-
Notifications
You must be signed in to change notification settings - Fork 112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure the git resolver with the GitHub API token #1333
Configure the git resolver with the GitHub API token #1333
Conversation
/assign @afrittoli |
/test check-pr-has-kind-label |
@abayer: The specified target(s) for
In response to this:
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. |
/assign @dibyom @lbernick @vdemeester |
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 <andrew.bayer@gmail.com>
@abayer is there a way to test this/have you tested this? (maybe at least build w/ kustomize and see what the diff is compared to the dogfooding cluster?) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you'll have to update https://github.com/tektoncd/plumbing/blob/main/tekton/cd/pipeline/overlays/dogfooding/kustomization.yaml as well
I'm asking @afrittoli about this in the productivity WG in a few minutes. =) |
Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com>
4f7f3d1
to
89dcc40
Compare
kustomization has now been updated! |
And I've verified (after copying https://storage.googleapis.com/tekton-releases/pipeline/previous/v0.44.0/release.yaml into |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @abayer
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jerop The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
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 <andrew.bayer@gmail.com>
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 <andrew.bayer@gmail.com>
Changes
I'm not 100% sure if this is right - specifically, this is trying to write to the
git-resolver-config
ConfigMap
in thetekton-pipelines-resolvers
namespace, but I put it in the same directory as the rest of the pipelines overlays. @afrittoli - I think this should work correctly, but I defer to you. =)/kind misc
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide
for more details.