-
Notifications
You must be signed in to change notification settings - Fork 68
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
semantic-release(/git) not using GH_TOKEN #196
Comments
What make you think it's related to not using Have you tried to push a commit to a protected branch with the same settings outside of semantic-release? |
@pvdlg We were trying to bypass the protection with a personal access token and couldn't achieve it. Now we managed to do it by setting a token in - name: Checkout project
uses: actions/checkout@v2
with:
token: ${{ secrets.GH_TOKEN }} Also, we no more need the - name: Semantic Release
run: yarn semantic-release
env:
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }} we use these plugins const plugins = [
'@semantic-release/commit-analyzer',
'@semantic-release/release-notes-generator',
'@semantic-release/changelog',
'@semantic-release/npm',
'@semantic-release/git',
] This makes me think that Any ideas of what we could oversee? |
It seems the error happens based on how the repo was cloned... Not sure why. If that helps here is how semantic-release interact handle repo authentication:
I don't know what GitHub is doing exactly when verifying permissions for protected branches nor what |
It seems the action set the token in In semantic-release we don't do that as we don't want to leave a token behind in a file on the CI. I don't know why the branch protection behave differently in those 2 cases. They should be equivalent. |
@pvdlg I just noticed that in our logs semantic-release outputs Might that be a problem? I can't see //EDIT: |
That's expected. As I explained earlier:
Because
No. As explained earlier semantic-release already adds the token to the URL when necessary. |
@pvdlg I see myself having the same problem. I can 't understand it:
Isn't basic auth this |
yes it is. So? I don't understand what you are asking. |
@Duchynko provided a workaround, which also works in my repositories with protected branches:
@pvdlg: any chance to look into this behaviour or at least add a documentation for it? |
Setting - name: Checkout
uses: actions/checkout@v2
with:
persist-credentials: false
- name: Release
run: yarn semantic-release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} According to the actions/checkout@v2 docs:
|
@anpa your answer really saved a lot of time! Huge thanks! |
This should be documented in the Github Actions recipes. |
I've had the same issue and can confirm that @anpa 's solution works a treat. Additionally that solution doesn't poses a security risk in the steps between checkout and release. |
I tried to use @anpa's solution but it did not work quite well for me. Because:
So I ended up with:
jobs:
release:
runs-on: ubuntu-latest
needs: build
steps:
- uses: actions/checkout@v2
with:
token: ${{ secrets.GH_TOKEN_SEMANTIC_RELEASE }}
- name: Use Node.js 12
uses: actions/setup-node@v1
with:
node-version: 12
- run: npm ci
- run: npm run release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
NPM_TOKEN: ${{ secrets.NPM_TOKEN }} Summary:
This way, I hope this helps some of you. :-) @cycjimmy you might want to update your documentation, since, I believe, it's the most "official" place we have this workaround documented so far. |
@felipecrs Hope this helps with your setup.
It does though. I'm using the following snippet in my release and the "default"
Hopefully this helps, this is a snippet from the release steps I'm using in multiple projects. I'm using the environment variables to have the GitHub release and commits as a specific user, @vidavidorra-release in this case. This behaviour is described in semantic-release/git documentation. FYI you can get the ID for an "anonymous" email via the GitHub API, e.g. https://api.github.com/users/vidavidorra-release. steps:
- name: Checkout
uses: actions/checkout@v2.3.3
with:
# Make sure the release step uses its own credentials.
persist-credentials: false
- name: Setup node
uses: actions/setup-node@v2.1.2
with:
node-version: 14
- name: Install project
run: npm ci --ignore-scripts
- name: Build
run: npm run build
- name: Release
env:
GITHUB_TOKEN: ${{ secrets.SEMANTIC_RELEASE_GITHUB_TOKEN }}
GIT_AUTHOR_NAME: vidavidorra-release
GIT_AUTHOR_EMAIL: 65564857+vidavidorra-release@users.noreply.github.com
GIT_COMMITTER_NAME: vidavidorra-release
GIT_COMMITTER_EMAIL: 65564857+vidavidorra-release@users.noreply.github.com
NPM_TOKEN: ${{ secrets.NPM_PUBLISH_TOKEN }}
run: npx --no-install semantic-release Edit: I see you wanted to have the release created as the @github-actions user, for which you can use the following environment variables.
|
Actually, that was not what I meant. I meant this: Because in @anpa's example, it uses
TYVM for the tip, very nice. However, I don't understand. Your solution is more complex than mine, what benefit it brings? |
I misunderstood it first, but got it now. It would make sense that GitHub actions doesn't allow you to make a
The benefit, for me at least, is that semantic release uses the PAT for creating commits with a specific user which it couldn't do with the default |
Yes, that's the main problem we're trying to solve here. The solution I proposed works just fine.
Got it.
That's a point. However, as per semantic-release, they recommend having a unique job for the release, which should run after the test job passes, but in a clean environment. So, as long as you follow this, your job will only perform the release. So I think there is no need to worry. |
This gives the bot access so it has permission to push to a restricted branch Source: semantic-release/git#196 (comment)
this should really be documented somewhere, as github actions is a very common tool to use this with, and also because branch protection rules are common practice, and this is not obivous and you usually only find out about it on these threads. should I make a PR? |
According to semantic-release/git#196 @semantic-release/git plugin should also work with the regular token when persist-credentials: false
This hopefully enables us to leverage required status checks in protected branches, as described here[^1]. Closes #3 [^1]: semantic-release/git#196 (comment)
## [1.0.2](v1.0.1...v1.0.2) (2022-07-06) ### Bug Fixes * do not persist token after git checkout ([70e6d09](70e6d09)), closes [#3](#3) [/github.com/semantic-release/git/issues/196#issuecomment-601310576](https://github.com//github.com/semantic-release/git/issues/196/issues/issuecomment-601310576)
This is a (hopeful) fix for release actions not triggering after the semantic release. See semantic-release/git#196.
matches this example now semantic-release/git#196 (comment)
First of all, thanks @anpa @felipecrs @jdbruijn , your solutions worked like a charm 🎉 Summarising here the core issue and some solutions. It will help myself think what to choose, so maybe it helps someone too :) IssueAs @anpa mentioned, the core issue is that
And given WorkaroundsCheckout without persisting credentialsThen semantic release actually configures the authentication. Enabling you to use the provided GitHub Personal Access Token for all operations when specifying Checkout with GitHub Personal Access Token (PAT)Then PAT is used for TipsUse GitHub no reply email as author / committer emailWhen configuring semantic release, so that commits & tags are related to your account. Instead of semantic release user, which is this plugin's default Updated docs link about no reply email: Extra findingsFine grained tokensCan be used to assign less privileges to the Personal Access Token. If using the token for all operations (no persist credentials workaround), you'll need to grant contents, issues and pull requests read/write access for the repository you're configuring. If using the Personal Access Token only for commit / tag operations (checkout with PAT token), read/write access for contents of the repository will be enough. Verified tagsIf not using the default provided As opposed when using default provided
Not even if using the tip to set the This is because semantic release uses the Hope it helps 😊 |
I have tried like this
and like this
And both of the times I receive the same output.
|
If we don't set this to not persist credentials, semantic release will not set the github token and releases fail in repos that have branch protection turned on. Refs: - semantic-release/git#196 (comment) - semantic-release/git#196 (comment)
If we don't set this to not persist credentials, semantic release will not set the github token and releases fail in repos that have branch protection turned on. Refs: - semantic-release/git#196 (comment) - semantic-release/git#196 (comment)
Did you set permissions right?
|
We're trying to push a commit to the protected master-test branch with Github Actions after a pull request is merged (on push to master-test). I generated a personal token with appropriate access to our repo (having an admin role) but noticed that the token is probably not being used (in Personal access token settings on GitHub).
I went through the documentation, followed each step, but still can't make it work. I've also tried to use GIT_CREDENTIALS env variable, without success.
We're using:
release.config.js
action setup
output from the job
The text was updated successfully, but these errors were encountered: