Recreate build pipeline within tectonic console #75

benjaminapetersen · 2018-05-29T14:47:49Z

Per task https://jira.coreos.com/browse/CONSOLE-453

w/@sg00dwin, bah, wasn't going to squash your commit into mine, sorry about that. 😦

Looking over a few more details from the old pipeline's flow, then I'll remove the WIP. Any feedback welcome.

benjaminapetersen · 2018-05-29T14:54:07Z

Pending:

Build in progess:

A complete flow:

spadgett · 2018-05-29T15:01:16Z

/cc @spadgett @rhamilto

spadgett

Thanks @benjaminapetersen. I realize this is still WIP, but wanted to give you some feedback. I have not looked closely at the CSS

spadgett · 2018-05-29T15:02:55Z

frontend/public/components/build-pipeline.scss

+$pipeline-in-progress-color: #0088ce;
+$pipeline-new-color: #bee1f4;
+$pipeline-pending-color: #d1d1d1;
+$pipeline-success-color: #3f9c35;


can we use $color-pf-* for colors in the palette?

https://www.patternfly.org/styles/color-palette/

@sg00dwin I'm fine with this if you are.

We can. I gave @benjaminapetersen the hex incorrectly.

@benjaminapetersen can you replace with the following vars.

$pipeline-aborted-color: $color-pf-black-300; $pipeline-border-color: $color-pf-black-300; $pipeline-failed-color: $color-pf-red-100; $pipeline-in-progress-color: $color-pf-blue-400; $pipeline-new-color: $color-pf-blue-100; $pipeline-pending-color: $color-pf-black-300; $pipeline-success-color: $color-pf-green-400; $pipeline-require-attention-color: $color-pf-gold-400;

Great, will update.

spadgett · 2018-05-29T15:08:36Z

frontend/public/components/build-pipeline.tsx

+import { resourcePath } from './utils';
+import { fromNow } from './utils/datetime';
+
+const getBuildNumber = (resource: any) => _.get(resource, ['metadata', 'annotations', 'openshift.io/build.number']);


You can leave : any off and it's the same (here and below). I'd rather not specify that everywhere when it's not needed.

But you might use : K8sResourceKind

Perfect, I'd rather use K8sResourceKind.

spadgett · 2018-05-29T15:09:23Z

frontend/public/components/build-pipeline.tsx

+const getStages = (status: any) => status && status.stages || [];
+const getJenkinsStatus = (resource: any) => {
+  const status = _.get(resource, ['metadata', 'annotations', 'openshift.io/jenkins-status-json']);
+  return status && JSON.parse(status);


Need to handle exceptions if it's not valid JSON.

spadgett · 2018-05-29T15:10:17Z

frontend/public/components/build-pipeline.tsx

+import { fromNow } from './utils/datetime';
+
+const getBuildNumber = (resource: any) => _.get(resource, ['metadata', 'annotations', 'openshift.io/build.number']);
+const getStages = (status: any) => status && status.stages || [];


const getStages = status => (status && status.stages) || [];

I guess this is actually the same due to order of precedence, but I think the parens make it more clear.

Yup but I can update.

spadgett · 2018-05-29T15:11:20Z

frontend/public/components/build-pipeline.tsx

+
+
+const BuildSummaryStatusIcon: React.SFC<BuildSummaryStatusIconProps> = ({status}) => {
+  let statusClass = _.lowerCase(status);


We should use const instead of let when possible (here and below)

also polishing up for next push.

spadgett · 2018-05-29T15:23:18Z

frontend/public/components/build-pipeline.tsx

+  </div>
+}
+
+const BuildAnimation = ({status}) => {


I'd use this shorthand

const BuildAnimation = ({status}) => <div>...</div>;

Should this have a type?

spadgett · 2018-05-29T15:24:35Z

frontend/public/components/build-pipeline.tsx

+  let buildUrl = getJenkinsBuildURL(resource);
+  if(pending) {
+    return <div className="build-pipeline__stage-actions text-muted">
+      <a href={buildUrl}>Input Required</a>


target="_blank" rel="noopener noreferrer"

spadgett · 2018-05-29T15:25:22Z

frontend/public/components/build-pipeline.tsx

+  return null;
+}
+
+const BuildStageTimestamp = ({timestamp}) => <div className="build-pipeline__stage-time text-muted">


spadgett · 2018-05-29T15:25:52Z

frontend/public/components/build-pipeline.tsx

+  </div>;
+};
+
+// NOTE: is not instantiated, so need this wrapper?


I'd leave off the comment since it applies to all tsx files

Yup, sorry didn't remove the [WIP] yet. Next push will eliminate the last of my notes-to-self 😄

spadgett · 2018-05-29T15:27:06Z

frontend/public/components/build.tsx

@@ -38,6 +39,11 @@ export const BuildsDetails: React.SFC<BuildsDetailsProps> = ({obj: build}) => {
  const duration = formatBuildDuration(build);

  return <div className="co-m-pane__body">
+    <div className="row">


Maybe it's OK, but this is going to add some empty DOM nodes if it's not actually a build pipeline

To fix this I'd prob extract the helper functions from the top of the build-pipeline.tsx file into a module, perhaps components/utils/build-pipeline.tsx or module/build-pipeline.tsx, then import into both files. That would let me use one of the functions here to conditionally render the <row>.

Preferrable?

Maybe just check build.spec.strategy.type === 'JenkinsPipeline'?

Yeah, def plenty reasonable. Lets go that route.

rhamilto · 2018-05-29T18:17:52Z

frontend/public/components/build-pipeline.scss

+  &:last-child:before {
+    display: none;
+  }
+  &.build-pipeline__stage--none {


Is the nesting necessary? BEM suggests you shouldn't nest...

@sg00dwin I'll defer to you on the style

rhamilto · 2018-05-29T18:22:48Z

frontend/public/components/build-pipeline.scss

+  text-align: center;
+}
+
+@media (min-width: 480px) {


Would it be better to nest the media queries with the default rules so things are a bit more compartmentalized?

rhamilto · 2018-05-29T18:25:26Z

frontend/public/components/build-pipeline.scss

+}
+
+.build-pipeline__status-icon {
+  &--complete {


Here modifiers are nested, but elsewhere they are not. Seems like we should be consistent?

rhamilto · 2018-05-29T18:26:48Z

frontend/public/components/build-pipeline.scss

+  height: 100%;
+  padding: 0 ($pipeline-padding / 2);
+}
+.build-pipeline__stage {


Nit: (here and throughout the file) alpha

@rhamilto is that standard in this repo? or have they followed another convention?
(asking cuz I'm still not a huge fan of alpha, ha.)

It is not (I'm not sure there is one), but it does appear to be in use within this partial.

kans

Please document how we can test this feature. We could potentially solve this problem in the future by adding different flavors of build configs to the YAML editor like we do for Roles.
Along the same lines, I am concerned about the difficulty of writing a reliable integration test for the pipeline visualization (mostly async animations). What are your thoughts?
In the not so distant past, we have seen trivially simple CSS animations use an entire CPU core in Chrome (a single blinking indicator). What does this do to performance?
Porting features over to the new Console is a golden opportunity to re-evaluate them, whether that be scope, form, or implementation. This sort of CSS is practically impossible for a human to review and there is quite a bit of it. Lets make an intentional decision one way or the other: is this UI and its implementation what we want now, or something that is merely convenient to build?

benjaminapetersen · 2018-05-30T15:35:58Z

frontend/public/components/build-pipeline.scss

+    justify-content: center;
+  }
+}
+


@sg00dwin we could use @each for stuff like this next block, to reduce some repetition. I don't have a strong opinion, but here is a before / after:

// without a list @media (min-width: $screen-md-min) { .build-pipeline__stage { width: (100% / 4); } } @media (min-width: $screen-lg-min) { .build-pipeline__stage { width: (100% / 5); } } @media (min-width: ($screen-lg-min + 200)) { .build-pipeline__stage { width: (100% / 6); } } @media (min-width: ($screen-lg-min + 400)) { .build-pipeline__stage { width: (100% / 7); } } // using a list $pipelineStageScreenSize: ( 4 $screen-md-min, 5 $screen-lg-min, 6 ($screen-lg-min + 200), 7 ($screen-lg-min + 400) ); @each $screenSize in $pipelineStageScreenSize { @media (min-width: nth($screenSize, 2)) { .build-pipeline__stage { width: (100% / nth($screenSize, 1)); } } }

Both will generate the same output css.

benjaminapetersen · 2018-05-30T17:47:15Z

@kans yeah let me see if I can hit all of those:

I'd love to see this for every PR, actually. A screenshot & "how do I use this?" is great for anyone reviewing, as well as historical documentation.

The Openshift QE V3 Test Files repo has quite a few bits of yaml and json to create resources in a variety of states. There are a handful of Pipelines options, for the sample below, I'm pulling the first one that came up:

# create a project
oc process -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/99d26e235b093431bff70e9edffc524559a9d664/pipeline/ui-pipeline-stage.yaml | oc create -f -

Then you should be able to navigate to a build page, see the pipeline, click action -> rebuild to run again, etc.

Integration tests for animations... I'd probably expect an exceptionally good set of unit tests & integration tests before worrying about testing a css animation. Not sure there is a ton value in pursuing.
Seems like an edge case, I'd prob trust a manual test for a css animation & worry about automated testing for all kinds of other things before worrying about a test case for this. Could be an enormous rabbit hole. Open to feedback, of course.
Definitely open to re-evaluation. This is not the full pipeline experience from the old console. I'd say comment away on the items in the PR that are worth discussion and lets talk (its essentially 1 CSS file and 1 JS file). I think both @sg00dwin and I would be happy to kick around chagnes, optimizations, etc.

Thanks for the feedback!

spadgett · 2018-05-30T18:23:19Z

In the not so distant past, we have seen trivially simple CSS animations use an entire CPU core in Chrome (a single blinking indicator). What does this do to performance?

@kans How have you profiled animations in the past?

I feel like, specifically for pipelines, they add a lot to the user experience. It's immediately apparent what stage is active and when the pipeline moves to the next stage.

spadgett · 2018-05-30T19:48:14Z

cc @openshift/team-ux-review

beanh66 · 2018-05-31T15:54:14Z

Thanks @spadgett, we will discuss in our design meeting today and will follow up this afternoon with comments.

serenamarie125 · 2018-06-01T17:10:53Z

@spadgett sorry bout the post 24 hour reply ... just connected with @sspeiche and others to get more background so we could provide a more thoughtful response.

The current design team was not involved with the pipeline design, although in our opinion we agree that it provides an positive user experience.

To provide a bit of history, we needed to have a CI/CD story for our platform...Jenkins is the #1 workflow/pipeline open source tool. The goal was to provide an integrated experience. The design "mirrored" the state in Build objects in OpenShift from Jenkins instead of forcing people to go back and forth. The original design process was a very long process driven by designers who did engage with customers during the design process. The design process was iterative.

The general feedback from customers has been that they really like it. There are some specific requests to improve on it, but these have yet to be addressed. Note that this is still a relatively new feature in the rate our customers roll out updates. So usage is picking up more now ...

One question going forward would be more around role based access. This feature would definitely be expected by an "app/dev" role, but unsure for admins.

@robszumski do you have additional thoughts?

serenamarie125 · 2018-06-01T17:12:21Z

One more note, OpenShift.io uses the same exact pipeline representation as OpenShift

tlwu2013 · 2018-06-01T17:45:58Z

@beanh66, @cshinn, and I briefly chatted about the design yesterday in our sync.
We feel it seems fine to keep the current design to matchup the experience on App Console side.
So I think from design standpoint, this seems to be good go. But I can't comment on engineering/testing point of view, so I'll defer that to dev team for extended discussions.
And if this PR did introduce serious performance throttle, I am open to exploring tweaks to the design to see if we can improve that.

BTW, just FYI, here's the screen capture I did from the youtube provided by @beanh66 for showing the interaction OpenShift Console side:
https://drive.google.com/file/d/1NzXtv5sLSvbUruF4SNru-NmR8eYwThW7/view?usp=sharing

spadgett · 2018-06-11T18:46:48Z

@benjaminapetersen @sg00dwin do you feel like this is ready for review?

@rhamilto can you review the styles?

benjaminapetersen · 2018-06-11T18:51:30Z

Running it again locally today, but the scss doesn't seem to build correctly (i think its something local, not that there is a scss error).

benjaminapetersen · 2018-06-11T19:13:53Z

Ok, local cache. solved.

Yeah, @spadgett @rhamilto I think its safe to give it a second round of review. @sg00dwin agreed?
@alecmerdler appreciate your thoughts on code style consistency or anything as well!

benjaminapetersen · 2018-06-11T19:30:23Z

frontend/public/components/build-pipeline.scss

+    }
+  }
+}
+


Untested, but since we have that open topic regarding sass loops, An alternative could be to use a sass map, something like this:

// can also use a map, with key-value pairs $pipeline-stages-per-row: ( small: ( column-no: 4, media-query-px: $screen-md-min ) medium: ( column-no: 4, media-query-px: $screen-lg-min ) large: ( column-no: 4, media-query-px: $screen-lg-min + 200 ) x-large: ( column-no: 4, media-query-px: $screen-lg-min + 400 ) ) // and use the map-get() function to get value by key... @each $size, $map in $pipeline-stages-per-row { @media (min-width: map-get($map, media-query-px)) { .build-pipeline__stage { width: (100% / map-get($map, column-no)); } } }

map-get($map, the-key-to-get) is clearer than nth($screenSize, someIndex), but the code is a bit longer.

rhamilto

Overall is fine. It's not clear if the file is organized in some way. Sometimes things are alpha, sometimes not. Would be good to be consistent within the file.

rhamilto · 2018-06-12T14:55:42Z

frontend/public/components/build-pipeline.scss

+
+.build-pipeline {
+  border: 1px solid $pipeline-border-color;
+	font-size: $pipeline-font-base;


Nit: spacing

Tab to space fixed.

benjaminapetersen · 2018-06-12T15:45:29Z

@rhamilto @sg00dwin I'm good with choosing an organizational pattern going forward (and ideally even documenting it). Still not fond of how alphabetical breaks up logical groupings like height and width, or top,bottom,left,right, etc, but any organization is better than random.

benjaminapetersen · 2018-06-12T15:49:29Z

@rhamilto opinion on the loops? Post refactor, prob worth assessing if its really an improvement or no.

benjaminapetersen · 2018-06-12T15:54:47Z

frontend/public/components/build-pipeline.scss

+  height: 100%;
+  opacity: 0;
+  width: 100%;
+}


Just an observation, since we've been kicking around the topic. Most of the other existing SCSS files seem to hover around 50 lines or less. There are a couple in the range of 100.

350 lines is pretty big.

Per the file size, I'm wondering if it would be good to break the elements down. I'm partial to the pattern I see in a lot of React apps where you have something like:

/public /components /build-pipeline |_ build-pipeline.js |_ build-stage.js |_ etc.

And do an

// build-pipeline.js import './build-pipeline.scss'; // build-stage.js import './build-stage.scss'; // etc.

But the current pattern is more or less one big file list in public/components so I don't necessarily want to go out of the norm.

Any thoughts? @rhamilto @sg00dwin
As well as @alecmerdler @spadgett since its a structure question.

Otherwise, I'm going to remove the [WIP] because we might be close to settled.

@benjaminapetersen Well, we can split it up to make it smaller, though a cursory look at the code, if you pull the rest out into a build-pipeline.scss partial, the majority of code would still be in build-stage.scss. Probably would still be 200 lines.

Yeah I think our verbals on this indicated we don't want to split it up at this point.

spadgett · 2018-06-16T01:15:20Z

frontend/public/components/build-pipeline.tsx

+    return {};
+  }
+
+  const json = _.attempt(JSON.parse, status);


nit: It's no longer JSON now that you've parsed it... I'd swap these variable names.

const json = _.get(resource, ['metadata', 'annotations', 'openshift.io/jenkins-status-json']); // ... const status = _.attempt(JSON.parse, json);

spadgett · 2018-06-16T01:18:23Z

frontend/public/components/build-pipeline.tsx

+    <span className={`build-pipeline__status-icon build-pipeline__status-icon--${statusClass}`}>
+      <span aria-hidden="true">
+        <span className={`fa ${icon} fa-fw`}></span>
+      </span>


Why the extra span? Couldn't this be...

<span className={`fa ${icon} fa-fw`} aria-hidden="true"></span>

Sure can, updating.

spadgett · 2018-06-16T01:21:42Z

frontend/public/components/build-pipeline.tsx

+    complete: 'fa-check-circle',
+    failed: 'fa-times-circle'
+  })[statusClass];
+  const hide = icon ? 'hide' : '';


Why use the hide class if we could just use JSX to hide the node. Is there some animation we want?

@sg00dwin on the animation Q, otherwise I'll fix this.

@sg00dwin there isn't a .hide class in the build-pipelines.scss file, doing a grep -ri 'hide' public/components' doesn't reveal a generic hide class with an animation, so I'll update this to use jsx.

Will be:

{!icon && <span className="build-pipeline__status-icon"> <span className="fa fa-refresh fa-spin" aria-hidden="true"></span> </span>}

Yeah, suggest an sr-only span in there too for screen readers

spadgett · 2018-06-16T01:22:16Z

frontend/public/components/build-pipeline.tsx

+  return <React.Fragment>
+    <span className={`build-pipeline__status-icon build-pipeline__status-icon--${statusClass}`}>
+      <span aria-hidden="true">
+        <span className={`fa ${icon} fa-fw`}></span>


We check for empty icon above. Doesn't that mean this could result in class="fa fa-fw" with no icon here?

Probably should be:

return <React.Fragment> {icon && <span className={`build-pipeline__status-icon build-pipeline__status-icon--${statusClass}`}> <span className={`fa ${icon} fa-fw`} aria-hidden="true"></span> </span>} {!icon && <span className="build-pipeline__status-icon"> <span className="fa fa-refresh fa-spin" aria-hidden="true"></span> </span>} </React.Fragment>;

Then the <React.Fragment> is not really needed, we will either do one or the other...

So probably should be:

return icon ? <span className={`build-pipeline__status-icon build-pipeline__status-icon--${statusClass}`}> <span className={`fa ${icon} fa-fw`} aria-hidden="true"></span> </span> : <span className="build-pipeline__status-icon"> <span className="fa fa-refresh fa-spin" aria-hidden="true"></span> </span>

spadgett · 2018-06-16T01:23:06Z

frontend/public/components/build-pipeline.tsx

+};
+
+const StagesNotStarted: React.SFC<StagesNotStartedProps> = ({stages}) => {
+  return !stages.length ? <div className="build-pipeline__stage build-pipeline__stage--none">No stages have started.


Prefer _.isEmpty

spadgett · 2018-06-16T01:28:34Z

frontend/public/components/build-pipeline.tsx

+</div>;
+
+const BuildStageName: React.SFC<BuildStageNameProps> = ({name}) => {
+  return <div title={name} className="build-pipeline__stage-name">


title is because long names get elided?

Think so:

.build-pipeline__stage-name { @include text-overflow(); margin-bottom: $pipeline-padding + 3px; }

that's correct

spadgett · 2018-06-16T01:29:34Z

frontend/public/components/build-pipeline.tsx

+</div>;
+
+const JenkinsInputUrl: React.SFC<JenkinsInputUrlProps> = ({obj, stage}) => {
+  const pending = stage && (stage.status === 'PAUSED_PENDING_INPUT');


I don't think you need to check if stage is defined here. We don't check other places, so it will be an error before it gets to this point.

Makes sense. hopefully the check in build.tsx means we won't start rendering any of this unless there are jenkins pipeline stages.

spadgett · 2018-06-16T01:32:13Z

frontend/public/components/build-pipeline.tsx

+    <BuildPipelineSummary obj={obj} />
+    <div className="build-pipeline__container">
+      <div className="build-pipeline__stages">
+        <StagesNotStarted stages={stages} />


This is a little confusing because it looks like StagesNotStarted is always visible, but then you loop over stages below. I think it's much clearer if you didn't use the component:

{_.isEmpty(stages) ? <div className="build-pipeline__stage build-pipeline__stage--none">No stages have started.</div> : stages.map(stage => <BuildStage obj={obj} stage={stage} key={stage.id} /> )}

I can put the _.isEmpty() check up here, that makes sense.

spadgett · 2018-06-16T01:34:02Z

frontend/public/components/build.tsx

@@ -38,6 +39,11 @@ export const BuildsDetails: React.SFC<BuildsDetailsProps> = ({obj: build}) => {
  const duration = formatBuildDuration(build);

  return <div className="co-m-pane__body">
+    <div className="row">


Maybe just check build.spec.strategy.type === 'JenkinsPipeline'?

spadgett · 2018-06-16T01:37:39Z

frontend/public/components/build-pipeline.tsx

+    <div className="build-pipeline__container">
+      <div className="build-pipeline__stages">
+        <StagesNotStarted stages={stages} />
+        { stages.map((stage => <BuildStage obj={obj} stage={stage} key={stage.id} /> )) }


Why the double parens (( )) ?

I was just envious of Lisp the day I wrote this...

benjaminapetersen · 2018-06-18T14:30:18Z

Addressing these & pushing an update shortly.

@sg00dwin

- Per task https://jira.coreos.com/browse/CONSOLE-453 - additions from @sg00dwin - Update scss to be smaller and less repetitive. - And change markup for when "no stages have started." state - Remove build details link since we're already show build details beneath pipeline

openshift-ci-robot · 2018-06-19T02:23:05Z

@benjaminapetersen: The following tests failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
ci/prow/crud	`ee9a1d9`	link	`/test crud`
ci/prow/alm	`ee9a1d9`	link	`/test alm`
ci/prow/performance	`ee9a1d9`	link	`/test performance`

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

benjaminapetersen · 2018-06-19T02:23:13Z

Comments addressed, squashed & co-authored w/@sg00dwin.

spadgett

/lgtm

spadgett · 2018-06-19T18:04:24Z

frontend/public/components/build-pipeline.tsx

+
+const BuildLogLink: React.SFC<BuildLogLinkProps> = ({ obj }) => {
+  const link = getJenkinsLogURL(obj);
+  return link ? <div className="build-pipeline__link">


nit: does this work?

return link && <div> ... </div>;

I bet it would have! Woops.

stevekuznetsov · 2018-06-19T18:41:42Z

/test backend
/test frontend

…anch fix secret

Migration: Moves Storage System List Page and Add Capacity Modal

openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label May 29, 2018

openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 29, 2018

benjaminapetersen requested a review from spadgett May 29, 2018 14:47

openshift-ci-robot added the size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. label May 29, 2018

benjaminapetersen requested a review from sg00dwin May 29, 2018 14:48

benjaminapetersen force-pushed the build-pipelines-migration branch from 68db58e to fbf3417 Compare May 29, 2018 15:00

openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 29, 2018

openshift-ci-robot requested a review from rhamilto May 29, 2018 15:01

spadgett requested changes May 29, 2018

View reviewed changes

benjaminapetersen force-pushed the build-pipelines-migration branch from fbf3417 to 9add2ae Compare May 29, 2018 16:02

rhamilto reviewed May 29, 2018

View reviewed changes

kans suggested changes May 30, 2018

View reviewed changes

benjaminapetersen commented May 30, 2018

View reviewed changes

benjaminapetersen force-pushed the build-pipelines-migration branch from 9add2ae to fd5c151 Compare June 1, 2018 15:33

benjaminapetersen force-pushed the build-pipelines-migration branch 2 times, most recently from 3872c8b to 36e8a78 Compare June 11, 2018 18:00

benjaminapetersen requested review from rhamilto and alecmerdler June 11, 2018 19:14

benjaminapetersen commented Jun 11, 2018

View reviewed changes

rhamilto reviewed Jun 12, 2018

View reviewed changes

benjaminapetersen commented Jun 12, 2018

View reviewed changes

benjaminapetersen changed the title ~~[WIP] Recreate build pipeline within tectonic console~~ Recreate build pipeline within tectonic console Jun 12, 2018

openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Jun 12, 2018

benjaminapetersen force-pushed the build-pipelines-migration branch from 36e8a78 to 37737d6 Compare June 13, 2018 15:29

spadgett requested changes Jun 16, 2018

View reviewed changes

benjaminapetersen force-pushed the build-pipelines-migration branch from 9b3226f to ee9a1d9 Compare June 19, 2018 02:21

openshift-ci-robot assigned spadgett Jun 19, 2018

spadgett approved these changes Jun 19, 2018

View reviewed changes

openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jun 19, 2018

openshift-merge-robot merged commit 1b5b07b into openshift:master Jun 19, 2018

wtrocki added a commit to wtrocki/console that referenced this pull request Feb 10, 2021

Merge pull request openshift#75 from bf2fc6cc711aee1a0c2a/wednesdayBr…

aadc9d7

…anch fix secret

TimothyAsirJeyasing pushed a commit to TimothyAsirJeyasing/console that referenced this pull request Aug 3, 2022

Merge pull request openshift#75 from bipuladh/ss-list

1ee2056

Migration: Moves Storage System List Page and Add Capacity Modal



		const BuildSummaryStatusIcon: React.SFC<BuildSummaryStatusIconProps> = ({status}) => {
		let statusClass = _.lowerCase(status);

Recreate build pipeline within tectonic console #75

Recreate build pipeline within tectonic console #75

Conversation

benjaminapetersen commented May 29, 2018

benjaminapetersen commented May 29, 2018

spadgett commented May 29, 2018

spadgett left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjaminapetersen May 30, 2018 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kans left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjaminapetersen commented May 30, 2018

spadgett commented May 30, 2018

spadgett commented May 30, 2018

beanh66 commented May 31, 2018

serenamarie125 commented Jun 1, 2018

serenamarie125 commented Jun 1, 2018

tlwu2013 commented Jun 1, 2018

spadgett commented Jun 11, 2018

benjaminapetersen commented Jun 11, 2018

benjaminapetersen commented Jun 11, 2018 • edited

Choose a reason for hiding this comment

rhamilto left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjaminapetersen Jun 13, 2018 • edited

Choose a reason for hiding this comment

benjaminapetersen commented Jun 12, 2018 • edited

benjaminapetersen commented Jun 12, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

benjaminapetersen May 30, 2018 •

edited

benjaminapetersen commented Jun 11, 2018 •

edited

benjaminapetersen Jun 13, 2018 •

edited

benjaminapetersen commented Jun 12, 2018 •

edited