##[error]Bad credentials

GitHub Actions
#1

We’re trying to use the svenstaro/upload-release-action in CosmoScout VR. While it works very nicely for our workflows running on Linux, it somehow fails with this error on a Windows host.

##[error]Bad credentials

Here is the error: https://github.com/cosmoscout/cosmoscout-vr/runs/234662696#step:7:8

Here is the according workflow file: https://github.com/cosmoscout/cosmoscout-vr/blob/feature/actions/.github/workflows/release.yml

After some testing, it seems that a significant difference between our workflow jobs are the build times: Linux takes only 30 min while Windows requires around 1.5 h. If the build times are lowered artificially, the upload works just fine. Can it be possible that the credentials provided by GitHub expire to quickly?

Related issue at the action’s repository: https://github.com/svenstaro/upload-release-action/issues/1

Edit: Today, after one week, I verified that this issue still persists… Is this a known bug or am I doing something wrong here?

3 Likes
#2

This is still an issue…

#3

While I did not get any response yet, I found an official documentation on this issue!

The installation access token expires after 60 minutes. GitHub fetches a token for each job, before the job begins.

So as a workaround, will use a personal access token instead of secrets.GITHUB_TOKEN.

4 Likes
#4

The only way to make it work seems to be using a separate job for release creation and pass the files between them via artifacts: https://help.github.com/en/actions/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts#passing-data-between-jobs-in-a-workflow.

Which is very inconvenient and a lot of boilerplate!

1 Like
#5

Using a separate job and passing artifacts using upload/download doesn’t work, unforutnately.  The expiry timer seems to kick off when the workflow containing the jobs start,  not when the job starts.  I tried the multi-job approach and got the same bad credentials result, even though the job that used those was  configured to start only after the long-running build job ended (via needs).  Now that I’m reading the docs carefully, that’s what it says:

Note: When a workflow run or its jobs are queued for more than one hour, the token may expire before the job starts.

For jobs the want to use credentials after the expiry period, the only way seems be to create and use a Personal Access Token

1 Like