Git resolver timeout > 1m doesn't work #6025
Comments
|
Yup, because of that. I missed that |
|
A brief explanation of why this issue is occurring: When Pipelines sees a reference to a remote task or a remote pipeline, it creates a resolution request object that is labeled with the resolver that should handle the request. Resolvers, including the git resolver, watch for resolution requests to be created that they can handle. The git resolver will time out fetching something from git after the time configured in the git resolver feature flags. However, pipelines will cancel the resolution request after 1 minute. So if the git timeout is > 1m, the git resolver won't time out after 1m, but the request will get timed out anyway. One idea for solving this is to allow the resolver to update the resolution request with something indicating "resolution is in progress, please don't time this out". The global timeout would then only apply if the resolver hadn't updated the resolution request at all. |
|
/assign @EmmaMunley I can take this on. I think we can start with making the global timeout configurable, and later remove the git timeout if it's too confusing. |
fixes tektoncd#6091 (this can be merged before tektoncd/plumbing#1333, but it'd definitely be beter for that Plumbing PR to merge first) This switches how we resolve the `publish-release` `Task` in `release-pipeline` from an anonymous git clone to using the GitHub API. The full clone approach is almost always timing out, in part thanks to tektoncd#6025, but even if it finished successfully every time, it'd still be adding at least a minute of extra time to the pipeline execution for no particularly good reason. Using the GitHub API-based resolution instead means no clone is needed, with the resolver just making a couple very specific API calls to get the contents of the specified file. So yeah, much faster! Signed-off-by: Andrew Bayer <[email protected]>
fixes #6091 (this can be merged before tektoncd/plumbing#1333, but it'd definitely be beter for that Plumbing PR to merge first) This switches how we resolve the `publish-release` `Task` in `release-pipeline` from an anonymous git clone to using the GitHub API. The full clone approach is almost always timing out, in part thanks to #6025, but even if it finished successfully every time, it'd still be adding at least a minute of extra time to the pipeline execution for no particularly good reason. Using the GitHub API-based resolution instead means no clone is needed, with the resolver just making a couple very specific API calls to get the contents of the specified file. So yeah, much faster! Signed-off-by: Andrew Bayer <[email protected]>
fixes tektoncd#6091 (this can be merged before tektoncd/plumbing#1333, but it'd definitely be beter for that Plumbing PR to merge first) This switches how we resolve the `publish-release` `Task` in `release-pipeline` from an anonymous git clone to using the GitHub API. The full clone approach is almost always timing out, in part thanks to tektoncd#6025, but even if it finished successfully every time, it'd still be adding at least a minute of extra time to the pipeline execution for no particularly good reason. Using the GitHub API-based resolution instead means no clone is needed, with the resolver just making a couple very specific API calls to get the contents of the specified file. So yeah, much faster! Signed-off-by: Andrew Bayer <[email protected]>
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
tekton-robot
added
the
lifecycle/stale
|
/lifecycle frozen |
tekton-robot
added
lifecycle/frozen
|
/remove-lifecycle stale Please prioritize this issue since this is impacting timely completion of many pipeline runs relying on remote tasks |
vdemeester
added
the
priority/critical-urgent
Expected Behavior
Git resolution times out after the amount of time specified by "fetch-timeout" in the git-resolver-config configmap in the tekton-pipelines-resolvers namespace.
Actual Behavior
Resolution times out after 1m. Possibly because of this?
Additional Info
Kubernetes version:
Output of
kubectl version:Tekton Pipeline version:
Output of
tkn versionorkubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'The text was updated successfully, but these errors were encountered: