-
Notifications
You must be signed in to change notification settings - Fork 268
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
Display placeholders for pipeline tasks that haven't begun executing yet #1869
Conversation
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.
Cool, that full task tree will be a nice change. Removing the parameter for sorting might be a breaking change but with alpha components i guess its at your own risk ? 😅
/approve
/lgtm
On the PipelineRun details page, display placeholders for pipeline tasks that don't yet have a corresponding TaskRun. Fill in spec details where available so the user can still view the definition. Once the pipeline task begins executing the placeholder will be replaced with the real TaskRun and corresponding details. In the case of Conditions, we make a best effort to display placeholders for the TaskRuns generated to evaluate them. Once they execute we will display the correct TaskRun details, however before this is available the placeholder may be incomplete and may become unselected as the PipelineRun updates. This is due to a lack of required runtime information to produce a consistent link between the resources. Since Conditions are deprecated, we're not planning to invest further effort in improving this. This update also changes the ordering of TaskRun in the TaskTree component. Instead of sorting by start time of the first step in each TaskRun, they're now sorted in order of definition in the Pipeline. A nice (subj.) side effect of this is that retries for a given TaskRun will be displayed immediately following the corresponding TaskRun rather than interspersed among other TaskRuns in an often unpredictable order. Future changes to the display of retries will further improve this grouping.
0cb9c14
to
ece0880
Compare
@steveodonovan rebased and resolved the merge conflict, good to go again. Thanks
Technically yes but it was never documented and defaulted to disabled anyway so 🤷 As far as I know the Dashboard itself was the only user of that prop. Hopefully anyone who poked around in the code, found it, and was using it, will prefer the new 'more correct' behaviour 😅 |
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
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: steveodonovan 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 |
Changes
Resolves #1263
Resolves #932
On the PipelineRun details page, display placeholders for pipeline tasks
that don't yet have a corresponding TaskRun. Fill in spec details where
available so the user can still view the definition.
Once the pipeline task begins executing the placeholder will be replaced
with the real TaskRun and corresponding details.
In the case of Conditions, we make a best effort to display placeholders
for the TaskRuns generated to evaluate them. Once they execute we will
display the correct TaskRun details, however before this is available
the placeholder may be incomplete and may become unselected as the
PipelineRun updates. This is due to a lack of required runtime information
to produce a consistent link between the resources. Since Conditions are
deprecated, we're not planning to invest further effort in improving this.
This update also changes the ordering of TaskRun in the TaskTree component.
Instead of sorting by start time of the first step in each TaskRun, they're
now sorted in order of definition in the Pipeline.
A nice (subj.) side effect of this is that retries for a given TaskRun
will be displayed immediately following the corresponding TaskRun rather
than interspersed among other TaskRuns in an often unpredictable order.
Future changes to the display of retries will further improve this grouping.
Before:
After:
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide
for more details.