This is substantially less hacky and less fragile than the previous
approach that used htmlq to parse the raw html returned by the frontend
and then compared the extracted status against a hardcoded list of known
translated statuses.
Back when this subtest was added, there simply was no API endpoint to
gather this information yet. I had this in my out of tree variant of
Forgejo for a while now.
Requires Forgejo v8.0.0+
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
git v2.47.0 made changes to trace2's nesting.
trace2.eventNesting (GIT_TRACE2_EVENT_NESTING) defaults to 2, but the
nested region we are after gained a level and is now at level 3 instead
of 2.
eventNesting describes the maximum nesting level to be logged.
So to make it log the negotated-version in connect.c again, we increase
the default by one, from 2 to 3.
Instead of only testing the runner registration, which doesn't tell us
all that much, we now test a (very simple) but actual workflow directly
runner on the host (type `:host`).
For this to work, we cache the official `actions/checkout` action from
GitHub as FOD and essentially mirror one version of it to Forgejo as
part of the test.
Since Forgejo does not yet provide an API endpoint for the workflow status
(whether a workflow is running, failed or successful), we have to resort
to parsing html for now.
It has some rather over the top poll logic, but I feel like will work
for quite some time without issues going unnoticed or whatever (TM).
This is essentially a response to a bug I found in
`services.gitea-actions-runner`, because we had no way to test that
module besides the runner registration (which, again, doesn't really
tell us all that much).
We inherited almost all of this test from `nixos/tests/gitea` when we
decided to split.
This change saves some resources (just 2 instead of 3 VMs) and is (IMHO)
easier to follow and improve upon.
We forgot to set two version related ldflags in our packaging and this
should prevent this from going unnoticed again.
Further details are in dab7aa20ed.
This should allow us to catch issues regarding that in the future.
nixos/gitea had an issue with the dump service recently, which didn't
affect us, fortunately.
But to be fair, it only affected non-default-y setups.
Not something we are able to catch in the current, rather simple, config
of our test.
Still, I see a lot of value adding this new subtest to our test suite.
Anyhow, this patch also exposes the resulting tarball as test (build)
output, which is a nice addition IMHO, as it allows some sort of
external sanity-check, if needed, without running the test interactive.
