-
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
Adding pipeline results #2042
Adding pipeline results #2042
Conversation
The following is the coverage report on pkg/.
|
/area api |
39b676b
to
8d96f29
Compare
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/retest |
2947409
to
40054a7
Compare
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
Something that occurs to me reading through this: It looks like we allow the user to only use a single isolated variable substitution in a given parameter. In other words they can't do something like:
Where the expected value here would end up looking something like "ci-991f807-ephemeral" and in this example would be the name of an ephemeral namespace or something that is deployed to when a PR is being tested. I need to check what variable substitution looks like with other fields. I have a hunch that this kind of thing is supported with others and we'd probably want the same kind of support here as well. Will look into it and update this PR with a comment. |
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 good so far! I've left some comments from an initial read-through and I want to get your feedback before I comment on the code any more.
Oh yeah. Didn't think about that. I don't think it would be too hard to implement that behavior. though theres something to think about that is the desired behavior. Since results are taken verbatim form the contents of the result file that the task lays on disk, we might run into a bunch of issues with newlines when performing the substitutions in embedded cases like the one you mentioned. In that example, if the task laid down the SHA like so (newline at the end):
would turn into
We could strip newline to prevent this, but that might be a bad idea as we likely don't want to alter the users output. |
@sbwsg I'm trying to rework all the variable substitution right now to use the jsonpath.Expand func from PR #1951 everywhere so that kind of logic isn't reimplemented a zillion times. I just hadn't realized it was such a huge job. @eddie4941 we're so close to the beta that if it's easy to implement in the current way it would be good even if we re-implement a little bit later.
...as the value of the JSON string which I believe is what we want. Meaning the new line lives on when it's extracted to a regular string. Going the other way that means you don't have to encode the new-line as it is a legitimate String character (DM me if that's confusing as hell) |
OK, I've run a test this morning to see what happens if you wrap a pipeline's param into a larger string being passed into a Task's param and it looks like it operates as mentioned. The pipeline's param is interpolated into the rest of the string contents. [1]
Great point. I had not thought about newlines being included here. My feeling is we should clearly document the behaviour initially and start considering changes such as trimming the whitespace only if users really struggle with it. My guess right now is that so long as we are passing the result values around verbatim that users will quickly learn to remove extra whitespace from the result values they emit from their tasks. This also sounds like a good thing to watch out for when we start updating tasks in the Catalog to emit their results. [1] Here's the quick example pipeline I wrote up to check the params behaviour: apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
name: print-message
spec:
inputs:
params:
- name: message
type: string
description: "The message to print"
default: "hello world"
steps:
- name: print
image: ubuntu
script: |
#!/usr/bin/env bash
echo "$(inputs.params.message)"
---
apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
name: add-octopus-arms
spec:
params:
- name: message
value: "o.O"
pipelineSpec:
params:
- name: message
type: string
description: "The figure to wrap in octopus arms"
tasks:
- name: add-octopus-arms
taskRef:
name: print-message
params:
- name: message
value: "~~$(params.message)~~" |
Example from a catalog entry of trimming newline when storing to a result here: https://github.com/tektoncd/catalog/pull/182/files#diff-1239eb0a6238e01666691e444b6367b7R55 It would be cool if this were handled for the user but it's not a huuuuge headache as it stands. Just |
40054a7
to
88c637c
Compare
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
I am doing a rebase on top of the v1beta1 change. This will require a |
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
/retest |
/test tekton-pipeline-unit-tests |
unit tests are passing locally, but they fail when run as automated tests. Investigating. |
The following is the coverage report on pkg/.
|
20244f9
to
2a86059
Compare
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
ca3bb5c
to
9d410d4
Compare
The following is the coverage report on pkg/.
|
Since the move to v1beta1, the test |
57881d6
to
3e8c9b7
Compare
The following is the coverage report on pkg/.
|
The following is the coverage report on pkg/.
|
f45a541
to
38ec513
Compare
The following is the coverage report on pkg/.
|
ok problem came from the validation of names. Fix pushed. |
re-adding the earlier lgtm /lgtm 🤞 |
🎉 |
Changes
Adding the ability to reuse task results into other tasks within the same pipeline
Fixes #1978
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Reviewer Notes
Release Notes