Enable Build Provenance for Nightly Builds #59013
Conversation
Maybe. This is pretty difficult (impossible?) to test outside of the CI environment itself. Ostensibly, this is all we should need for github actions, though. cc @DanielRosenwasser who wanted to know what it'd take to enable this. For nightlies, at least, it's in theory not bad. For actual releases, it's likely a bit more complex, given our publishing and releasing pipeline.
typescript-bot
added
Author: Team
For Uncommitted Bug
| @@ -60,6 +61,6 @@ jobs: | |||
| npx hereby configure-nightly | |||
| npx hereby LKG | |||
| node ./scripts/addPackageJsonGitHead.mjs package.json | |||
| npm publish --tag next | |||
| npm publish --provenance --access public --tag next | |||
There was a problem hiding this comment.
I don't think this will work; CI uses the version of npm in package.json, which is v8, and it doesn't seem like it has that flag:
Publish a package
Usage:
npm publish <package-spec>
Options:
[--tag <tag>] [--access <restricted|public>] [--dry-run] [--otp <otp>]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[-ws|--workspaces] [--include-workspace-root]
Run "npm help publish" for more info
There was a problem hiding this comment.
(we're pinned to v8 since we need to ensure the lockfile stays at v2 so that older node in CI can install the right stuff, but I suppose we could instead do a node version swap in those jobs after install)
There was a problem hiding this comment.
Do we have a reason we can't bump it for this task?
There was a problem hiding this comment.
Rather, I mean: we could just install latest npm just for the publish line here.
There was a problem hiding this comment.
Then we'd be publishing with an untested version of node; we've seen that the files array globbing rules changed previously and broke a published package, so I'm moderately nervous about that. I think I'd sooner bump us to a newer npm and then just do "use node 20, install, switch to node 14, test"
There was a problem hiding this comment.
The node versions are definitely all still tested, it's moreso the npm publish result isn't - which is fair, but we also don't test that. At all. That'd be like a post-publish API test watchdog, which is like... a couple levels deeper an integration test than we bother with right now, and even then that would be an after-the-fact thing (though you could make the argument the playground fills this purpose) - it's just impossible for us to know how npm is going to roundtrip the package (though we probably can have reasonable expectations) through the publishing operation (though npm pack is a... partial preview?). And honestly, if npm@latest breaks what we publish, I'd rather know sooner (in the nightly, which can break from time to time, and if it does, people and infra complain) than later (whenever we get around to updating the frozen version string).
There was a problem hiding this comment.
That's fair, though I also think it'd be odd for our nightly releases to have providence but not our stable builds... 😄
There was a problem hiding this comment.
It's just easy to turn on to try in our nightlies and tweak until it's right (at hopefully minimal cost to us), and then we have another month or so before we even make our next stable build to consider if we can/it's worth finally fully migrating off of azure pipelines for releases (provenance as is right now is only works on github actions and gitlab runners - presumably because those are the runners where npm knows how to find the build steps for the publish (not that build steps alone get you a truly reproducible build, but that's why it's "provenance" and not "reproducible builds" - it's a weaker guarantee)).
There was a problem hiding this comment.
Yeah, if we use Actions, then I'd probably even go to the highest level, e.g. https://github.com/jakebailey/hereby/blob/main/.github/workflows/release.yml#L33 (which works well).
There was a problem hiding this comment.
I'd rather just stick with what npm provides for now - it's far more likely to become defacto standard than the bespoke actions are.
Maybe. This is pretty difficult (impossible?) to test outside of the CI environment itself. Ostensibly, this is all we should need for github actions, though.
cc @DanielRosenwasser who wanted to know what it'd take to enable this. For nightlies, at least, it's in theory not bad. For actual releases, it's likely a bit more complex, given our publishing and releasing pipeline.