5 Commits
Author SHA1 Message Date
silverwind 1031e34987 test: run integration tests on random ports and speed up slow tests (#39842)
Integration test processes now get their own work directory, config file
and random ports, so several runs can execute in parallel on one
machine. The slowest tests also lose fixed sleeps and needlessly
expensive setup, with their assertions kept.

- Batch PostgreSQL sequence resets, the main per-test fixture cost there
- Cheap hashing params in hash and OAuth2 fixture tests, full-cost
vectors stay
- Single fetch for negative Actions runner assertions instead of 1s
polls
- Queue flushes and backdated timestamps instead of sleeps
- In-memory SQLite test journal, tmpfs for PostgreSQL in CI
- E2E instance writes SSH keys into its work directory instead of
`~/.ssh/authorized_keys`
2026-10-18 12:56:04 +00:00
silverwind afb7edef07 refactor: replace AWS SDK with a REST client for CodeCommit migration (#39330)
Replace `aws-sdk-go-v2` in the CodeCommit migration with a minimal REST
client for the four read-only API calls it uses. Binary shrinks by ~3.1
MB.

Mock data was recorded against live from a AWS CodeCommit repo and then
anonymized.

Also stop storing the repo description as the default branch which fixes
below issue. All comments in
https://github.com/go-gitea/gitea/issues/34627 are addressed, the merge
metadata was fixed earlier in
https://github.com/go-gitea/gitea/pull/34645.

Fixes: https://github.com/go-gitea/gitea/issues/34627
2026-09-17 09:58:05 +00:00
silverwind df71d5f5e2 test: run frontend unit tests in browsers (#38860)
Run them in headless [vitest browser
mode](https://vitest.dev/guide/browser/) in chromium and firefox.
Similar UX than current tests, it's about 5 times as slow (goes from 1s
to 5s on my machine), but definitely worth it as it removes all
happy-dom problems.

---------

Signed-off-by: silverwind <me@silverwind.io>
2026-08-17 22:22:54 +00:00
wxiaoguanganddelvh fff32e9469 refactor: prepare to decouple the "model migration" package and "models" package (#38533)
Migrations should never use model structs directly, because the model
structs can be different in different releases. e.g. if one migration uses
"User" model, it works in the early releases, then one day, when the
User model changes, the migration breaks because it will use the
new (incorrect) User model, it should only use the old User model.

The same to "modules/structs".

---------

Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
2026-07-20 03:42:02 +00:00
c68925152b docs: add development setup guide (#37960)
Moves the "Hacking on Gitea" page out of the documentation website and into the repository as `docs/development.md`, so contributors find build and test instructions next to the code. The content has been cleaned up and corrected for in-repo use.

---------

Signed-off-by: bircni <bircni@icloud.com>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
2026-06-17 06:39:22 +00:00