[Question]: persistCredentials: true - Token Only Lasts For 1 Hour?

[v1ferrarij]

Describe your question

I have been working on a pipeline which builds VM Images in Azure, due to the nature of the pipeline, the pipeline takes more than 1 hour to complete.

At the end of the pipeline when the build of the image completes, we want to tag our repository.

I have found that if a pipeline runs for longer than 1 hour, persistCrendentials: true becomes redundant, it appears as though the credentials expire, thus meaning I cannot run git commands at the end of the pipeline.

Is this expected behaviour, could you add an option to extend the token life time?

Versions

Azure DevOps Services

Environment type (Please select at least one enviroment where you face this issue)

• [X] Self-Hosted
• [X] Microsoft Hosted
• [ ] VMSS Pool
• [ ] Container

Azure DevOps Server type

dev.azure.com (formerly visualstudio.com)

Operation system

Ubuntu 22.04

Version controll system

Git

Azure DevOps Server Version (if applicable)

No response

[DmitriiBobreshev]

Hi @v1ferrarij, thank you for the question, 60 minute is default timeout for the jobs, you can increase that time by passing timeoutInMinutes parameter in the job.

[v1ferrarij]

Hi @DmitriiBobreshev I think there is confusion with the question I asked. My issue is not around job time out, my question was around timeout for the OAuth token, I have no issues running jobs for over 60 minutes. Are you able to re-review the question please?

[DmitriiBobreshev]

Hi @v1ferrarij, sorry for the misunderstanding, are you using Azure Pipelines GitHub App for authentication?

[v1ferrarij]

Hi @v1ferrarij, sorry for the misunderstanding, are you using Azure Pipelines GitHub App for authentication?

Hey, No worries.

Yes we are using GitHub App for auth.

We use this task for auth, but it appears as though whatever token this produces only last for 1 hour, I have also tried putting the step further down the pipeline, but the same issue occurs.

steps:
- checkout: self
  persistCredentials: true
  fetchDepth: 0

[DmitriiBobreshev]

Got it, thanks! Yes, this is expected behaviour when you're using Azure Pipelines GitHub App for authentication. When you perform a checkout step it executes under a new token created by Azure Pipelines GitHub App and authenticates as a GitHub App installation, unfortunately, such tokens expire after 1hour and, unfortunately, we can't control the behaviour. .

[v1ferrarij]

Got it, thanks! Yes, this is expected behaviour when you're using Azure Pipelines GitHub App for authentication. When you perform a checkout step it executes under a new token created by Azure Pipelines GitHub App and authenticates as a GitHub App installation, unfortunately, such tokens expire after 1hour and, unfortunately, we can't control the behaviour. .

Ah okay that makes sense, do you know if the behaviour is different when using OAuth connection?

I have a workaround which is working, which was to put the Git commands in a separate job which only runs depending on the previous job, this works, but not ideal I guess.

[v1ferrarij]

@DmitriiBobreshev Hi again, Do you know if the access token this step sets includes permission to call the GitHub API ?

steps:
- checkout: self
  persistCredentials: true
  fetchDepth: 0

[DmitriiBobreshev]

Hi @v1ferrarij, The agent only receives the token from AzDevOps and using it, I believe the token has the same permissions as an installed AzDevOps Pipelines Application. Regarding the question about OAuth, the limitations probably will be the same,

Another option is you can pass GithubToken with limited scope as secret variable and use it inside a script as we do for agent's releases

[v1ferrarij]

Hey @DmitriiBobreshev Ah no worries, I managed to get the token from the step I sent, but it looks like the token does not have permission to call the GitHub API, only clone and read repos. I was trying to avoid setting up a token in GitHub as its more to maintain and port over to ADO. Thanks