Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(issue 285): Add provenance support #294

Merged
merged 19 commits into from
May 3, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 40 additions & 10 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -84,14 +84,20 @@ jobs:
contents: write
issues: write
pull-requests: write
# optional: `id-token: write` permission is required if `provenance: true` is set below
id-token: write
steps:
- uses: nearform-actions/optic-release-automation-action@v4
with:
npm-token: ${{ secrets.NPM_TOKEN }}
optic-token: ${{ secrets.OPTIC_TOKEN }}
commit-message: ${{ github.event.inputs.commit-message }}
semver: ${{ github.event.inputs.semver }}
npm-tag: ${{ github.event.inputs.tag }}
# optional: set this secret in your repo config for publishing to NPM
npm-token: ${{ secrets.NPM_TOKEN }}
# optional: set this secret in your repo config for 2FA with Optic
simoneb marked this conversation as resolved.
Show resolved Hide resolved
optic-token: ${{ secrets.OPTIC_TOKEN }}
# optional: NPM will generate provenance statement, or abort release if it can't
provenance: true
```

The above workflow (when manually triggered) will:
Expand All @@ -111,6 +117,7 @@ When you merge this PR:
- Upon successful retrieval of the OTP, it will publish the package to Npm.
- Create a Github release with change logs (You can customize release notes using [release.yml](https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes#example-configuration))
- Leave a comment on each issues that are linked to the pull reqeuests of this release. This feature can be turned off by the `notify-on-the-issue` flag.
- _(Optional)_ If `provenance: true` was set, NPM will add a [Provenance](#provenance) notice to the package's public NPM page.

When you close the PR without merging it: nothing will happen.

Expand Down Expand Up @@ -220,17 +227,40 @@ Please note that in case of a prerelease the `sync-semver-tags` input will be tr

## Provenance
simoneb marked this conversation as resolved.
Show resolved Hide resolved

NPM will [generate a provenance statement](https://docs.npmjs.com/generating-provenance-statements) for your releases if the following conditions are met:
If `provenance: true` is added to your `release.yml`'s **inputs**, NPM will [generate a provenance statement](https://docs.npmjs.com/generating-provenance-statements).

NPM has some internal [requirements](https://docs.npmjs.com/generating-provenance-statements#prerequisites) for generating provenance. Unfortunately as of May 2023, not all are documented by NPM; some key requirements are:

- `id-token: write` must be added to your `release.yml`'s **permissions**
- NPM must on version 9.5.0 or greater (this will be met if our recommended `runs-on: ubuntu-latest` is used)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only main outstanding thing I need to understand and we need to decide if we want to do something about.

The action at the moment uses whatever version of Node is installed in the runner, which you already figured out should be good enough when using the built-in runners (ubuntu specifically, but let's assume this is true for the others too).

Yet there is a way for us to force a specific version of Node by using the setup-node action from within our action. This would allow us to make sure we install a recent node version, meaning that we would know provenance would work (thereby allowing us to remove much of the npm-version-specific logic you have written), yet I'm not sure if the action forcing a certain node version is a sensible decision for this action. We just never had this problem before, but maybe it's just about the right time we think about it.

Copy link
Contributor Author

@AlanSl AlanSl May 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say no because it adds maintenance burden on our side (we'd need to choose when to update now and in future) and seems to go against least-surprise: right now, there's a very clear division of responsibility, where the user-side yml sets up the environment and runner, then our script runs inside their environment.

I'd thought about this, there's a few ways we could do it if we wanted to, the least obtrusive I could think of was adding something like "engines": { "npm": ">=9.5.0" } to package.json, which is better than specifying a node version because it allows users to be more up to date (e.g. they can jump to Node 20 before we do), and it doesn't impose on node version when all we have any reason to care about is NPM version.

But even that felt a bit heavy-handed for an opt-in feature. If a user wants an old NPM version (e.g. IIRC some projects stick to 8.5 to avoid side effects of changes to dependency resolution), and they don't care about provenance, there's really nothing wrong with that and no reason to stand in their way. Just tell them why it didn't work if they do try out provenance.

- NPM has some undocumented internal requirements on `package.json` completeness. For example, the [repository field](https://docs.npmjs.com/cli/v9/configuring-npm/package-json#repository) is required, and some NPM versions may require its `"url"` property to match the format `"git+https://github.com/user/repo"`.

- In the `.yml` file that configures your release action:
- Add `provenance: true` to your list of **inputs**
- Add `id-token: write` to your list of **permissions**
- Ensure your CI runner uses NPM >= 9.5.0 (should be the default if Node >= 18)
- Ensure your `package.json` is complete and correct. NPM will cancel the release with specific errors if it finds a problem. Requirements may change in future NPM releases but include things like a `"repository"` field with `"url"` property matching the format `"git+https://github.com/user/repo"`.
If any requirements are not met, the release will be aborted before publishing the new version, and an appropriate error will be shown in the actions report. The release commit can be reverted and the action re-tried after fixing the issue highlighted in the logged error.

If `provenance: true` is in your YML inputs and any condition isn't met, the release will cancel with an error.
The above [example yml action](example) includes support for Provenance. To add provenance support to an existing action, add these two lines:

```yml
jobs:
release:
runs-on: ubuntu-latest
permissions:
contents: write
issues: write
pull-requests: write
# add this permission which is required for provenance
id-token: write
steps:
- uses: nearform-actions/optic-release-automation-action@v4
with:
npm-token: ${{ secrets.NPM_TOKEN }}
optic-token: ${{ secrets.OPTIC_TOKEN }}
commit-message: ${{ github.event.inputs.commit-message }}
semver: ${{ github.event.inputs.semver }}
npm-tag: ${{ github.event.inputs.tag }}
# add this to activate the action's provenance feature
provenance: true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering if there's a way to highlight certain lines using github code highlighting

Copy link
Contributor Author

@AlanSl AlanSl May 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems not, sadly:

```

If you run a release without `provenance: true` when a previous release had provenance, the provenance banner on your package's NPM landing page will be removed but the banner will remain on the subpage for the previous release.

## Inputs

Expand Down