Add types #2
Add types #2
Conversation
|
For folks interested in reviewing, the commit that contains the API types specifically is 362223b The rest of the code is mostly boilerplate built by kubebuilder that allows us to have controllers that can do some (very) basic validation. |
| apiVersion: apiextensions.k8s.io/v1beta1 | ||
| kind: CustomResourceDefinition | ||
| metadata: | ||
| creationTimestamp: null |
There was a problem hiding this comment.
can we skip the creationTimestamp filed if its always null?
| names: | ||
| kind: PipelineParams | ||
| plural: pipelineparams | ||
| scope: Namespaced |
There was a problem hiding this comment.
Is it a design goal that piplines and tasks are Namespace Scoped Vs Cluster Scoped?
If that is the case, we should clarify in the DD or document it somewhere.
There was a problem hiding this comment.
I'm pretty sure we want these to be namespace scoped, we should add this to the README
| // TODO(bobcatfish): when I use `metav1.Time` here I can't figure out | ||
| // how to serialize :( | ||
| LastTransitionTime string `json:"lastTransitionTime"` | ||
|
|
There was a problem hiding this comment.
@bobcatfish There are some examples of using metav1.Time in the knative/build repo (https://github.com/knative/build/blob/master/pkg/apis/build/v1alpha1/build_types.go#L193). What issue do you get when you try it?
There was a problem hiding this comment.
oh man! it was a doozy. the error looks like this:
status.conditions.lastTransitionTime in body must be of type object: "string"
This is the result of trying to kubectl apply -f with our samples (e.g. kritis-pipeline-run.yaml), which has content like:
conditions:
- type: Started
status: "True"
lastTransitionTime: "2018-10-04T12:25:39Z"
reason: manualTrigger
message: "Pipeline has been triggered manually"
I couldn't figure out what values to put in for lastTransitionTime that would satisfy the controller when using metav1.Time. It's also a bit odd to do this b/c usually the controller would be populating these values 🤔
There was a problem hiding this comment.
I believe it uses the time.RFC3339 format according to this: https://github.com/kubernetes/apimachinery/blob/master/pkg/apis/meta/v1/time.go#L114
which looks like this: 2012-11-01T22:08:41+00:00
There was a problem hiding this comment.
Thanks @pivotal-nader-ziada , I'll give that a shot!
There was a problem hiding this comment.
not sure what the issue was prior, changing to metav1.Time appears to be working now. made this change in the PR
There was a problem hiding this comment.
I am confused but happy! I will definitely take it :D
... you know, I wonder if I was using * metav1.Time????
There was a problem hiding this comment.
apparently "2018-10-04T12:25:39Z" was an okay format after all! ¯_(ツ)_/¯
| Branch string `json:"branch"` | ||
| Commit string `json:"commit,omitempty"` | ||
| ServiceAccount string `json:"serviceAccount,omitempty"` | ||
| } |
There was a problem hiding this comment.
is this only intended to support git commits or gcs buckets? maybe a generic interface with git and gcs types implementing it?
There was a problem hiding this comment.
Also can the Source be the output of the previous task?
There was a problem hiding this comment.
is this only intended to support git commits or gcs buckets? maybe a generic interface with git and gcs types implementing it?
Definitely we want to be able to support other sources than just git! It's not clear how exactly to design this though since some tasks might have logic that expects a git commit hash (e.g. naming an image)
I'll add an issue to our issue tracker shortly so we can dive into this more!
Also can the Source be the output of the previous task?
Oh neat! In the current design we didn't allow for that but do you think that's something folks would use?
There was a problem hiding this comment.
Can you let us know your thoughts about the other types of Sources and how to support a generic interface?
Yes, I think its useful to for example be able to build an image in a step and run tests on that image just built before uploading it in the following step. This would be need the ability to an input of a task to be a output of a previous task
There was a problem hiding this comment.
Can you let us know your thoughts about the other types of Sources and how to support a generic interface?
We're not sure yet but I'll tag you when I create an issue to track this investigation!
Yes, I think its useful to for example be able to build an image in a step and run tests on that image just built before uploading it in the following step. This would be need the ability to an input of a task to be a output of a previous task
Ah this is definitely something we support in the current design - however we are assuming the image is pushed to an image repository between steps, which is expensive! you can see what that could look like in this example https://github.com/knative/build-pipeline/blob/master/examples/pipelines/kritis.yaml#L37 where an image built in a previous step is provided as a parameter
There was a problem hiding this comment.
This makes it harder to make sure the testImage step is actually testing the image that was meant to be created in the buildPush step or picked up an older image because the push failed.
That's a great point. What do you think about being sure that the image is correct by making the digest available? @tejal29 has been suggesting we add an image type that could be an output and an in input - so a Task that builds an image could expose an image, including the digest, and the test Task could be given that image as an input via the Pipeline. (We also want to make sure we make use of the work already done to design build artifacts note doc shared with knative-dev@googlegroups.com).
One downside though is the extra overhead to upload the image to a registry in the build Task and then download it in the test Task :(
There was a problem hiding this comment.
The issue of knowing that the sources/inputs you're operating on throughout the pipeline stay the same came up at the build-crd working group meeting also, so maybe we should tackle the issue more generally as well 🤔
There was a problem hiding this comment.
Yeah, I agree the generic type of input/output might be the way to think about this, an image type can be one implementation, and git another.
We would need to indicate to a taskRun somehow that its input is the output of another taskRun
One downside though is the extra overhead to upload the image to a registry in the build Task and then download it in the test Task :(
Wouldn't we need to do that anyway for the test task to run against the new image?
I think your suggestion of having another issue to cover the design of Source input/output might be the best option to move this forward
There was a problem hiding this comment.
Created #11 to discuss particularly the issue of being sure you're using the sources/inputs you expect to be using.
There was a problem hiding this comment.
Also created #13 to explore sources in more detail!
DEVELOPMENT.md
Outdated
|
|
||
| You must install these tools: | ||
|
|
||
| 1. [`go`](https://golang.org/doc/install): The language `Knative Serving` is built in |
There was a problem hiding this comment.
"Knative serving" should be "Piplien CRD"
One of the examples demonstrates building an arbitrary pipeline for a project called `kritis`, mostly b/c folks who are working on this project have also worked on `kritis` and are familiar with it, but it's not actually relevant to `bulid-pipeline` directly. Tried to make this more clear in the docs. Also in #2 we had a question about what `strawman` means (not the first time this has come up!) A defintion is avialable at https://en.wikipedia.org/wiki/Straw_man_proposal but also mentions it is "american business jargon" so if we want to go on using that term we should define it. Instead I removed it from the one place it exists in our docs. Since no one has completely beaten up the proposal yet it seems to be graduating beyond the "strawman" phase - but correct me if I'm wrong :D
CI setup for master branch
CI setup for master branch
# This is the 1st commit message: change tutorial to getting-started # This is the commit message tektoncd#2: update some of the docs # This is the commit message tektoncd#3: Remove/Modify local registry setup This is a getting-started guide and if the user was able to get to this doc. It means they have access to the internet. It is probably easier for the user to create docker hub account then to setup a local image registry. It is probably more secure/convenient to push an image to docker hub with an api token that can revoked then depending on a local registry # This is the commit message tektoncd#4: change from we to you chaning we to you because it is the user doing the tutorial # This is the commit message tektoncd#5: change from we to you # This is the commit message tektoncd#6: parent 6328deb author popcor255 <popcor255@gmail.com> 1585337853 -0500 committer popcor255 <popcor255@gmail.com> 1585608100 -0400 Restoring tutorial.md There are alot of docs referencing to this doc. This doc will need to be removed eventually. However, I will keep in here for now Restoring bullet point that outlines the tutorial changing 'docker' to Docker remove 'also' from sentences change tekton piplines to Tekton Pipelines changed the logs and regred to have docker.io changed some of the output logs from the results of the instructions because they did not reflect the changes that were made correct grammar The namespace does not matter the tutorial will work either way Change pipeline Change pipeline and task with inline-yaml Remove/Modify local registry setup This is a getting-started guide and if the user was able to get to this doc. It means they have access to the internet. It is probably user for them to create docker account then to setup a local image registry. It is probably more secure to push an image to docker hub with an api token that can revoked then depending on a local registry change from we to you chaning we to you because it is the user doing the tutorial change from we to you Restoring tutorial.md There are alot of docs referencing to this doc. This doc will need to be removed eventually. However, I will keep in here for now Restoring bullet point that outlines the tutorial correct grammar The namespace does not matter the tutorial will work either way Change pipeline Change pipeline and task with inline-yaml # This is the commit message tektoncd#7: Restoring tutorial.md There are alot of docs referencing to this doc. This doc will need to be removed eventually. However, I will keep in here for now # This is the commit message tektoncd#8: Restoring bullet point that outlines the tutorial
ghost
mentioned this pull request
# This is the 1st commit message: allow dot character in resource names # The commit message tektoncd#2 will be skipped: # pipelinerun validation test update
Signed-off-by: Dan Lorenc <dlorenc@google.com> changed to use spiffe-csi Add pod SPIFFE id annotation for workload registrar Signed-off-by: Brandon Lum <lumjjb@gmail.com> removed spire jwt updated obtaining trust bundle Added SPIFFE entry registration and SVID entrypointer backoff (tektoncd#2) * Added SPIFFE entry registration and SVID entrypointer backoff Signed-off-by: Brandon Lum <lumjjb@gmail.com> * Allow SPIRE configuration through opts Signed-off-by: Brandon Lum <lumjjb@gmail.com> * Add validation of SpireConfig Signed-off-by: Brandon Lum <lumjjb@gmail.com>
# This is the 1st commit message: change emitting results # This is the commit message #2: fix code # This is the commit message #3: A few minor cleanups in pkg/reconciler/pipelinerun/pipelinerun_test.go These just mildly annoyed me, so I thought I'd clean them up. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com> # This is the commit message #4: Instrument e2e pipelinerun_test.go files for logstream These two (`test/pipelinerun_test.go` and `test/v1alpha1/pipelinerun_test.go`) weren't done in the last PR, because they were messy and I wanted to get that PR in. But I had some time this morning, so here they are, which should be the last things in the e2e tests (other than examples/yamls testing, which are their own bucket of worms) to be instrumented with `helpers.ObjectNameForTest(t)`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com> # This is the commit message #5: Update tutorial links We recently updated the introductory tutorial on the documnentation website. That tutorial covers the same content as the one here. To avoid duplicated efforts and content drift, I'm linkin that doc here and replacing the existing content. Additionally, this removes references to `PipelineResources`. # This is the commit message #6: Set git-clone tasks in examples to run as root Similar to tektoncd@ba2e7f3 - with tektoncd#4758, `git-init` now uses `ghcr.io/distroless/git` as its base image, and that image needs to run as root. `git-init` by default does _not_ run as root. So the two examples using copy-pasted old versions of the `git-clone` catalog task need to be changed to run as root, or the example tests will keep failing forever. An equivalent change will be needed in the `git-clone` catalog task once it's bumped to using `git-init:v0.35.0` or later - currently, it's using `v0.29.0`. Signed-off-by: Andrew Bayer <andrew.bayer@gmail.com> # This is the commit message #7: adding latest release - 0.35 Updating the table to include the latest release links. # This is the commit message #8: Added a unit test for pod status. Add unit test with large result for setTaskRunStatusBasedOnStepStatus.
This PR adds the basic Pipeline CRD types from the strawman examples. The types were created from a kubebuilder scaffold. These CRDs include:
Pipeline
PipelineRun
PipelineParams
Task
TaskRun
To install the types into a cluster you can use:
make installTo run the test suite:
make testFor more info on kubebuilder see:
https://book.kubebuilder.io/quick_start.html