Skip to content

Changes in permission-* handling since version 2.0.4 #248

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

Open
andrej-urvantsev opened this issue May 6, 2025 · 9 comments
Open

Changes in permission-* handling since version 2.0.4 #248

andrej-urvantsev opened this issue May 6, 2025 · 9 comments

Comments

@andrej-urvantsev
Copy link

Hi!

Could you please clarify changes in releases between 2.0.3 and 2.0.6?

Until version 2.0.4 we used to have following in our workflow(which uses App Token to push to protected branch)

        permission-metadata: read
        permission-contents: write

But after 2nd of May(versions 2.0.4 - 2.0.6) this stopped working and workflow started to fail with

Error:  The git-push command failed.
Error:  Command output:
Error: [ERROR] remote: error: GH006: Protected branch update failed for refs/heads/main.

However if we remove permission-* setting(so token inherits all permissions), then it works again.

Now, I'm a bit confused: is it we who did it wrong before v2.0.4, or something broke in the latest releases?

@ben-wilson-mews
Copy link

So glad you created this @andrej-urvantsev. I left on friday having completed a pipeline, happy with myself, got back from a bank holiday weekend to it broken 😆 I was so confused!

This screams regression, from what I've read on the docs, we're doing everything right. I'll see if I can debug the problem and tag the author of the commits

@ben-wilson-mews
Copy link

@Omochice I think this might be your PR - #246

@ben-wilson-mews
Copy link

It's not obvious if this is a regression or if there was some silent failures before. I can see some new retry logic if there's a >= 500 response code, but I'm getting a 422 response, which suggests that retry logic is a red herring and it's actually something else in the change, suggesting the payload is 👎

@ben-wilson-mews
Copy link

@gr2m could we get a revert on that PR please?

@ben-wilson-mews
Copy link

@parkerbxyz Actually I suspect it's #243, the previously linked one was a patch on top of that work. Given the 2.0.4+ tags being identified, this would be the likely culprit

@gr2m
Copy link
Contributor

gr2m commented May 6, 2025

but I'm getting a 422 response

That usually means you don't have the permission. What we fixed was the permissions setting, they actually work now. Before the recent changes, they actually had no effect.

I assume the permissions you set do not suffice for what you are doing with the token and it only started failing after we fixed the permission setting.

@gr2m
Copy link
Contributor

gr2m commented May 6, 2025

However if we remove permission-* setting(so token inherits all permissions), then it works again.

This also supports my assumption above.

To make it work again, remove all permission-* settings. But to make it work with as few permissions as possible, you'll have to figure out which permission is missing in your inputs that is required for the actions you want to take. By default, the token inherits all permissions from the installation. So if that works, try adding all the permissions to your inputs and then remove them one by one until you find the one you were missing.

@ben-wilson-mews
Copy link

@gr2m are you certain? I'm pretty confident my permissions are correct. I suppose I could narrow them down. The gist I got from his response is removing all permissions worked, not specific permissions.

@gr2m
Copy link
Contributor

gr2m commented May 8, 2025

Can you share

  1. Permissions of your installations
  2. The workflow file that uses actions/create-github-app-token, or at least the step where you set the permissions?

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

No branches or pull requests

3 participants