There is no guarantee that a test will not reset the actions logs from a
previous test. Since logs-compression depends on the logs from the
echo test, make that dependency explicit.
The absence of the test-gitlab container will display
Error response from daemon: No such container: test-gitlab
which can be mistaken as an actual error where in fact it should be
ignored.
The log path depends on the previous actions run and may not always
be 01/1.log.zst. Assuming it is makes this test fragile as it is
influenced by which previous tests are run and what they do.
Instead of having an explicit vX.Y-dev version to be referenced
explicitly, a binary built from source replaces the matching
version. For instance, if forgejo/build-from-sources contains v9.0,
* the development branch is compiled from source
* the v9.0 artifact is uploaded
* prior to running any test, the artificat is downloaded and used
* the v9.0 binary is not downloaded from
forgejo/experimental/integration because it is already present
The vX.Y release is built daily and the end-to-end tests run on it. If
a regression is introduced, it will be spotted within 24h.
Compiling from source is used when the Forgejo runs the end-to-end
suite on a specific pull request.
In the lifecycle of vX.Y.Z, all tests are run against vX.Y-test
before it is published, including when the tag is pushed because the
automated release process now runs end-to-end before pushing the
release to forgejo-experimental.
Running end-to-end against vX.Y-dev is therefore redundant with at least
two other runs with exactly the same SHA (the one before the tag is
pushed and the one when the tag is pushed). There would be value in
doing that if it allowed to detect race conditions in Forgejo. But
such races were not found in the past six months and there is a lot
more scrutiny on commits merged in Forgejo which makes it even less
likely than it was before.
Running the tests on vX.Y instead of also including the built version
provide the same coverage and reduces the workload.
the upgrade path from Gitea v1.21 & v1.22 to v8.0 was tested before it
was published. The patch releases for v8.0 will only include bug fixes
and no database upgrades: they are the only kind of changes that could
cause a problem with upgrades.
/repos/{owner}/{repo}/actions/workflows/{workflowname}/dispatches
* fails if the required inputs are not provided
* sets defaults to inputs that are not provided
The type of inputs are only used for building the web UI interface,
not for validation. All values are strings.
Do not force the runner version, use whatever default setup-forgejo
provides.
Forcing the version will break the cascading-pr workflow. It will
attempt to download a version that does not exist instead of building
it from sources.
This reverts commit dca3641cf3.
