-
Notifications
You must be signed in to change notification settings - Fork 112
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
Surface error results to BuildRun #930
Surface error results to BuildRun #930
Conversation
Continuation of #901. As requested by @adambkaplan, I have split the error surfacing logic from the git error reporting. |
5a6317c
to
07f0af5
Compare
recreating the reviewer list from previous PR: /unassign @qu1queee |
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.
Nice work. Please also extend the buildstrategy.md. Give some guidance on how the two results can be filled - and important: to fail the buildrun, the step still must return a non-zero exit code. We can add examples in later PRs into our sample build strategies.
b9475f3
to
98399e3
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.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: SaschaSchwarze0 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 |
c743d21
to
51a348e
Compare
my 2 comments / suggestions have been addressed - thanks @dalbar @otaviof @adambkaplan @coreydaley - as being assigned to this PR, do you all want to take a review at this before it gets the lgtm tag? If so, please do so. If not, unassign yourselves and we'll from there (I might be able to take a more detailed pass before my EOB today). thanks |
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.
Most of my comments here are stylistic recommendations. Since build results are effectively "user generated," I recommend that we establish a convention for the provided reason
in our documentation and code.
const ( | ||
resultErrorMessage = "error-message" | ||
resultErrorReason = "error-reason" | ||
prefixedResultErrorReason = prefixParamsResultsVolumes + "-" + resultErrorReason | ||
prefixedResultErrorMessage = prefixParamsResultsVolumes + "-" + resultErrorMessage | ||
) |
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.
These constants should be moved to pkg/apis/build/v1alpha1
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.
What is your reasoning for that? It is currently only used in the resources package.
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.
+1 to Baran's assessment. The constants are an implementation detail because we use them on the TaskRun internally but in the BuildRun they are copied into "normal" fields in the status. -> Somebody who uses our Go types does not need to know these constants.
d67c464
to
f5c483f
Compare
f5c483f
to
595e7d0
Compare
595e7d0
to
0add676
Compare
0add676
to
da542ee
Compare
4d9505d
to
495654b
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.
@dalbar generally looks good - please squash your commits and then I think we can lgtm this.
495654b
to
819300f
Compare
Thanks. I have squashed the commits. |
@dalbar Have you seen these verify remarks:
Can you run a |
d189b90
to
3ef1606
Compare
I did and the command did not yield any changes. |
@dalbar, Please try the following steps:
|
According to ship 0024, this commit adds a mechanism to surface errors from TaskRun steps. The errors are published under `status.failure` in BuildRun iff underlying TaskRun has failed.
3ef1606
to
3a2e93d
Compare
The remaining TODOs (squashing commits and running /lgtm |
Changes
This PR provides a mechanism to surface errors in the build process into BuildRun objects granting more visibility into without being Tekton/Implementation specific. To achieve this goal, we introduce two new generic results
shp-error-reason
andshp-error-message
, that a TaskRun can emit and a BuildRun can pick up.Initial implementation for ship 24.
/kind feature
/kind api-change
Submitter Checklist
Release Note