-
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
TEP-0097 breakpoint before steps for taskrun #7391
TEP-0097 breakpoint before steps for taskrun #7391
Conversation
/kind feature |
/assign @chitrangpatel @lbernick |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
5ffee60
to
e15525f
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-build-tests |
e15525f
to
49f4641
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
49f4641
to
c5befb0
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: chitrangpatel 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 |
c5befb0
to
9e2e2f3
Compare
i have reased, but it doesn't seem to work, I'll try test again later |
The following is the coverage report on the affected files.
|
yeah I think we are still being affected by the ongoing rate pull effect which exists for 6 hours!! |
/test pull-tekton-pipeline-alpha-integration-tests |
/test pull-tekton-pipeline-build-tests |
00e2654
to
49779a3
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
49779a3
to
02a269e
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
02a269e
to
4052462
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
4052462
to
88240b8
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
Signed-off-by: chengjoey <[email protected]>
88240b8
to
b7ee47e
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
@chitrangpatel , now all the checks have passed~ |
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.
Thank you for this! Just a few minor comments, otherwise it looks good!
Please let me know if you prefer to merge this and address the comments in a follow-up PR.
### Breakpoint before step | ||
|
||
|
||
TaskRun will be stuck waiting for user debugging before the step execution. |
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.
NIT: The TaskRun
will be wait for use input before starting the execution of the step
|
||
|
||
TaskRun will be stuck waiting for user debugging before the step execution. | ||
When beforeStep-Breakpoint takes effect, the user can see the following information |
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.
NIT: what's "beforeStep-Breakpoint"? If it is the name of a configuration option or variable please use the inline code-block, else please use a description in plain english i.e. "When the breakpoint before step takes effect"
1. Executing /tekton/debug/scripts/debug-beforestep-continue will continue to execute the step program | ||
2. Executing /tekton/debug/scripts/debug-beforestep-fail-continue will not continue to execute the task, and will mark the step as failed |
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.
NIT: please wrap the file-paths with inline code blocks (e.g. `code block`)
@@ -80,7 +95,13 @@ to reflect step number. eg: Step 0 will have `/tekton/debug/info/0`, Step 1 will | |||
### Debug Scripts | |||
|
|||
`/tekton/debug/scripts/debug-continue` : Mark the step as completed with success by writing to `/tekton/run`. eg: User wants to exit | |||
breakpoint for failed step 0. Running this script would create `/tekton/run/0` and `/tekton/run/0.breakpointexit`. | |||
onfailure breakpoint for failed step 0. Running this script would create `/tekton/run/0` and `/tekton/run/0/out.breakpointexit`. |
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.
NIT: breakpoint on failure
|
||
`/tekton/debug/scripts/debug-fail-continue` : Mark the step as completed with failure by writing to `/tekton/run`. eg: User wants to exit | ||
breakpoint for failed step 0. Running this script would create `/tekton/run/0.err` and `/tekton/run/0.breakpointexit`. | ||
onfailure breakpoint for failed step 0. Running this script would create `/tekton/run/0` and `/tekton/run/0/out.breakpointexit.err`. |
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.
Ditto
} | ||
|
||
// HaveBeforeSteps return true if have any before steps | ||
func (trd *TaskRunDebug) HaveBeforeSteps() bool { |
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.
NIT: to be consistent with other method names, this should be HasBeforeSteps
beforeSteps := sets.NewString() | ||
for i, step := range db.Breakpoints.BeforeSteps { | ||
if beforeSteps.Has(step) { | ||
errs = errs.Also(apis.ErrGeneric(fmt.Sprintf("before step must be unique, the same step: %s is defined multiple times at", step), fmt.Sprintf("breakpoints.beforeSteps[%d]", i))) | ||
} | ||
beforeSteps.Insert(step) | ||
} |
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's a pity that we cannot always validate here that the step names provided are actually valid (since resources are not resolved yet), but we could do so at least in the case of embedded specification.
We could validate the case of referenced spec at runtime too. Either case, silently ignoring non-existent step names would not be helpful for users, I think it would be better to fail the TaskRun
and report that a step on the list does not exists. WDYT?
This could be an enhancement in a follow-up PR if you agree.
} | ||
|
||
var ( | ||
errDebugBeforeStep = DebugBeforeStepError("before step breakpoint error file, user decided to skip the current step execution") |
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'm not sure I understand the meaning of this.
I'm guessing that "an error was encountered while waiting for the before-step breakpoint file because the user decided to skip the execution of the step"? Could you clarify?
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.
Maybe it could be rephrased as: "before-step breakpoint: step execution skipped by the user"?
logger.Fatalf("Error while handling task artifacts: %s", err) | ||
} | ||
output = append(output, artifacts...) | ||
e.appendArtifactOutputs(&output, logger) |
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's the reason for moving this code to a function? It does not help with testing and it is not re-used anywhere else.
checkForBreakpointOnFailure(e, breakpointExitPostFile) | ||
e.CheckForBreakpointOnFailure() |
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, but it seems unrelated to this PR.
Is the reason for making CheckForBreakpointOnFailure
public is to provide unit test coverage?
Thanks @afrittoli for your comments. Yes, I hope to merge this PR and fix the issues raised in your comments in a follow-up PR, and I will fix them before the next milestone. |
Merging now. |
Changes
breakpoint before steps for taskrun
TEP-0097
#5691
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes