gotestsum [1] is a tool that brings sanity to human-powered
analysis of test results, supporting handy summaries of results
and more.
This implementation allows for the use of `USE_GOTESTSUM=yes`
to switch the implementation from raw `go test` to `gotestsum`.
It also gives general flexibility in choice of go tests runner.
The PREFIX-SUFFIX play is needed for compiled tests and may
be subject to modification depending on the outcome of #5248
[1] https://pkg.go.dev/gotest.tools/gotestsum
This is a step towards making Forgejo's binaries (the one listed in the
release tab) reproducible.
In order to make the actual binary reproducible, we have to ensure that
the release workflow has the correct configuration to produce such
reproducible binaries. The release workflow currently uses the
Dockerfile to produce binaries, as this is one of the easiest ways to do
cross-compiling for Go binaries with CGO enabled (due to SQLite). In the
Dockerfile, two new arguments are being given to the build command.
`-trimpath` ensures that the workpath directory doesn't get included in
the binary; this means that file names (such as for panics) are
relative (to the workpath) and not absolute, which shouldn't impact
debugging. `-buildid=` is added to the linker flag; it sets the BuildID
of the Go linker to be empty; the `-buildid` hashes the input actions
and output content; these vary from build to build for unknown reasons,
but likely because of the involvement of temporary file names, this
doesn't have any effect on the behavior of the resulting binary.
The Makefile receives a new command, `reproduce-build#$VERSION` which
can be used by people to produce a reproducible Forgejo binary of a
particular release; it roughly does what the release workflow also does.
Build the Dockerfile and extract the Forgejo binary from it. This
doesn't allow to produce a reproducible version for every release, only
for those that include this patch, as it needs to call the makefile of
that version in order to make a reproducible binary.
There's one thing left to do: the Dockerfile pins the Go version to a
minor level and not to a patch level. This means that if a new Go patch
version is released, that will be used instead and will result in a
different binary that isn't bit to bit the same as the one that Forgejo
has released.
Modifies forms:
- (new) org team
- (new) repo webhook
- (new) repo protected branch
The forms are not completely rewritten to semantic HTML yet. The focus
of this change was on standard elements, some custom solutions were left
untouched for now.
- swaps the order fo permission radio buttons as per https://codeberg.org/forgejo/forgejo/issues/4983
- uses fieldsets to group related inputs
- ensures consistent styling across forms
- can be improved later, e.g. using horizontal lines between sections
- fixes: previous font size of labels was smaller than the font size of the help text
- help text are now part of the label, clicking them now also activates the input
- drop unused CSS (no required checkboxes in grouped class remain)
- playwright testing:
- move login boilerplate to utils
- automated form accessibility checking
- allow defining the scope, because legacy parts of the forms are not yet accessible
- assert some CSS properties that should not be overriden
- the Makefile adjustment was necessary, because eslint scanned some internal files in the tests/e2e/reports directory
See https://codeberg.org/forgejo/discussions/issues/164 for the
rationale and discussion of this change.
Everything related to the `go-git` dependency is dropped (Only a single
instance is left in a test file to test for an XSS, it requires crafting
an commit that Git itself refuses to craft). `_gogit` files have
been removed entirely, `go:build: !gogit` is removed, `XXX_nogogit.go` files
either have been renamed or had their code being merged into the
`XXX.go` file.
For #4082.
~~Per the discussion in the issue, the current plan will likely involve duplicating the redis library calling code once for each cacher, as neither garnet nor redict guarantee continued compatibility with redis.~~
See discussion below for details.
## Tasklist
- [x] Write workflow to run cache-specific unit test(s) only (cache, session, queue, nosql) for each cacher
- [x] Check whether garnet and redict pass unit tests with no code modification (gauge required work)
- both passed, but that is because there were very few tests that test the remote cache store
### Out of scope for this PR
- Improve test coverage
- `modules/cache` against a server
- `modules/session` against a server (also needs tests in general)
- _(?) Duplicate implementation for each cacher_
- _Restructure redis usage in `modules/cache` and `modules/settings/cache`_
- _Restructure `modules/session` and its settings_
- _Restructure `modules/queue` and its settings_
- _Restructure `modules/nosql` and its settings_
Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/4138
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Elias Elwyn <a@jthv.ai>
Co-committed-by: Elias Elwyn <a@jthv.ai>
