chore(deps): require a 24-hour minimum release age - #341
Merged
Conversation
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
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.
Part of RSRMID-3018.
Why
The daily dependency refresh resolved lockfiles with a 30-minute
minimumReleaseAgewhile every other install applied pnpm's default of 24 hours. It therefore committed
lockfiles that every consumer then rejected with
ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATIONfor up to a day, and any release triggered inthat window failed through no fault of the change that triggered it. The offending
packages rotated with each run, which made a standing conflict between two jobs look
like a transient.
The escape hatch had been applied unevenly across the organisation: three repositories
set
minimumReleaseAge: 0, two carried hand-maintainedminimumReleaseAgeExcludeallowlists that had already rotted (both pinned
@team-internet/semantic-release-plugins@1.0.6by exact version long after that packagemoved to 2.3.1, so they no longer matched anything they were written to cover), and the
rest inherited the default and broke.
What this does
Declares one value — 1440 minutes — here and in every other
rtldev-middlewarerepository, and retires the allowlists.
1440 is pnpm's own default, named explicitly rather than inherited so that it is a
decision which can be reported as drift when it changes.
0is deliberately not theanswer: this is a supply-chain control, and the reasoning is written into the file so
that the next person under time pressure does not reach for it to make a build go green.
The companion change in
rtldev-middleware-shareable-workflowsdeletes the refreshjob's own
--config.minimumReleaseAge=30rather than correcting the number, so thatboth
pnpmandnpm-check-updatesread this file instead. That makes the producer andthe consumer of the lockfile the same threshold by construction — and since the
constraint is "published before now minus the threshold", and now only moves forward, a
lockfile the refresh resolves can never be too fresh for a later install.
Enforced from here on by
scripts/node-policy.shin the workspace repository, whichalso forbids
minimumReleaseAgeExclude.Verification
pnpm install --frozen-lockfilepasses in this repository under the new threshold.