-
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
Add pipeline strawman example #1
Conversation
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 |
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.
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".
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 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.
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.
Yeah, that would be very helpful to explicitly state - it wasn't quite what I had taken away from prior convos
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 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 |
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.
Minor nit, does it make sense to introduce Task
before TaskRun
?
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.
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.
examples/README.md
Outdated
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)): |
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.
Looks like this link would be broken?
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 for catching this!
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.
hm and that file is in fact missing XD - watch this space
- name: 'testBucket' | ||
type: 'gcs' | ||
url: 'gcs://somebucket/results/tests' | ||
status: |
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.
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
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.
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.
b1b3e12
to
70968b4
Compare
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.
some nits.
examples/deploy_tasks.yaml
Outdated
- name: clusterName | ||
buildSpec: | ||
steps: | ||
# TODO: just guessing how helm works |
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.
remove this todo
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.
lol but it's still true! XD
okay i'll remove it ;)
prevTasks: | ||
- taskRef: | ||
name: unit-test-kritis-12321312984 | ||
conditions: |
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.
Add a comment here, this will be auto filed by the controller?
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.
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: |
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.
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.
70968b4
to
49d2316
Compare
@bobcatfish - Could you please explain what's |
Thanks for asking @nrshrivatsan !
I've also opened #25 to make this more clear in our docs. |
Initial commit for OpenShift CI
Add pipeline strawman example
Initial commit for OpenShift CI
Add initial list of owners for event triggering ⚡
Add pod SPIFFE id annotation for workload registrar
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
@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 forTaskRun
!