Repository navigation
Update mysql Docker tag to v26 - #2152
Closed
renovate[bot] wants to merge 1 commit into
Closed
renovate[bot] wants to merge 1 commit into
renovate[bot] wants to merge 1 commit into
Conversation
Contributor
Author
Renovate Ignore NotificationBecause you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR. |
sagzy
added a commit
that referenced
this pull request
Sep 2, 2026
We've closed the Redis major PR three times now and it has come back every time — #2153, then #2155, then #2156 — each one carrying the "Immortal: this PR will be recreated if closed unmerged" banner. That banner isn't arbitrary. Renovate records a closure as "this branch with this title was rejected", and it refuses to trust that record when the PR's contents can shift underneath it. A grouped PR whose members move to different versions is exactly that case: our Redis group pairs ioredis 5.11.1 -> 6.0.0 with the redis image 7-alpine -> 8-alpine, which trips the check in generateBranchConfig and marks the branch immortal. It also explains why the other majors we closed that day stayed closed — ubuntu (#2154) and mysql (#2152) were single-dep PRs whose titles name a version, so their closures mean something durable. recreateWhen: 'never' on the rule tells Renovate to honour the closure anyway. Two things worth knowing about that: - This group's title has no version in it ("Update Redis (major)"), so closing the PR now silences later Redis majors under the same title. The Dependency Dashboard lists it with a checkbox that forces the PR back, which is the escape hatch when we do want to do the upgrade. - Only Redis gets the setting. MySQL and Node are grouped the same way and could develop the same behaviour if both members ever take majors at differing versions, but neither has, and a rule that isn't earning its place is a rule someone has to reason about later. The alternative was pinning ioredis below 6 the way the shared preset pins @elastic/elasticsearch. That says "not this version, and here's why", which is a stronger claim than we can make — we haven't decided against Redis 8, we've just decided against it this week. ref #2148
sagzy
added a commit
that referenced
this pull request
Sep 2, 2026
We've closed the Redis major PR three times now and it has come back every time — #2153, then #2155, then #2156 — each one carrying the "Immortal: this PR will be recreated if closed unmerged" banner. That banner isn't arbitrary. Renovate records a closure as "this branch with this title was rejected", and it refuses to trust that record when the PR's contents can shift underneath it. A grouped PR whose members move to different versions is exactly that case: our Redis group pairs ioredis 5.11.1 -> 6.0.0 with the redis image 7-alpine -> 8-alpine, which trips the check in generateBranchConfig and marks the branch immortal. It also explains why the other majors we closed that day stayed closed — ubuntu (#2154) and mysql (#2152) were single-dep PRs whose titles name a version, so their closures mean something durable. recreateWhen: 'never' on the rule tells Renovate to honour the closure anyway. Two things worth knowing about that: - This group's title has no version in it ("Update Redis (major)"), so closing the PR now silences later Redis majors under the same title. The Dependency Dashboard lists it with a checkbox that forces the PR back, which is the escape hatch when we do want to do the upgrade. - Only Redis gets the setting. MySQL and Node are grouped the same way and could develop the same behaviour if both members ever take majors at differing versions, but neither has, and a rule that isn't earning its place is a rule someone has to reason about later. The alternative was pinning ioredis below 6 the way the shared preset pins @elastic/elasticsearch. That says "not this version, and here's why", which is a stronger claim than we can make — we haven't decided against Redis 8, we've just decided against it this week. ref #2148
This branch was previously deployed
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.
This PR contains the following updates:
8.4.11→26.7.0Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
Configuration
📅 Schedule: (UTC)
* 7-16 * * 1,2,3,4)🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.