"refusing to allow a bot to create or update workflow" when pushing tags on older commits

Code to Cloud GitHub Actions
#1

From within an action, I’m trying to modify tags to automate the versioning scheme recommended in the toolkit documentation: a “most recent major release” tag (such as v1) pointing at the most recent semantic versioning tag with the same major release, i.e., if I have tags v1.0.0, v1.0.1, v1.1.0, v1.2.0 and v1.2.1, then v1 should point to the same commit as v1.2.1. When I release v1.3.0, v1 should automatically be updated to point to what v1.3.0 points to.

To have access to all the tags, I check out the repository with all commits:

- name: 'Check out code'
      uses: 'actions/checkout@v2'
      with:
        fetch-depth: 0

The action runs a shell script in a Docker container, and I set the GITHUB_TOKEN in the environment:

- name: 'Update release tags for latest major and minor releases'
      uses: 'bewuethr/release-tracker-action@master'
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

According to the documentation for the checkout action, the auth token is persisted in the Git config, and indeed, I can do things like

git push --delete origin "$tag"

without problems.

However, after creating new tags, if any new tag doesn’t point to the most recent commit, I can’t push it and get an error message like this:

! [remote rejected] v0.1 -> v0.1 (refusing to allow a bot to create or update workflow `.github/workflows/releasetracker.yml`)

I’m trying to push nothing but the tags by using something like

git push origin "$tag1" "$tag2"

and definitely didn’t modify the workflow file.

From a shell script running in a docker action, how can I push my new tags pointing to older commits?

Things I’ve tried:

I’ve seen other people doing similar things by using the GitHub API instead of Git commands (like in the Branch Cleanup Action, where a branch is deleted using an API call), but is that the only way? It does feel like a bug that my push is prevented with a reason that doesn’t seem to apply to my situation.

I also haven’t tried using a personal access token instead of GITHUB_TOKEN, because again, it feels like it shouldn’t be necessary.

As a side note, posts with similar problems in this forum such as Refusing to allow an integration to create or update seemed to have “refresh the token of your client” as the solution, but that doesn’t apply in my case.

#2

Hi @bewuethr ,

The error is due to that GITHUB_TOKEN is used to update the tag. Please create a personal access token as secrets instead. Please follow below items to fix your code:

  1. In the workflow yaml, add ‘persist-credentials: false’ for ‘actions/checkout@v2’.

Use PAT for ‘bewuethr/release-tracker-action@master’.

Code sample as below:

jobs:
  release-tracking:
    runs-on: 'ubuntu-latest'
    steps:
    - name: 'Check out code'
      uses: 'actions/checkout@v2'
      with:
        fetch-depth: 0
        persist-credentials: false
    - name: 'Update release tags for latest major and minor releases'
      uses: '{org}/release-tracker-action@master'
      env:
        GITHUB_ACTOR: username
        TOKEN: ${{ secrets.PAT }}

  1. In the ‘tagupdater’ file, set remote url.

    git remote set-url --push origin “https://$GITHUB_ACTOR:$TOKEN@github.com/$GITHUB_REPOSITORY”

tagpush.png
tagpush.png817×296 17.2 KB

But there is a limitation that a new workflow is triggered again since PAT update the tag, and the workflow will fail.

Probably api call can work better.

Thanks.

1 Like
#3

Thanks, I half suspected I’d have to do it like that. I was mostly confused because some things such as deleting tags worked, and the error message “refusing to allow a bot to create or update workflow” is implying that I’m trying to do something with my worfklow, but I wasn’t.