We noticed this issue when using GitHub Apps but the problem would affect any pipeline I think. With GitHub Apps the token used to interact with GitHub is refreshed every hour, so if a pipeline runs for longer than the hour the .git_credentials file written during the creds-init step at the start of the pipeline becomes out of date for subsequent steps that need it.
Even though the issue is more obvious with GitHub Apps because of the short refresh time I should imagine any long running Pipelines that are in progress will suffer if the git token secret is updated in the cluster.
I "think" the way other applications which require a git token address this is by mounting the secret as a volume into the container, when the secret is updated in the cluster, operations in the pod can read the updated value without restarting.
As a thought, I'm wondering if we out to do a similar thing, i.e create a .git_credentials secret and have Tekton automatically add a volume to any pods and a volumeMount to any containers, then set the XDG_CONFIG_HOME to the mounted path location? Would that work?
Not sure, there's probably other options to consider and there may already be an alternative answer?
FWIW we're worked around the issue for now by reading the Git token directly from the secret in the pipeline when needed, this isn't ideal though as we don't want the pipeline service account to have permission to read secrets really.
Or an alternative could be to use a git credential helper that could read the token from the secret (or where ever it might be stored) when required?
@garethjevans ok interesting, could you give some more details about what a git credentials helper might look like and how commands like git and other libraries that use a git credentials file or token would use it?
/kind question
@rawlingsj I think https://github.com/tektoncd/pipeline/issues/1831 covers this scenario in a lot more detail
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
Most helpful comment
Or an alternative could be to use a git credential helper that could read the token from the secret (or where ever it might be stored) when required?