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

Node release workflow #378

Merged
merged 129 commits into from
Sep 11, 2022
Merged

Node release workflow #378

merged 129 commits into from
Sep 11, 2022

Conversation

acalcutt
Copy link
Collaborator

@acalcutt acalcutt commented Jul 30, 2022

This is an attempt to create a node release workflow for #314

It is made to publish to github releases and the npm registry. It is based on what I am using for @acalcutt/maplibre-gl-native and https://github.com/acalcutt/maplibre-gl-native/releases. It is based on some ideas and conversation from @mnutt in #217

What this needs:
'Environment Secrets' set in github for 'NODE_PRE_GYP_GITHUB_TOKEN' and 'NPM_TOKEN'

NODE_PRE_GYP_GITHUB_TOKEN (needed to publish to github)

Within GitHub, create a new authorization:

go to Settings -> Developer settings
click [Personal access tokens](https://github.com/settings/tokens)
click Generate new token
Select public_repo and repo_deployment
Generate Token
copy the key that's generated and set NODE_PRE_GYP_GITHUB_TOKEN environment variable to it. Within your command prompt:
SET NODE_PRE_GYP_GITHUB_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

NPM_TOKEN (needed to publish to the maplibre npmjs registry)
This needs a maplibre npmjs token which has publish rights...like created here https://docs.npmjs.com/creating-and-viewing-access-tokens

Other Notes

  • I had to make two changes to node-pre-gyp-github . The first change made it target the 'main' branch instead of 'master'. The second makes the name include 'node-' to fit in with the other maplibre releases (so the name would be like 'node-v5.0.0' instead of 'v5.0.0').
  • Because there is no automatic versioning on this project, the version in package.json must be changed before running the node-release workflow.
  • I removed 'macos-11.0' and 'ubuntu-18.04' after making the node matrix because it was just to many jobs running. also 'ubuntu-18.04' had trouble building on node 18 due to dependencies not available in that OS. I was planning to use the newer MacOS OS, but was asked to use the older one for compatibility (the older os version would work on the newer od, but not the other way around)

@ntadej
Copy link
Collaborator

ntadej commented Sep 11, 2022

OK, we'll have to figure out how to bypass this. Do you have reviews disabled in JS or how do you do it there?

@birkskyum
Copy link
Member

birkskyum commented Sep 11, 2022

Review is not disabled in JS. We do manually update the version and Changelog in a PR, and hit release. It's maybe slower, but it feels very controlled and we don't publish releases often enough for it become annoying.

@birkskyum
Copy link
Member

something like this:
maplibre/maplibre-gl-js#1556

@acalcutt
Copy link
Collaborator Author

I tested enabling branch protection in my branch and saw the same thing. It looks like the second option here works, specifying a token with permission on the checkout https://stackoverflow.com/a/63733988

Should I submit the change to this PR or make a new one?

@birkskyum
Copy link
Member

birkskyum commented Sep 11, 2022

Because this is merged already, I think a new one is necessary.

@ntadej
Copy link
Collaborator

ntadej commented Sep 11, 2022

What you could also think of is to make an action to make a PR with the changelog updates and version bump and then one to do final processing when the tag is made. This could also work.

@acalcutt
Copy link
Collaborator Author

OK I added #466

For the tag, that gets created by node-pre-gyp-github which is already using a git token. we will have to see if that has the same issue

@acalcutt
Copy link
Collaborator Author

acalcutt commented Sep 11, 2022

Hmm, that fix didn't seem to work here. wondering CR_PAT doesn't have the permission needed

@birkskyum
Copy link
Member

birkskyum commented Sep 11, 2022

The PR is not, but the tag is created automatically in the JS repo in the release workflow.

@acalcutt
Copy link
Collaborator Author

In my repo I am using the NODE_PRE_GYP_GITHUB_TOKEN secret for this, which seems to be working for me. That was created like this, with public_repo and repo_deployment permissions

Within GitHub, create a new authorization:

go to Settings -> Developer settings
click [Personal access tokens](https://github.com/settings/tokens)
click Generate new token
Select public_repo and repo_deployment
Generate Token
copy the key that's generated and set NODE_PRE_GYP_GITHUB_TOKEN environment variable to it. Within your command prompt:
SET NODE_PRE_GYP_GITHUB_TOKEN=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Though that token is a personal token and I am the administrator of those repos, so that could make a difference.

@birkskyum
Copy link
Member

birkskyum commented Sep 11, 2022

I've adding my PAT (generated as you described) as a NODE_PRE_GYP_GITHUB_TOKEN in the repo. In principle that could allow skipping the branch protection. @acalcutt are you able to use the key from the script, and is public_repo and repo_deployment enough? @ntadej , what's your view on this approach? ... the strategy seems a bit dangerous to me.

@acalcutt
Copy link
Collaborator Author

This is what I am using in my branch, it is what the node-pre-gyp-github readme says to use for permissions and it seemed to work.

These are the only two checkbox checked in permissions
image

I just did a test run of this in my fork and it worked
https://github.com/acalcutt/maplibre-gl-native/actions/runs/3031922268

@birkskyum
Copy link
Member

birkskyum commented Sep 11, 2022

Maybe swapping secrets.CR_PAT with the PAT-key I just added "secrets.NODE_PRE_GYP_GITHUB_TOKEN" will resolve it then, because it has the same checkboxes marked.

@wipfli
Copy link
Member

wipfli commented Sep 12, 2022

When adding new secrets, please write down what they do in #312. We could also start adding some documentation about the build processes and secrets used in this repo...

@wipfli
Copy link
Member

wipfli commented Sep 12, 2022

@birkskyum as a Governing Board member you have access to our Bitwarden key manager. Do you think it would make sense to store clear-text passwords and keys there as well? I am asking because maybe it is enough if we just document well how the secrets were generated and who has access to them...

@birkskyum
Copy link
Member

The release workflow is running now.

@acalcutt
Copy link
Collaborator Author

It looks like it all published correctly. One thing I notice though is it shows that it was published by birkskyum not github-actions. Most likely because we used your token for the version bump checkout/push

Also, I know you we asking about the security of this. I was thinking about that and I wonder what would could happen if someone moved that into a pr ci script. could they affect something real?

Maybe I should make NODE_PRE_GYP_GITHUB_TOKEN and NPM_TOKEN some type of enterable field so it's not part of the workflow? idk

@ntadej
Copy link
Collaborator

ntadej commented Sep 13, 2022

Maybe we should figure out if there's an action for that so we do not do it manually. It may help.

@birkskyum
Copy link
Member

birkskyum commented Sep 13, 2022

This release workflow works quite well for gl-js to npm.
https://github.com/maplibre/maplibre-gl-js/blob/main/.github/workflows/release.yml

I wouldn't mind taking the dangerous admin-push permissions away from the workflow, so we manually had to merge the updated version in package.json / package-lock.json / CHANGELOG.md before it publishes.

@acalcutt
Copy link
Collaborator Author

That looks like it also uses secrets.GITHUB_TOKEN and secrets.NPM_ORG_TOKEN, so possibly the same concern?

The PR ci workflow runs automatically with whatever workflow someone uploads.... so my thinking would be what happens if someone maliciously threw those secrets in a ci?

@birkskyum
Copy link
Member

birkskyum commented Sep 13, 2022

In that workflow, GITHUB_TOKEN is used to make a tag and a release, not push a commit, but if it has the same permissions I guess your concern is the same. I don't know what permissions were set for the GITHUB_TOKEN when it was created.

@ntadej
Copy link
Collaborator

ntadej commented Sep 13, 2022

Indeed, but something in the current workflow made you Birk the releasing user, not github-actions. Maybe GITHUB_TOKEN is enough and can replace NODE_PRE_GYP_GITHUB_TOKEN?

@acalcutt
Copy link
Collaborator Author

The permission we gave NODE_PRE_GYP_GITHUB_TOKEN we so node-pre-gyp-github could release the binaries. It just happended to work for that push too

@ntadej
Copy link
Collaborator

ntadej commented Sep 13, 2022

Also note that in the Qt release workflow I added

    permissions:
      contents: write

to the job. Not sure where I copied it from but this may add more permissions to GITHUB_TOKEN.

@birkskyum
Copy link
Member

Also, regarding actions automatically running on a PR - it doesn't start workflows automatically for first-time contributors, but it's hardly a guarantee for anything.

@acalcutt
Copy link
Collaborator Author

On the plus side I tried testing it in https://github.com/acalcutt/tileserver-gl/tree/maplibre_pre and it seems to work as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants