一键导入
ignition-update
// Update the Ignition library dependency to the latest release, re-vendor, and fix any breakage
// Update the Ignition library dependency to the latest release, re-vendor, and fix any breakage
| name | ignition-update |
| description | Update the Ignition library dependency to the latest release, re-vendor, and fix any breakage |
go.mod and the latest release from GitHubgo.mod to the latest Ignition versiongo mod tidy && go mod vendorgo test ./... to verify existing translations still workgh CLI available (for querying latest release), or internet access for go list -m -versions# Fully automatic - discovers latest version from GitHub
/ignition-update
No arguments required.
1a. Read the current Ignition version from go.mod:
grep 'coreos/ignition/v2' go.mod
Extract the current version (e.g., v2.20.0).
1b. Find the latest Ignition release:
gh release list --repo coreos/ignition --limit 10
Or:
go list -m -versions github.com/coreos/ignition/v2 | tr ' ' '\n' | tail -5
Pick the latest stable release (not a pre-release/RC).
1c. Compare versions:
If the current version is already the latest, inform the user and stop:
"go.mod already has the latest Ignition version (vX.Y.Z). Nothing to update."
1d. Confirm with user:
"Current: vX.Y.Z -> Latest: vA.B.C. Proceed with update?"
Edit go.mod to change the github.com/coreos/ignition/v2 version to the latest.
Only change the version in the require block, for example:
github.com/coreos/ignition/v2 v2.20.0
becomes:
github.com/coreos/ignition/v2 v2.26.0
Do NOT manually edit indirect dependencies - go mod tidy handles those.
go mod tidy
go mod vendor
If go mod tidy fails, it usually means:
go.mod)If the Go version in go.mod needs bumping (the new Ignition version requires a newer Go), update the go directive as well. Check what Go version the Ignition release requires:
# After vendoring, check what Ignition's go.mod requires
cat vendor/github.com/coreos/ignition/v2/go.mod | head -5
go test ./...
If tests pass, proceed to Step 6.
Common causes of breakage after an Ignition update:
5a. Type definition changes in existing specs
Ignition sometimes adds new fields, validation, or changes types in existing spec versions. If a translation module references a field that changed:
5b. New validation in existing specs
Ignition may add stricter validation to existing spec versions. Test configs that were previously valid may now fail validation:
5c. Transitive dependency API changes
If a transitive dependency (e.g., go-systemd, go-json) changed its API:
After fixing, re-run:
go test ./...
Repeat until all tests pass.
gofmt -l .
If any files are listed, format them:
gofmt -w .
After completion, summarize what changed for the user:
v3_X directories appeared in vendor)Suggest a commit message following the repo convention:
go.mod: update to Ignition vX.Y.Z
go mod tidy && go mod vendor/add-spec-translation for that)Discovering Ignition versions...
Current (go.mod): v2.20.0
Latest (GitHub): v2.26.0
Update Ignition v2.20.0 -> v2.26.0? (y/n)
Updating go.mod...
Running go mod tidy && go mod vendor...
New spec types detected:
- v3_6 (cex, clevis, config, device, directory, disk, ...)
Transitive dependencies updated:
- aws-sdk-go -> aws-sdk-go-v2
- go-systemd/v22: v22.5.0 -> v22.6.0
- testify: v1.9.0 -> v1.11.1
Running go test ./...
PASS
gofmt check: clean
Suggested commit message:
go.mod: update to Ignition v2.26.0
.opencode/skills/ignition-update/DESIGN.md.opencode/skills/add-spec-translation/SKILL.md04f5d8a, fc3acd6, dc5d7d4, 9b0adda