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.
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.
/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.
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.
A loop is waiting for /srv/example/post-7-0-schedule-volume/DONE to exist before
declaring the workflow is successfully run. But it is not really until
/srv/example/post-7-0-schedule/contexts is created with the event content and they
will race.
Fixes: https://code.forgejo.org/forgejo/end-to-end/issues/181
Exactly the same as 57fdd1cd49 but for
post-7-0-schedule instead of cron
A loop is waiting for /srv/example/cron-volume/DONE to exist before
declaring the workflow is successfully run. But it is not really until
/srv/example/cron/contexts is created with the event content and they
will race.
Fixes: https://code.forgejo.org/forgejo/end-to-end/issues/181
A) When both push happen within the same second, the SHA will be
identical and there will not be any cancelation.
B) When `sleep infinity` happens after the reload of the runner, it
will block the following tests forever because it has a capacity of one.
Fixes: https://code.forgejo.org/forgejo/end-to-end/issues/144
2024-05-13T00:58:49.1453499Z actions_verify_example.out:[main (root-commit) cbf3afb] initial commit
2024-05-13T00:58:49.1453528Z actions_verify_example.out: 3 files changed, 28 insertions(+)
2024-05-13T00:58:49.1453556Z actions_verify_example.out: create mode 100644 .forgejo/workflows/test.yml
2024-05-13T00:58:49.1453585Z actions_verify_example.out: create mode 100755 run.sh
2024-05-13T00:58:49.1453611Z actions_verify_example.out: create mode 100644 teardown.sh
2024-05-13T00:58:49.1453638Z actions_verify_example.out:+ git remote add origin http://root:admin1234@10.201.14.172:3000/root/example-push-cancel
2024-05-13T00:58:49.1453669Z actions_verify_example.out:+ git push --force -u origin main
2024-05-13T00:58:49.1453699Z actions_verify_example.out:remote: . Processing 1 references
2024-05-13T00:58:49.1453728Z actions_verify_example.out:remote: Processed 1 references in total
2024-05-13T00:58:49.1453758Z actions_verify_example.out:To http://10.201.14.172:3000/root/example-push-cancel
2024-05-13T00:58:49.1453786Z actions_verify_example.out: * [new branch] main -> main
2024-05-13T00:58:49.1453814Z actions_verify_example.out:branch 'main' set up to track 'origin/main'.
...
2024-05-13T00:58:49.1458629Z actions_verify_example.out:[main (root-commit) cbf3afb] initial commit
2024-05-13T00:58:49.1458656Z actions_verify_example.out: 3 files changed, 28 insertions(+)
2024-05-13T00:58:49.1458683Z actions_verify_example.out: create mode 100644 .forgejo/workflows/test.yml
2024-05-13T00:58:49.1458711Z actions_verify_example.out: create mode 100755 run.sh
2024-05-13T00:58:49.1458738Z actions_verify_example.out: create mode 100644 teardown.sh
2024-05-13T00:58:49.1458764Z actions_verify_example.out:+ git remote add origin http://root:admin1234@10.201.14.172:3000/root/example-push-cancel
2024-05-13T00:58:49.1458795Z actions_verify_example.out:+ git push --force -u origin main
2024-05-13T00:58:49.1458822Z actions_verify_example.out:Everything up-to-date
When the container for running the steps is specificied, it is setup
differently than when it is implicit. This test adds coverage for both
instead of running all examples with an explicitly specified container
image.
* 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
