Revert 53375283d4
fix: alternative route of getting latest Gitea version
Use git ls-remote and git-mirror instead of the API
$ version=1.23
$ git ls-remote --refs --tags --sort=version:refname https://git-mirror.forgejo.org/go-gitea/gitea "v$version*" | sed -n -E -e "s|^.*/v($version[\.0-9]*)$|\1|p"
1.23.0
1.23.1
1.23.2
1.23.3
1.23.4
1.23.5
1.23.6
1.23.7
The function may be called from scripts that run under different users
and re-using the same file name will run into problems:
/home/debian/.cache/act/2cc577985400de79/hostexecutor/lib/lib.sh: line 96: /tmp/page: Permission denied
curl: (23) Failure writing output to destination
Loop over all pages instead of getting the first one only to not miss any version.
Reviewed-on: https://code.forgejo.org/forgejo/end-to-end/pulls/544
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
Do not hardcode https://codeberg.org, use the FORGEJO_INSTANCE variable instead. It can be overriden when codeberg.org is unavailable.
Reviewed-on: https://code.forgejo.org/forgejo/end-to-end/pulls/542
Reviewed-by: earl-warren <earl-warren@noreply.code.forgejo.org>
Co-authored-by: limiting-factor <limiting-factor@posteo.com>
Co-committed-by: limiting-factor <limiting-factor@posteo.com>
The end-to-end tests moved to a slower machine recently. When the
daily releases are build, the end-to-end all run simultaneously and
slow down the machine to a point where it will take more than 30
seconds for a Forgejo instance to start.
Be more forgiving and let it retry for a minute.
https://code.forgejo.org/forgejo/end-to-end/actions/runs/1857/jobs/6
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.
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 $work_path/forgejo-curl.sh for each Forgejo instance is logged
in with admin permissions and ready to use.
The default forgejo-curl.sh remains logged in the last Forgejo
instance that was launched.
Instead of hardcoding "forgejo" as the base for the daemon to store
the PID and the logs, use the base of the WORK_PATH so that a given
work path can run a dedicated forgejo instance by the same name.
instead of hardcoding forgejo-work-path to be the base of WORK_PATH
relative to DIR, read it from the app.ini file. It will allow
multiple Forgejo instances to run simultaneously, each using a
different directory.
The instance hosting the forgejo repository may be down or very slow
while the build tries to fetch from it, retry a few times instead of
giving up immediately.
A total retry time of 3 * 60 seconds is probably sufficient since
Forgejo startup time is lower than this, even on large instances.
* replace the high level test running actions tests with end-to-end.sh
* set DOMAIN to the IP instead of 127.0.0.1 for runner <-> forgejo communications
* move forgejo_cli from a function to a file so that it can be used by forgejo-runner.sh
* keep the documentation updates workflows separate because they need to open one PR per version
