-
-
Notifications
You must be signed in to change notification settings - Fork 300
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
Conversation
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? |
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. |
something like this: |
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? |
Because this is merged already, I think a new one is necessary. |
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. |
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 |
Hmm, that fix didn't seem to work here. wondering CR_PAT doesn't have the permission needed |
The PR is not, but the tag is created automatically in the JS repo in the release workflow. |
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
Though that token is a personal token and I am the administrator of those repos, so that could make a difference. |
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 |
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 I just did a test run of this in my fork and it worked |
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. |
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... |
@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... |
The release workflow is running now. |
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 |
Maybe we should figure out if there's an action for that so we do not do it manually. It may help. |
This release workflow works quite well for gl-js to npm. 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. |
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? |
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. |
Indeed, but something in the current workflow made you Birk the releasing user, not |
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 |
Also note that in the Qt release workflow I added
to the job. Not sure where I copied it from but this may add more permissions to |
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. |
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. |
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)
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