feat(core/pipeline): add execution UI for waitForCondition stage#6826
feat(core/pipeline): add execution UI for waitForCondition stage#6826erikmunson merged 6 commits intospinnaker:masterfrom
Conversation
|
The following commits need their title changed:
Please format your commit title into the form:
This allows us to easily generate changelogs & determine semantic version numbers when cutting releases. You can read more about commit conventions here. |
| labelComponent?: React.ComponentClass<IExecutionStageLabelComponentProps>; | ||
| markerIcon?: React.ComponentClass<{ stage: IExecutionStageSummary }>; | ||
| labelComponent?: React.ComponentType<IExecutionStageLabelComponentProps>; | ||
| markerIcon?: React.ComponentType<{ stage: IExecutionStageSummary }>; |
There was a problem hiding this comment.
some stuff — including these type changes — comes from the first commit where I tried to re-use some wait stage code before going down the execution window route. I removed the gluey bits from that approach but left any generic refactors like widening these types to support functional components.
| const inSuspendedExecutionWindow = stage.inSuspendedExecutionWindow; | ||
| if (inSuspendedExecutionWindow && executionMarker) { | ||
| const { suspendedStageTypes } = stage; | ||
| if (suspendedStageTypes.has('restrictExecutionDuringTimeWindow') && executionMarker) { |
There was a problem hiding this comment.
I think if we add one more stage to the list of suspend-able types, it'll make sense to make the stages themselves register a handler for this marker treatment. Until then the if/else seems mostly ok to me.
| @@ -0,0 +1,19 @@ | |||
| import { IExecution } from 'core/domain'; | |||
|
|
|||
| export const mapRunningStatusToSuspended = (execution: IExecution, stageType: string) => { | |||
There was a problem hiding this comment.
might be nice to name this function to indicate that it is mutating the stage
There was a problem hiding this comment.
maybe something like applySuspendedStatuses
There was a problem hiding this comment.
mmmmm i like, good idea
|
|
||
| export class WaitExecutionLabel extends React.Component<IWaitExecutionLabelProps, IWaitExecutionLabelState> { | ||
| constructor(props: IWaitExecutionLabelProps) { | ||
| export class WaitExecutionLabel extends React.Component<IExecutionStageLabelComponentProps, IWaitExecutionLabelState> { |
There was a problem hiding this comment.
I think it would be more consistent to name the interface IExecutionStageLabelProps
There was a problem hiding this comment.
While I agree that's a better name, the interface itself was already there (I just discovered and used it instead of the duplicate interface that was in this file before). I was hesitant to do a rename because two similar interfaces in IExecutionStage.ts have the same ComponentXyz naming.
Looking at the three similiarly-named interfaces, though, they're each only used in 2 or 3 spots so maybe a mass renaming is safe to do in this PR.
There was a problem hiding this comment.
do what you want
…85 and titus to 0.0.87 (#6855) * chore(core): Bump version to 0.0.351 f6c87a3 refactor(core/amazon): allow custom load balancer creation flow (#6852) 6ddc476 fix(titus): correctly set dirty field on command viewstate (#6795) 20d6766 feat(help): Custom help link (#6842) a9cfe57 chore: upgrade to react 16.8 (#6846) 2e4135a fix(pipeline/executionStatus): "details" link hidden by scrollbar. (#6850) af8fa5f feat(preconfiguredJobs): support produce artifacts (#6845) 48ba3fc fix(core/pipeline): un-shadow parameter (#6843) ec12527 feat(core/pipeline): add execution UI for waitForCondition stage (#6826) e17f387 fix(artifacts): HTTP default artifact needs reference field (#6836) e618548 feat(preconfiguredJob): logs for k8s jobs (#6840) 6072ee5 feat(core/pipelineConfig): toggle pins individually (#6830) c25363c fix(artifacts): Clean pipeline expected artifacts when triggers are removed (#6799) 5640431 fix(k8s): Fix deploy manifest (#6833) 2020bf6 feat(core/execution-parameters): condense parameters/artifacts and make it collapsable (#6756) 2d7f388 feat(kubernetes): feature-flagged support for kubernetes traffic management strategies (#6816) bcca9dc feat(core): Create pipeline from v2 template list d7e860c fix(triggers): Remove RunAsUser if pipeline permissions enabled for react triggers. (#6818) 1201896 fix(mptv2): clicking a view link on template list screen throws exception (#6815) 985a3ad fix(artifacts): helm artifact, replace object assignw with object spread (#6814) 2039b34 fix(artifacts): default helm artifact editor is broken (#6811) bdcbc97 fix(google): GCE create server group and load balancer fixes (#6806) * chore(docker): Bump version to 0.0.36 d7e860c fix(triggers): Remove RunAsUser if pipeline permissions enabled for react triggers. (#6818) * chore(amazon): Bump version to 0.0.185 f6c87a3 refactor(core/amazon): allow custom load balancer creation flow (#6852) 6ddc476 fix(titus): correctly set dirty field on command viewstate (#6795) * chore(titus): Bump version to 0.0.87 30556ad fix(titus): send serverGroupName when terminating instances (#6854) 6ddc476 fix(titus): correctly set dirty field on command viewstate (#6795)
3 participants
We've got a new stage called
waitForCondition. It's synthetically added (currently to Deploy stages) to delay subsequent stages until some conditions are met. The conditions are defined on the backend.This adds the usual execution UI bits you'd expect, with a twist: it uses the same patterns we originally built for execution windows. We chose this approach because it solves the problem that execution windows have around making it obvious Orca changed the behavior of a pipeline on the fly, even if the stage details aren't shown.
Here's an example of what it would look like for our first use case internally, which is suspending deploys until we're done shifting traffic out of a region:
cc @jeyrschabu