Test-infra: Documentations for using tekton with Prow

[yfei1]

I'm working on migrating a CI pipeline from Google Cloud Build to Prow, yet couldn't figure out a way to let the Prow native Kubernetes agent runs sequentially. It seems like Tekton agent provides the pipeline feature but I couldn't find related documentations for setting up Tekton with Prow.

Issue in Tekton: https://github.com/tektoncd/pipeline/issues/1187

[stevekuznetsov]

/cc @ccojocar @JoelSpeed @cjwagner

[JoelSpeed]

Our experience is that there isn't really documentation at the moment, that said we did manage to get a working pipeline.

You'll need to:

• Deploy a Pipeline controller
• Define and deploy your Pipelines and Tasks
• Define a Pre/Postsubmit that uses a pipeline_run_spec
• Deploy the Tekton pipelines controller and it's supporting components

Note the PROW_IMPLICIT_GIT_REF in the Presubmit definition. This is some Prow magic that will be replaced by a PipelineResource pointing to the Git repo and commit you are testing. (This took me a while to figure out). This will then act as an input to your Pipeline which you can then pass as input to your tasks.

While this works and the pipeline runs, there is very little observability into the runs at present which means I can't recommend pushing this to "production", the issues we identified that block us are:

• No persistent logs from pipeline runs
• No integration with Deck/Spyglass
• No integration with presets, you have to manually configure them on the tasks
• Uncertain if syntax is liable to change. Pipelines and tasks may become embedded in PipelineRunSpec (see https://github.com/tektoncd/pipeline/issues/872)
• Compatibility with private repos is also an unknown

I don't know if any of this has changed since we made our evaluation a few weeks ago, I know this is a very active area of development for Prow at present and things are moving quite quickly

[ccojocar]

I wanted to write some docs for installation since quite a while but I haven't had much time. Thanks @JoelSpeed for providing some details above. The install process is a bit tedious at the moment.

[bobcatfish]

No persistent logs from pipeline runs

Issue in the tekton backlog possibly relevant to your interests @JoelSpeed : https://github.com/tektoncd/pipeline/issues/1155 ( + @sbwsg )

[bobcatfish]

Thanks for writing this up @JoelSpeed !! I was able to get Prow + Pipeline working thanks to this write up :D

Quick note: it looks like the crier component is also required now when the agent type is something other than kubernetes ( thanks @krzyzacy + @BenTheElder !! ❤️ )

[eddycharly]

Is there a way to construct the PipelineResource differently than with the PROW_IMPLICIT_GIT_REF magic ?

Some kind of template in the pipeline_run_spec maybe ?

My goal is to pass the branch name to the pipeline, i guess prow uses the commit hash as revision argument to the PipelineResource. I tried to use ${inputs.resources.git.revision} in my task and it is indeed the commit hash.

Is there a way to pass the branch name to the pipeline in a separate argument ?

[cjwagner]

I'm not sure how constructing the PipelineResource differently would help you pass the branch name to the pipeline, but if your goal is to just determine the branch name from within a pipeline you can already do that using the PULL_BASE_REF pipeline parameter. All ProwJob environment variables are defined here and pipeline ProwJobs use pipeline Params to pass the values instead of actual environment variables. https://github.com/kubernetes/test-infra/blob/91fce157bfe50b475d6ecf5d9fb27ec9e3aec49f/prow/cmd/pipeline/controller.go#L627-L639

[eddycharly]

@cjwagner i just checked, prow injects the variables in the PipelineRun resource like this :

  params:
  - name: BUILD_ID
    value: "1188889208643653632"
  - name: JOB_NAME
    value: tekton
  - name: JOB_TYPE
    value: presubmit
  - name: PROW_JOB_ID
    value: ee0b566e-f9b2-11e9-a511-06179cedbf44
  - name: PULL_BASE_REF
    value: master
...

PULL_BASE_REF contains the target branch of the pull request, is there any way to have the source branch also ?

[cjwagner]

No, the source branch is a branch from the source repo which can be the upstream repo, but is typically a fork repo, so the source branch doesn't necessarily exist in the upstream repo that the presubmit checks out. Why do you need to know the name of the source branch given that it doesn't necessarily even exist in the repo we are checking out?

[eddycharly]

I see your point, I didn’t think about forks.
I wanted to setup an environment related to the pull request, I will use the pull request number instead as it is available.
Thanks.

[fejta-bot]

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: 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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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.