-
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
Migrate yaml e2e test from knative/build #493
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: shashwathi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
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 migrating all these yaml files, but I found it hard to find them.
One of the benefits of these files in the build repo is to show examples of how to write your own build, or task in our case, and in their current location with no clear reference to them from any docs, most people will not see them
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 great @shashwathi ! 🎉🎉🎉
This looks like it was a lot of work, thanks for taking it on!! I think it's super cool to see proof now that we support all the same functionality of Build/BuildTemplates! I mean we're using exactly the same code as Build but still v cool to see :D
- There are a few references to "build" and/or "build crd" in the examples that we might want to update
- What do you think about getting rid of the
run
directory all together, having all the examples in the top levelexamples
dir, one file per complete example? I think it's a bit unclear at the moment why some of the examples live at the top level and get special explanation in the README and some don't
I followed the pattern suggested by Jason to include relevant k8s, knative objects in same yaml separated by
---
.
I like it! The idea of each yaml being a self contained example is nice :D
either feature is not supported(like failure labels)
I think that's reasonable! We have end to end tests, and pretty decent unit test coverage, so I think it's okay to leave out the negative examples
I have not intentionally added all tests because either feature is not supported(like failure labels) or better examples are already present in repo like task template params.
Would it be a crazy amount of work to include in the commit message which ones were skipped and why? Makes it easy to make sure none were skipped that shouldn't be, and also I can see us having to compare the examples b/w the repos again a couple more times as we migrate development completely away from knative/build
|
||
It uses `kubernetes.io/dockercfg` secret type but, | ||
`kubernetes.io/dockerconfigjson` and | ||
[Knative flavored credentials](https://github.com/knative/docs/blob/master/build/auth.md#guiding-credential-selection) | ||
are supported too. | ||
|
||
## Results |
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.
ooo nice! maybe put a link to this section at the top?
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.
just bumping 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.
README is pretty small so is there any value in having link at top?
build.knative.dev/docker-1: https://eu.gcr.io | ||
build.knative.dev/docker-2: https://asia.gcr.io | ||
build.knative.dev/docker-3: https://gcr.io | ||
build.knative.dev/docker-4: https://reduce-chance-of-selecting-gcr.io |
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 these should be something else, maybe pipeline.knative.dev
? (not sure if this actually works tho 😅 )
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.
It does not work. Is this something we need a separate issue or tackle it in this PR?
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.
oh yeah separate PR then for sure i think! separate issue even
c27b641
to
413f056
Compare
Done. Updated commit msg to include yamls that were not migrated
I think I have addressed it all. Let me know if I missed something
I think there are cases like replacing image path with KO_DOCKER_REPO which needs instructions in README but I agree rest of them don't need it I guess. I tried with Few tasks are referenced in taskruns and pipelinerun so there will be copies of same tasks repeated in multiple files. is that okay? |
0c9acd8
to
32b4923
Compare
32b4923
to
a22854a
Compare
/hold cancel |
a22854a
to
22b6f7b
Compare
@bobcatfish : one of build yaml tests relied on volume source templating and that feature has not implemented yet. |
871f0ee
to
fa078a6
Compare
@@ -89,5 +89,14 @@ func ApplyReplacements(build *buildv1alpha1.Build, replacements map[string]strin | |||
steps[i].VolumeMounts[iv].SubPath = templating.ApplyReplacements(v.SubPath, replacements) | |||
} | |||
} | |||
|
|||
// Apply variable expansion to the build's volumes |
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.
neat!!
Generally looking great but a couple doc requests:
Hm I could go either way! If we decided to not duplicate them, I think
I'm fine with same PR but can we add some docs on this to our templating docs? |
fa078a6
to
d7833ba
Compare
Done. Added an example. Let me know what you think
I have duplicated tasks and made them all self contained. README contains instruction on how to apply, what to change in yaml files and how to check results. Let me know if I missed anything. |
d7833ba
to
abc14d4
Compare
e2e test failure was not related to the PR. I have added an issue to fix this separately. I am going to re-trigger the tests for now |
/test pull-knative-build-pipeline-integration-tests |
Fixes tektoncd#302 what: Add yaml tests which cover different features of knative build in knative build pipeline like mounting secret as volume, templating arguements. list build yamls tests are not added: - build with `source` key. As build added support for multiple sources build examples included both `source` and `sources` key version of build. In taskrun world it means the same thing (https://github.com/knative/build/tree/master/test/sources) - build subpath feature is not supported in taskrun (https://github.com/knative/build/tree/master/test/subpath) - build with multiple steps(https://github.com/knative/build/tree/master/test/multiple-steps). taskrun contains examples with multiple steps - build that panics (https://github.com/knative/build/tree/master/test/panic). Taskrun with expectation to fail is not supported in yaml - build with timeout (https://github.com/knative/build/tree/master/test/build-with-timeout). Taskrun with timeout test is already present in e2e go test - build with custom source. Taskrun does nto support custom source (https://github.com/knative/build/tree/master/test/custom-source) - build that fails (https://github.com/knative/build/tree/master/test/fail). Taskrun does not support failed taskruns - build with step status (https://github.com/knative/build/tree/master/test/step-status). go e2e tests already cover this feature - build yaml tests git-init image directly. This is indirectly testing git resource and does not add much value. (https://github.com/knative/build/tree/master/test/reuse-git-init)
why: Build supported this feature and one of the build yaml test relies on this feature what: Taskrun can template volumes names and config volume sources
abc14d4
to
161aa81
Compare
Really nice work @shashwathi !!! The examples dir is looking great :D :D :D Thanks for catching and fixing those issues we'd missed as well ❤️ - and thanks for taking this on, hope it wasn't too tedious 😅 /lgtm |
In response to this:
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. |
Fixes #302
Add yaml tests which cover different features of knative build in knative build pipeline like mounting secret as volume, templating arguments.
I followed the pattern suggested by Jason to include relevant k8s, knative objects in same yaml separated by
---
. Test file names should sufficiently explain the taskrun but if anybody feels strongly about adding more docs, please leave comment on what would be ideal place for this documentation.I have not intentionally added all tests because either feature is not supported(like failure labels) or better examples are already present in repo like task template params.
cc @imjasonh