They do not appear to be needed in recent versions (could not find a reference
in Ladybird build system).
If they are needed for the build it would likely they would make the package
`unfreeRedistributable` given the EULA attached to them.
We can use the same "hack" as in labeler-no-sync.yml, because OWNERS is
the only file without extension in that directory structure.
This makes it easier to search for CI related PRs via label.
This adds the minimum nix version and the latest lix version to the
matrix of parse checks. Especially the minimum nix version is relevant,
because parsing routinely breaks because of introduction of newer
syntax.
Adding lix just completes the picture.
The nix-parse workflow can now be run locally the same way as in CI.
To do this, the CI's workflow was slightly adjusted. Instead of testing
only the changed files, we're now testing all files in the repository.
This is possible in two ways:
1. By calling nix-instantiate once with all files as arguments. This
will be rather fast, but only the first error is shown before it errors
out.
2. By calling nix-instantiate once for each file. This will be much
slower, but has the advantage that we see all errors at once.
To avoid running the long variant every time, we first do a quick check
with the fast version. If that fails, we run the slower one to report
the errors. This gives us the best of both.
ARM runners are supposed to be more energy efficient than x86. Also,
from limited testing, they appear to be faster for the eval jobs as
well. Average run time for the "Outpaths (x86_64-linux)" job was 4m 27s,
so far. In the first run, this job came in at 3m 9s. This effect did not
show for other jobs, yet.
The following two exceptions are made right now:
- nixpkgs-lib-tests currently fails on the ARM runner building Nix 2.3
- nixpkgs-vet is currently pinned to a x86_64-linux only binary release
I added a lint-action.sh script in .github/workflows a while ago while
fixing some warnings. But I haven't run it myself ever since. This needs
to be part of CI to make any use of it.
The eval-aliases job is independent of all the other eval jobs. By
splitting it into a separate workflow, we avoid running it in two cases:
1. When turning a PR "ready to review". In this case, the main eval
workflow needs to run to be able to tag reviewers - but not
eval-aliases.
2. On branches like master, staging, etc. We only need to run eval there
to have a result to compare against in PRs. eval-aliases doesn't
contribute to that.
Thus, this will avoid wasting resources.
Previously, the user of postgresqlTestHook would have needed to set
failureHook accordingly. However, this was not a clean solution, because
postgresqlStop would also run for configure or build failures, before
the server was even started. This gave odd errors from a failed shutdown
in the log.
Now postgresqlStop is only called when it makes sense - and whenever
postgresqlTestHook is used.
