Replies: 4 comments 1 reply
-
Adding: I have no custom Rules or Protected Tags rules in this repository. So it can't be that either. I do wonder if it's a bug in the new Protected Tags feature though. |
Beta Was this translation helpful? Give feedback.
-
I replaced the action with an equivalent script to try and help with debugging, - uses: actions/github-script@v7
with:
script: |
async function run() {
const {data: tag} = await github.rest.git.getRef({
...context.repo,
ref: "tags/v2.0.1"
});
console.log(tag);
const sha = tag.object.sha;
console.log(sha);
const x = await github.rest.git.updateRef({
...context.repo,
ref: "v2",
sha: sha,
force: true
});
console.log(x);
}
await run(); Here's the full error that can be seen now:
That documentation URL repeats the same advice:
Which, according to the "Setup Job" step this Job indeed has.
|
Beta Was this translation helpful? Give feedback.
-
I have the exact same problem. Itworks if I use PAT, but not with GITHUB_TOKEN. |
Beta Was this translation helpful? Give feedback.
-
Sorry for not reporting back, but I eventually discovered that the action of moving a tag from SHA GitHub never allows bots to change workflows content under any circumstances. This is completely separate from the workflow permissions or repository rules, and there is no way to bypass it. PAT is the only solution. |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
I have an action that is attempting to update the major version tag (
v2
) to point to a release tag (v2.0.1
). I've copied this workflow from here. My repository is here, its workflow is here, and an example failure is here.The workflow errors with "Resource not accessible by integration"
The code that's being run and failing is ultimately,
So this is saying an attempt to update a ref is getting a 403. Googling that gets you lots of obvious answers around granting the correct permissions (
contents:write
). But my permissions are 100% correct, as visible here:Even the default token gets read-write as per the repository Settings anyway. And even if I change this to
write-all
, the error still occurs.There must be something else going on and it's driving my bananas. Something dumb like the tag not really existing (and 404 being presented as 403), or release tags being special, I'm just not sure. Hopefully someone can spot it?
I was able to successfully run
git tag v2 v2.0.1
locally, so I'm relatively confident this should work.Beta Was this translation helpful? Give feedback.
All reactions