Skip to content
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

Add pipeline strawman example #1

Merged
merged 1 commit into from
Sep 5, 2018
Merged

Add pipeline strawman example #1

merged 1 commit into from
Sep 5, 2018

Conversation

bobcatfish
Copy link
Collaborator

@dlorenc @imjasonh @tejal29 @aaron-prindle and I have been working on a
strawman proposal for adding a Pipeline CRD and also for possibly
envolving the Build CRD into a slightly more generic Task CRD.

This PR demonstrates some paper prototype examples of what it could look
like to define pipelines using the CRDs described in the README.

Was originally at knative/build#319 - but this version actually has a PipelineRun and status fields for TaskRun!

README.md Outdated
A library of build pipelines
# Pipeline CRD

The goal of the Pipeline CRD is to provide k8s-style resources that allow the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing that I suspect people will wonder about when they read this doc that we might want to clarify is whether the Pipeline CRD is supposed to be an API+implementation, or an API that can be backed with an arbitrary implementation similar to Kubernetes ingress. The impression I was left with after the last working group meeting is that the goal was the former, not the latter. Is that correct? This phrase raised the question for me: "provide k8s-style resources".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I would classify this repo as "the API, and an on-cluster implementation of that API". Like ingress, or serving, or build, etc., one can imagine a CRD implementation that is backed by something off-cluster, or that just uses the API for compatibility and doesn't run "clusters" at all.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that would be very helpful to explicitly state - it wasn't quite what I had taken away from prior convos

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing this out @pmorie! I'll add something right at the beginning to try to make this clear.

README.md Outdated
[the Jenkins test analyzer plugin](https://wiki.jenkins.io/display/JENKINS/Test+Results+Analyzer+Plugin))
* [Tasks](#tasks) can depend on artifacts, output and parameters created by other tasks.

## TaskRun
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor nit, does it make sense to introduce Task before TaskRun?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think you're right - I had it the other way around before and then somehow got the crazy idea that this was clearer (I think b/c creating a TaskRun actually invokes the Task, kind of like creating a Build today will also run the steps in the Build) but I think you're right that introducing the Runs afterward makes more sense.

This directory contains examples of [the Pipeline strawman CRDs](../README.md) in action.

To deploy them to your cluster (after
[installing the CRDs and running the controller](../DEVELOPMENT.md#installing-andrunning)):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like this link would be broken?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for catching this!

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm and that file is in fact missing XD - watch this space

- name: 'testBucket'
type: 'gcs'
url: 'gcs://somebucket/results/tests'
status:
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm after a bit more thought and looking at @aaron-prindle's proposals around templating, I'm thinking the status section should also include the buildSpec with templating applied

Copy link
Contributor

@tejal29 tejal29 Sep 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes or a add a todo with a issue link describing templating proposal

EDIT: huh. Yes for the comment you had regarding @aaron-prindle proposal.
Github screwed this up.

Copy link
Contributor

@tejal29 tejal29 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some nits.

- name: clusterName
buildSpec:
steps:
# TODO: just guessing how helm works
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove this todo

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lol but it's still true! XD

okay i'll remove it ;)

prevTasks:
- taskRef:
name: unit-test-kritis-12321312984
conditions:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a comment here, this will be auto filed by the controller?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ya the whole status section will be filled out by the controller - ill add a comment

- name: 'testBucket'
type: 'gcs'
url: 'gcs://somebucket/results/tests'
status:
Copy link
Contributor

@tejal29 tejal29 Sep 5, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes or a add a todo with a issue link describing templating proposal

EDIT: huh. Yes for the comment you had regarding @aaron-prindle proposal.
Github screwed this up.

@dlorenc @imjasonh @tejal29 @aaron-prindle and I have been working on a
strawman proposal for adding a Pipeline CRD and also for possibly
envolving the Build CRD into a slightly more generic Task CRD.

This PR demonstrates some paper prototype examples of what it could look
like to define pipelines using the CRDs described in the README.
@bobcatfish bobcatfish merged commit 3726a43 into master Sep 5, 2018
@bobcatfish bobcatfish deleted the pipeline_strawman branch September 5, 2018 22:02
@nrshrivatsan
Copy link

@bobcatfish - Could you please explain what's kriti and strawman?

@bobcatfish
Copy link
Collaborator Author

@bobcatfish - Could you please explain what's kriti and strawman?

Thanks for asking @nrshrivatsan !

  • Kritis is a project that some folks on the team (notably @tejal29 and @aaron-prindle ) have been working on: https://github.com/grafeas/kritis It's not actually relevant to the build-pipeline project and is only included here as an example since we were familiar with how to build + test it
  • strawman is a term for a proposal that is created for the purpose of generating discussion and debate - so not necessarily the proposal you want to use in the long run, but a starting point - see also https://en.wikipedia.org/wiki/Straw_man_proposal

I've also opened #25 to make this more clear in our docs.

vdemeester referenced this pull request in vdemeester/tektoncd-pipeline Apr 3, 2019
Initial commit for OpenShift CI
chmouel pushed a commit to chmouel/tektoncd-pipeline that referenced this pull request Apr 11, 2019
chmouel pushed a commit to chmouel/tektoncd-pipeline that referenced this pull request Apr 11, 2019
pradeepitm12 pushed a commit to pradeepitm12/pipeline that referenced this pull request Jan 28, 2021
Add initial list of owners for event triggering ⚡
@wlynch wlynch mentioned this pull request Sep 24, 2021
3 tasks
lumjjb pushed a commit to lumjjb/pipeline that referenced this pull request Feb 8, 2022
Add pod SPIFFE id annotation for workload registrar
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 24, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 24, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 25, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 26, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 26, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 26, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline May 31, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline Jun 14, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline Jun 14, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
austinzhao-go referenced this pull request in austinzhao-go/pipeline Jun 14, 2022
Required fields and related webhook validations are added to support
a user to configure the computing resources per Task/Pod which significantly
reduces the over-asked amount configured by the step-level.
tekton-robot pushed a commit that referenced this pull request Jun 28, 2022
Required fields and related webhook validations are added to support
a user to configure compute resources for TaskRun which will significantly
reduce the over-asked resources amount configured by the Step-level.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants