Root cause: DeterminateSystems/update-flake-lock@v27 uses
peter-evans/create-pull-request@v6.0.5 internally, which is incompatible
with actions/checkout@v6's new credential storage mechanism.
The Problem Chain:
- actions/checkout@v6 moved credentials from .git/config to $RUNNER_TEMP
(security improvement)
- peter-evans/create-pull-request@v6.0.5 cannot access credentials from
the new $RUNNER_TEMP location
- This causes exit code 128 when update-flake-lock tries to create PRs
The Fix:
- create-pull-request@v7.0.9 fixed v6 compatibility
- However, update-flake-lock@v27 (released July 2025) hasn't upgraded yet
- Reverting to v5 restores working credential access
Next Steps:
- Can upgrade to v6 once update-flake-lock uses create-pull-request@v7.0.9+
- https://github.com/DeterminateSystems/update-flake-lock/pull/224
- Dependabot configured to ignore v6 upgrades until compatibility is fixed
Fixes: https://github.com/nix-community/home-manager/actions/runs/19712979574
See: https://github.com/peter-evans/create-pull-request/issues/690
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We have moved towards running more tests on buildbot for better
performance. Don't duplicate efforts on github actions.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We have lots of tests and would like to add more. However, adding more
testing coverage comes at the cost of a slower CI when we run them
sequentially. This adds test outputs that are chunked however we'd like
to tune for batch sizes. Allowing us to create a parallelized CI
workflow.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Break the workflow into multiple scripts to make it easier to test /
maintain. Also fix the remove reviewer process to not review reviews
from people that were manually requested.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Better support updating existing PRs and summary of changes in workflow
summary. Tested in nixvim.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We dont want need to maintain duplicate entries for maintainers in HM
that already exist in Nixpkgs. Add a check that calls out users that
don't need an entry in our internal list.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We just need to run it once properly and dont need to keep running it
for every push until the last.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We want to ping maintainers whenever files are affected. Right now it
requires changing a PR to a draft and reopening, but we should be more
clever and request the review whenever the file is updated.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Was relying on flawed logic and fragile parsing to identify maintainers
on changed files. Rework to use nix eval to grab the `meta.maintainers`
to use when requesting a review.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Previously, we had to hack together some string matching to identify and
retrieve the maintainers in the repo. We can just eval the modules to
retrieve the list of maintainers more accurately.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Cancel existing runs when a new push happens so we don't unnecessarily
run jobs that are irrelevant.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We need to make sure that we don't insert invalid maintainers otherwise
it breaks the RFC39 invite workflow. Check that we have valid nix and
the required attributes are able to be parsed properly.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Want to create an easier way to notify maintainers that someone is
working on their module. Added a workflow for requesting a review from any maintainers that have joined the `home-manager-maintainers` team in the organization.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
We need a nixpkgs on NIX_PATH. Right now we have been using the latest
from channel. But, we can actually just fetch the nixpkgs from our
flake.lock by parsing the flake.lock.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Not every PR requires the overhead of spinning up runners and running
our entire test suite. Filter on paths affected and only run the
relevant steps.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Currently only running on the master branch. But, we can schedule on the
release branch, as well.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
Right now, we grab the latest home-manager pushed to remote. We need to
test against the code we are pushing out.
Signed-off-by: Austin Horstman <khaneliman12@gmail.com>
