Tags: mrtoms/pipeline
Tags
Omit NotFound when cleaning up the Affinity Assistant The PipelineRun reconciler cleanup the affinity assistant when the PipelineRun is completed. If the cleanup-function is called more than once, the DELETE request will return a NotFound response. It does not make sense to return NotFound responses as an error, since this is what we want to achieve. (cherry picked from commit 204a403)
Disable keep-alive for cloud-event connections Disable keep alive forces the HTTP client to drop the connection once a response is received. This avoids building up large numbers of idle connections and it fixes the immediate issue. After this we may want to see how to ensure we can re-use connection and also set and idle-connection timeout. Fixes tektoncd#3190 (cherry picked from commit 7a9a85b)
Add support for repeated PVC-claim but using subPath in AA-validation The validation for compatibility with the Affinity Assistant does not support the same PVC repeated, but using different subPaths. This patch adds support for this case and tests for the validation. Co-authored-by: Scott <sbws@google.com>
Ensure pullrequest-init is based on a root image 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.
Ensure pullrequest-init is based on a root image 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.
Add pipeline run support for cloud events Replace the pipeline run controller own config store with the shared one used by the taskrun controller too. The pipeline run config store is only useful to the artifact storage, however the artifact storage loads the config by fetching the configmap via the kube client, so it does not use the config store. Attaching the shared config store to the controller, along with the cloud events client, enables the pipeline run controller to start sending cloud events for all events where we send k8s events today (except for error ones). Add a reconciler unit test to verify that events are sent when the sink is configured. Drop reconciler/pipelinerun/config because it's not used. It was injected in the pipeline run controller before, but not used. We can add the store for artifact configs back in a different commit, but it wil have to be part of the shared store. (cherry picked from commit e6c91d2) Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Revert "Remove creds-init intContainer" This reverts commit bbb767c. In tektoncd#2671 I removed the creds-init initContainer from Task Pods so that credentials could be used by containers running with non-root users. The intention was for this change to be free of any side-effects to end-users. Unfortunately a [backwards incompatible issue](tektoncd#2951) has cropped up with this change: When a user does not specify the `known_hosts` field in a creds-init Secret, the credential code will perform an `ssh-keyscan` of the remote server to get its public key. The problem is that previously we could guarantee `ssh-keyscan` was available since the code ran in our own creds-init container with our own docker image. Since we've now moved that code into Steps' entrypoint the Steps container is required to provide `ssh-keyscan`. This is a change in container contract and therefore backwards-incompatible. In this PR I've reverted the creds-init change for the 0.14 branch rather than attempt to fix the `ssh-keyscan` issue and possibly introduce more problems. Before 0.15 I'd like to get a better backwards-compatible fix organized. So I plan to leave the creds-init change in place in the `master` branch for the time being.
PreviousNext