Skip to content

Stopped Renovate reopening the Redis major PR after we close it - #2158

Merged
sagzy merged 1 commit into
mainfrom
claude/renovate-immortal-pr-config-4f19b0
Sep 2, 2026
Merged

sagzy merged 1 commit into
mainfrom
claude/renovate-immortal-pr-config-4f19b0

Conversation

@sagzy

@sagzy sagzy commented Sep 2, 2026 •

Copy link
Copy Markdown
Contributor

ref #2148

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.

flowchart TD
    A[PR closed unmerged] --> B{Grouped PR?}
    B -->|No| C["Title names a version<br/>'Update dependency ky to v2.1.0'"]
    C --> D[Closure is durable — stays closed]
    B -->|Yes| E{Members moving to<br/>different versions?}
    E -->|No| D
    E -->|Yes| F["Contents shift as any member moves,<br/>so branch + title can't record<br/>what we rejected"]
    F --> G[Immortal — recreated on the next run]
    G -.->|recreateWhen: 'never'| D
Loading

This 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.

@coderabbitai

coderabbitai Bot commented Sep 2, 2026 •

Copy link
Copy Markdown

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: 2822e12f-419e-4501-9938-3108e0e40c6a

📥 Commits

Reviewing files that changed from the base of the PR and between b0a81fd and f79fe4f.

📒 Files selected for processing (1)
  • .github/renovate.json5

Walkthrough

The Redis Renovate package rule now sets recreateWhen: 'never', so Renovate does not recreate the grouped Redis major-update pull request.

Estimated code review effort: 1 (Trivial) | ~2 minutes

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch claude/renovate-immortal-pr-config-4f19b0

Comment @coderabbitai help to get the list of available commands.

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
sagzy force-pushed the claude/renovate-immortal-pr-config-4f19b0 branch from 8eaf4d0 to f79fe4f Compare September 2, 2026 11:21
@sagzy
sagzy merged commit bb5adb7 into main Sep 2, 2026
8 of 9 checks passed
@sagzy
sagzy deleted the claude/renovate-immortal-pr-config-4f19b0 branch September 2, 2026 11:22

This branch was previously deployed

1 inactive deployment
staging — f79fe4f4 Deployed Sep 2, 2026 by sagzy via deploy-pr / Deploy PR #9555
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant