chore(lock): refresh bundles.lock — redis 6.2.0 → 6.3.0 (closes #38)#89
Merged
Conversation
Manually-regenerated bundles.lock from `phpup lockfile-update` against
ghcr.io/buildrush. Replaces the 8 existing `ext:redis:6.2.0:{8.1..8.4}:*`
entries with the corresponding 6.3.0 entries, and adds 2 new
`ext:redis:6.3.0:8.5:*` entries (8.5 was previously excluded for
redis pre-#76).
Brings main back to a fully consistent state — catalog, lockfile, and
GHCR all agree on redis 6.3.0 — completing the work started in #76.
The non-redis line-level churn in this diff is in-entry digest/spec_hash
refresh from the multiple publish runs that fired during the chain of
fixes (#85, #86, #87, #88). Bundle keys themselves are unchanged
outside of redis. Per internal/testsuite/runner.go:345-346, manifest
digests are non-reproducible across pushes because meta.json carries a
build-time timestamp; this is expected behavior, not a regression.
Why this is committed by hand rather than auto-committed by the publish
job: the publish job's git push is rejected by the main-branch ruleset
("Changes must be made through a pull request"). A follow-up will
either switch the auto-commit to a bot-PR flow or grant the publish
identity a ruleset bypass; until then, version-bump PRs require this
manual lockfile-update PR step.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Manually-regenerated `bundles.lock` from `phpup lockfile-update` against `ghcr.io/buildrush`. This is the lockfile commit the post-#76 `publish` job tried to make automatically but couldn't (workflow→ruleset chain documented below).
Changes
Sanity check: only 18 bundle keys change (8 redis 6.2.0 removals + 10 redis 6.3.0 additions). All other line-level diff is within-entry digest/spec_hash refresh.
Why a manual PR
PR #76 (the redis catalog bump) merged on 2026-04-25 but couldn't trigger the auto-publish flow because of a four-link CI chain:
GHCR is now correct for all 10 redis 6.3.0 cells (verified: `gh api 'orgs/buildrush/packages/...'` shows full canonical-tag set). This PR is the lockfile catch-up that should have happened automatically post-#76.
Outstanding follow-up
The publish job still can't auto-commit `bundles.lock` because of #5 (ruleset). Options for a follow-up PR:
Until either lands, version-bump PRs need this manual lockfile-update PR step (predictable, ~1 min effort).
Verification
After this merges, end users on `@main` get a working redis 6.3.0 install on PHP 8.5 (and consistent on 8.1–8.4 against the new pin).
`make check` is unchanged (no Go source change). CI on this PR will smoke-test the action surface against the freshly-tagged GHCR bundles via PR #85's PR-self-containment path — the first end-to-end validation of the whole chain.
Closes #38.