Add minimumReleaseAge#2065
Conversation
🦋 Changeset detectedLatest commit: 11e3c21 The changes in this PR will be included in the next version bump. Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
tadhglewis
left a comment
tadhglewis
left a comment
There was a problem hiding this comment.
lgtm - gotta stop those zero days
| } | ||
|
|
||
| const newContents = `${pnpmWorkspaceContents} | ||
| minimumReleaseAge: 1440 |
There was a problem hiding this comment.
What about 3 days? Potentially overly cautious however renovates would take a few days to update a dependency anyway, so we should align local pnpm install with the renovate schedule?
Ref: https://github.com/seek-oss/rynovate/blob/714d3dc0de53be06c5228bed5e550ae65cab3ab7/default.json#L321
There was a problem hiding this comment.
Yeah open to suggestions, picked a day because that's what was in the pnpm changelog 😆
Mhmmm didn't think about that, kinda like aligning them 🤔
There was a problem hiding this comment.
Went with this approach because reviving this seemed like a substantially larger undertaking.
I would like to see it happen, but given the current frequency of incidents I thought the value of getting this in sooner rather than later outweighs having a nicer way to manage config now. 🫠
There was a problem hiding this comment.
Do we have an immediate need for overloads? If not, I wonder if we leave this out (or perhaps undocumented so as to not encourage uptake) until we implement skuba.config.ts properly.
There was a problem hiding this comment.
Think yes, only if we end up not excluding packages that we want to publish and test quickly 🤔
I wound it back to just @seek/* but am now reconsidering after looking at all the exclusions listed here.
Feel like it might be good to have them the same so we don't end up with renovates hanging around unable to install...
| - '*skuba*' | ||
| - '*seek*' |
There was a problem hiding this comment.
Is it concerning to exempt package patterns that we don't control (i.e. other than @seek/*)?
I'm thinking: not great, but probably not a dealbreaker. skuba isn't going to appear in package names organically, so it would require a targeted attack and two steps to exploit (compromise a package left-pad to add a benign dependency on a bad-skuba@^1.0.0 package then wait for 3 days for left-pad to be bumped, publish evil-skuba@1.0.1 with badness included then wait for the next lock file maintenance). seek may be more likely but again would likely require a targeted attack.
Not sure I like the alternative of tediously listing out the exclusions, unless we keep it to a pretty small subset (e.g. it's probably fine if seek-koala is not updated immediately).
There was a problem hiding this comment.
Yeah thinking through it more, the motivation was to keep the exclusion list short while not getting in the way of development. But if we keep the ability to overload then that provides an escape hatch if required, and makes the default less greedy. 🤔
There was a problem hiding this comment.
Do we have an immediate need for overloads? If not, I wonder if we leave this out (or perhaps undocumented so as to not encourage uptake) until we implement skuba.config.ts properly.
Co-authored-by: Ryan Ling <ryan@outlook.com.au>
Co-authored-by: Ryan Ling <ryan@outlook.com.au>
Align with seek-oss/skuba#2065.
Align with seek-oss/skuba#2065.
3 participants
https://github.com/pnpm/pnpm/releases/tag/v10.17.0