nearform-actions/optic-release-automation-action

Add support for provenance

simoneb opened this issue ยท 7 comments

https://github.blog/2023-04-19-introducing-npm-package-provenance/

Things to consider:

  • does it work on older npm versions? probably not
AlanSl commented

Regarding the "older versions of NPM" question:

Running npm publish --provenance in 9.4 (before the release in 9.5), 8.3.1 and 6.0.0 just ignores the flag, it doesn't cause it to fail. NPM 9.5.1 is already the default in ubuntu-latest so most CI jobs should be compatible, but when someone's CI uses an old version of node, it looks like the publish will pass and the --provenance flag will be ignored.

I'm assuming we want provenance to be an opt-in option defined something like this?

      - uses: nearform-actions/optic-release-automation-action
        with:
          semver: ${{ github.event.inputs.semver }}
          commit-message: 'chore: release {version}'
          provenance: true

So we could just ignore NPM version, but maybe we want to abort if a user opted in to provenance and doesn't realise their CI is using a too-old version of NPM, rather than letting the publish succeed and the provenance aspect fail silently? With something like this maybe:

if (inputs['provenance']) {
  const npmVersion = getNpmVersion()
  if (!semver.satisfies(npmVersion, '>=9.5.0') {
    throw new Error(`Provenance option requires action to run on NPM >=9.5.0. You are using NPM ${npmVersion}`)
  }
}
AlanSl commented

Regarding actually adding provenance support:

Unfortunately, simply adding --provenance flag to the exec call within publishToNpm.js fails with this error:

npm notice Publishing to https://registry.npmjs.org/ with tag latest and default access
npm ERR! code EUSAGE
npm ERR! Automatic provenance generation not supported outside of GitHub Actions

We're calling npm publish in node from GitHub Actions' own @actions/exec, from within a GitHub Action. You'd think this would be sufficiently within GitHub Actions, but apparently not.

I've had a look at the example NPM package that successfully published using provenance linked to from the blog, and they appeared to use changesets, which uses publishScript = core.getInput("publish") from @actions/core. Presumably that's more wired in to the GitHub Actions publish API than exec which could run anything?

So if there are no objections or other suggestions, I'll see if it's possible to refactor our publish step to use core.getInput("publish") instead of exec.

AlanSl commented

Side note - I lost some time due to some issues with Optic Expo on iOS: the first 3-4 publish actions passed automatically without requiring verification (the app's internal notifications counter was +1ing its red number each time, but not actually showing the "do you want to continue" message). Then, the app started crashing to home screen any time I tried to open the notifications screen, and publish actions started failing with 403 errors, presumably timing out waiting for a response from the app. I switched to the Android version of Optic Expo and that worked as expected, showing the notification.

I'll write up a bug report on the Optic Expo repo later, and maybe I could pick that issue up next after this one?

Thanks for all the insights Alan, very valuable:

  • Node version: this is true unless we're using a specific node version within the action. The action is composite but we're using the github-script action to execute node code, so I can't tell for sure which version of Node that will be using, we probably need to double check this https://github.com/nearform-actions/optic-release-automation-action/blob/main/action.yml
  • Ideally provenance is configurable, although, at least for our own purposes, we will probably want it enabled by default. But whether we enable it by default or not very much depends on whether it needs any additional setup to make it work, because if that's the case we can't, at least not without releasing a major version, as it would be a breaking change. If it doesn't require additional set up instead, then I'd say it should be the default. I mean, why would you NOT want it?
  • The user doesn't control which Node version this is running on, so no point in excluding the provenance flag in case Node is old in my opinion
  • for the error about it not working with the error "npm ERR! Automatic provenance generation not supported outside of GitHub Actions", well we need to figure out how to make it work, possibly requiring changes to the action
  • yeah the app is probably not thoroughly tested. I am the main user of the optic expo app and I run it with Expo Go. Note that this change is somewhat independent of the app. If you use the action you don't necessarily have to use 2FA
AlanSl commented

Quick update: I've got it working:

image

There's a few non-obvious pitfalls (not least an NPM-side error fixed in the NPM version that ships with Node 20 but still present in the NPM version that ships with Node 18,where the wrong error message is shown in some misconfiguration states) so there might be a blog post in this.

Also re. the question "Is there any reason not to enable provenance?" - there's a couple of requirements like permissions fields and required package.json fields where it'll fail if they're not present (with potentially misleading messages if on a Node 18 CI). So options are maybe:

  1. We check those fields ourselves, and opt-in to provenance by default but only if we see that the known criteria are met and adding --provenance won't cause the release to error out?
  2. Or, we ignore that stuff unless a provenance flag is provided, and if it is, check the requirements and fail-fast the release if they're not met (to avoid doing a release that causes the NPM page to lose its provenance, since it was specifically requested)?

Amazing, thanks. What you list are good reasons not to enable provenance by default, at least not for now.

Next steps are:

  1. make any necessary changes to the source of this action to make this work
  2. create docs in the readme of this action to describe how to enable provenance and what implications it will have

Once this is done:

  1. we surely want to go around and enable provenance on all our repos where we use this
  2. great topic for a blog post and some publicity for the action

๐ŸŽ‰ This issue has been resolved in version 4.5.0 ๐ŸŽ‰

The release is available on:

Your optic bot ๐Ÿ“ฆ๐Ÿš€