-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Align release-generated .ko.yaml with repo config #3018
Conversation
This resolves disparities between the .ko.yaml normally used to build images during development with the one generated and used during a release (to ensure git-init and creds-init are built on the just-built build-base image) This won't prevent future drift.
/kind cleanup |
/test pull-tekton-pipeline-integration-tests |
/lgtm nice! |
/kind cleanup |
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.
/lgtm
/test check-pr-has-kind-label |
/kind cleanup |
https://dashboard.dogfooding.tekton.dev/#/namespaces/tektonci/taskruns there is a check-labels that seems stuck.. 🤔 |
@imjasonh fixed now 😉 |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dlorenc 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 |
The PullRequest Resource, when used as an output, is able to read in a pr.json to determine if there have been any changes that require syncing to github. pr.json may have been written by any prior Step with any ownership settings. If pr.json was written with root permissions then the PullRequest Resource needs to be have permissions to read that file. The PullRequest Resource image has been based on a nonroot image in our `.ko.yaml` since 0.13 of Tekton Pipelines ([`.ko.yaml` was updated here](#2606)). However, the published images did not match the configuration in the `.ko.yaml` until 0.15.0 ([our `tekton/publish.yaml` was brought into line with `.ko.yaml` here](#3018)). Given that copying or writing pr.json in a Step can result in the file being owned by root using a nonroot image is not a suitable choice of base image - the output PullRequest attempts to open pr.json and hits a permissions error. This commit updates the PullRequest image to be based on distroless static instead of nonroot and adds an example yaml file that should exercise the behaviour of copying the file from an input to output pullrequest resource.
The PullRequest Resource, when used as an output, is able to read in a pr.json to determine if there have been any changes that require syncing to github. pr.json may have been written by any prior Step with any ownership settings. If pr.json was written with root permissions then the PullRequest Resource needs to be have permissions to read that file. The PullRequest Resource image has been based on a nonroot image in our `.ko.yaml` since 0.13 of Tekton Pipelines ([`.ko.yaml` was updated here](tektoncd#2606)). However, the published images did not match the configuration in the `.ko.yaml` until 0.15.0 ([our `tekton/publish.yaml` was brought into line with `.ko.yaml` here](tektoncd#3018)). Given that copying or writing pr.json in a Step can result in the file being owned by root using a nonroot image is not a suitable choice of base image - the output PullRequest attempts to open pr.json and hits a permissions error. This commit updates the PullRequest image to be based on distroless static instead of nonroot and adds an example yaml file that should exercise the behaviour of copying the file from an input to output pullrequest resource.
This resolves disparities between the .ko.yaml normally used to build
images during development with the one generated and used during a
release (to ensure git-init and creds-init are built on the just-built
build-base image)
This won't prevent future drift.
#3007
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.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes
/cc @dlorenc @vdemeester