Closed GeoffreyHayward closed 2 months ago
The issue was that a tagged commit contained a change to another workflow, so while this workflow was not making a change (i.e. in the yml file), the command git push --force --no-verify origin tag prd
was enough to trigger a permission issue.
By running the command locally, where permission is not an issue, the tags moved along and allowed the subsequent workflow run to continue.
The error message didn't have enough information in it to make it clear that the tagged commit had the issue (i.e. what it was doing), as opposed to the workflow itself (i.e. how it was doing it).
This issue is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 15 days.
This issue was closed because it has been stalled for 15 days with no activity.
I am suddenly getting a permission error in two workflows that used to work. The error message states a permission error for another workflow, but this workflow is not imported/called/referenced by either of the workflows. The message/reason appears to be erroneous.
The only change to these workflows is they have been renamed. However, after the rename, one of the two continued to work (finish successfully), before this sudden issue began. As you can see here.
Before the rename, the two workflows have been in service successfully for several months.
Here is the error message:
But, it is important to understand that
master-to-uat-workflow.yml
is not included or a part of the workflows that are getting given this error.The two workflows are:
The expected behaviour was to continue running
git push --force --no-verify origin tag prd
via a Make command. This command moves the git tags to reflect what's in production.Runner Version and Platform
They are both using Ubuntu latest.
What's not working?
A permission error is given. However, the permission error looks to be an erroneous message/reason.
But just in case, I have checked that the GITHUB_TOKEN has full permission on the Repo and the Org, and we do not have an Enterprise account (so no policies). I have also tried giving the workflows inline full read-write permission.
Further, I have tried this on a fork and cannot reproduce the issue. The fork finishes successfully.
Job Log Output
Runner and Worker's Diagnostic Logs
logs_13326.zip
Other
I have tried duplicating the files to see if new (not renamed) files worked. They did not work and got the same error message.