skuba migrate node 22 #1735
skuba migrate node 22 #1735
Conversation
🦋 Changeset detectedLatest commit: ed14a1b 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 |
There was a problem hiding this comment.
I feel we need to test how this behaves in a file structure, would the best way to do this be by utilising memfs?
| export const patches: Patches = [ | ||
| { | ||
| apply: tryUpgradeNode, | ||
| description: 'Upgrades Node.js to version 22', |
There was a problem hiding this comment.
| description: 'Upgrades Node.js to version 22', | |
| description: 'Upgrade Node.js to version 22', |
There was a problem hiding this comment.
IIRC we typically put this under the current version (i.e. 9.1.0) as we can't necessarily predict the release it will end up in (could be 9.2.0, could be 10.0.0).
|
|
||
| if (type === 'package') { | ||
| log.warn( | ||
| 'Skuba type package is not supported, packages should be updated manually to ensure major runtime depreciations are intended', |
There was a problem hiding this comment.
Violation of skuba brand guidelines 🧌
| 'Skuba type package is not supported, packages should be updated manually to ensure major runtime depreciations are intended', | |
| 'skuba type package is not supported, packages should be updated manually to ensure major runtime deprecations are intended', |
| if (process.env.SKIP_NODE_UPGRADE) { | ||
| return { | ||
| result: 'skip', | ||
| reason: 'SKIP_NODE_UPGRADE environment variable set', | ||
| }; | ||
| } |
There was a problem hiding this comment.
- Does
skippermanently discard the patch, or will it retry on the next run without the environment variable? Any thoughts on the desired behaviour here? - I have a slight preference for formalising this as a command-line option because I see it being long lived (new LTS every year), but I could be easily convinced the other way
| execSync( | ||
| `npm show @types/node@^${major} version --json | jq '.[-1]'`, | ||
| ).toString(); |
There was a problem hiding this comment.
- I think we'd almost always run in an environment with
npmpreinstalled, but is there an equivalent package that lets us achieve this without depending on an external binary? - I'm not sure that we can assume that
jqis installed. Can we do that part in code?
| @@ -41,22 +53,30 @@ describe('nodeVersionMigration', () => { | |||
| 'plugins:\n - docker#v3.0.0:\n image: node:18.1.2-slim\n', | |||
| '.buildkite/pipeline2.yml': | |||
| 'plugins:\n - docker#v3.0.0:\n image: node:18\n', | |||
| '.buildkite/pipline3.yml': | |||
There was a problem hiding this comment.
Is pipline intentional 😅. ig it proves we're not strictly matching on pipeline
Resolves #1549