mirror of
https://github.com/moons-14/dotfiles.git
synced 2026-10-07 02:24:08 +09:00
59 lines
2.3 KiB
Markdown
59 lines
2.3 KiB
Markdown
---
|
|
name: update-flake-input
|
|
description: Update one or more pinned flake inputs with bounded lock-file changes and non-activating Linux and Darwin validation. Use for dependency refreshes, input-specific updates, automated lock-file pull requests, or diagnosing a regression introduced by flake.lock.
|
|
---
|
|
|
|
# Update a Flake Input
|
|
|
|
Keep the update scope explicit and treat `flake.lock` as generated dependency
|
|
state. Never activate a host as part of this workflow; do not run `nh os switch`,
|
|
`nixos-rebuild switch`, `darwin-rebuild switch`, `home-manager switch`, or an
|
|
equivalent command.
|
|
|
|
## Bound the update
|
|
|
|
1. Read `AGENTS.md`, inspect `git status --short`, and preserve unrelated work.
|
|
2. Record the input names and the behavior or version change being requested.
|
|
3. Prefer an input-specific update:
|
|
|
|
```sh
|
|
nix flake update <input-name>
|
|
```
|
|
|
|
Use an unrestricted `nix flake update` only when the task explicitly requests a
|
|
full refresh. Do not hand-edit lock nodes.
|
|
|
|
## Audit the lock diff
|
|
|
|
Inspect the complete `flake.lock` diff. Confirm that changed nodes are the
|
|
requested inputs or unavoidable followers and that source owners, repositories,
|
|
reference types, and hashes remain expected. Investigate unexpected node
|
|
replacement, disappearing followers, or a large transitive graph rewrite before
|
|
validation.
|
|
|
|
## Validate without activation
|
|
|
|
Run the common validation workflow against the lock file:
|
|
|
|
```sh
|
|
nix run .#check -- plan --paths flake.lock --json
|
|
nix run .#check -- fast --paths flake.lock
|
|
nix run .#check -- eval --paths flake.lock
|
|
nix run .#check -- build --paths flake.lock
|
|
```
|
|
|
|
A lock-file change requires full evaluation and the complete native check set.
|
|
Linux and Darwin builds must run on compatible runners. The scheduled update
|
|
workflow uploads the candidate lock file, builds Linux and Darwin checks, and
|
|
creates a pull request only after both pass.
|
|
|
|
When a failure appears only after the update, invoke `debug-nix-failure`, compare
|
|
the failing derivation or option with the base lock, and narrow the responsible
|
|
input before adding an override or patch.
|
|
|
|
## Report the result
|
|
|
|
List requested and transitively changed inputs, validation commands and native
|
|
platform results, any package or option migration, and remaining manual runtime
|
|
checks. Evaluation or a native build is not activation.
|