Design updates for Builds & Pipelines

The original builds redesign was created before Pipelines was introduced, and now there is some duplication of information between builds and pipelines pages, along with some possibly unnecessary features. I think we should work on a more unified style for the following pages:

• Pipelines
• Builds
• Merge Requests > MR # >Builds
• Commits > Commit # > Builds

It also sounds like maybe the Tags column is unnecessary as many users do not use it which results in a blank column and wasted space.

cc @jschatz1 @dzaporozhets @ayufan

cc @markpundsack

Kamil suggested maybe we should just kill the Builds list... :) Eventually we should, but I suggested we give it a couple months to let people get used to it.

@markpundsack Why would we kill it?

Added ~19173 ~19492 labels

Download dropdown issue - https://gitlab.com/gitlab-org/gitlab-ce/issues/17804

@ayufan @markpundsack does it mean Pipelines replaces Builds page?

I don't want to sidetrack the conversation too much, but after using Pipelines for a short while, I find they provide everything I need and the Builds list has no value. So yeah, eventually I could see us just killing the Builds list completely. Note we still need to view individual builds, and even lists of builds, but they'd be under pipelines. e.g. pick the most recent pipeline, then click on it and see a list of builds for that pipeline, grouped by stage, then click on an individual build to see the build details.

We still need to make the pipelines list appear for merge requests, though, and there's a bit of underlying work to prepare for that. So we're not ready to kill Builds yet. And even if we were, we can give people time to get used to the idea before forcing them into the Pipelines view.

But, as https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4053 is trying to limit the number of tab items, it's reasonable to start by making a CI/CD tab with both Pipelines and Builds underneath it. Or not. Just go ahead and kill the Builds list. Whatever. :)

Is there anything in the Builds list that isn't covered by Pipelines?

mentioned in merge request !4230 (merged)

Added frontend label

Removed ~19492 label

Milestone changed to %8.9

Reassigned to @annabeldunstone

mentioned in issue #18249 (closed)

Added ~15078 label

mentioned in issue #18534 (closed)

@annabeldunstone Is this still an issue or can we close it?

@markpundsack It's still an issue at the moment (I haven't had a chance to implement any updates). Please leave it open for now

@annabeldunstone Can you assign more appropriate milestone?

Milestone changed to %8.10

mentioned in issue #18920 (closed)

@ayufan @markpundsack I propose @annabeldunstone and @hazelyang work on UI improvements to CI pages.

@dzaporozhets That would be great!

@hazelyang please collaborate with @annabeldunstone for improving CI pages.

@annabeldunstone

I modified Pipelines page based on your suggestions above. It looks clearer and more consistency with Builds. One thing, I tried different ways to put ID below the status label, but it looked not okay, so I let it be in the other column like Build ID in Build page.

If you have any feedback, please let me know.

---

@hazelyang Could you also look at: https://gitlab.com/gitlab-org/gitlab-ce/issues/18181 and https://gitlab.com/gitlab-org/gitlab-ce/issues/18479?

@markpundsack Do you find useful information about who created this pipeline or who was the author of commit?

@markpundsack What do you think about dropping the ID?

@ayufan Oh yeah, showing who triggered it is probably valuable. At least CircleCI shows it.

I am torn on the ID. I'm not sure I need to see it at all. Or maybe only show the ID on a pipeline detail page.

Just for reference, here's what CircleCI shows:

The build ID is in there, but made secondary by combining with what we call our Commit column. Now that I see that, if the IDs weren't 7-digits long, and were incremental for the project, then maybe the build number would be more meaningful to me.

@markpundsack Hopefully we can migrate to project counted ids some time soon, because current IDs doesn't make sense.

mentioned in issue #18992 (closed)

Do we need the entire commit message & branch name? They take up a lot of space. How about just the commit hash?

@ayufan Sure, I saw that. Thanks!

I proposed 4 designs based on the discussion above.

A: Dropping ID

I only removed id column in this mockup since people maybe need to know the commit message and branch.

B: Dropping ID and branch name

C: Dropping branch name

D: Dropping branch name and commit message

@annabeldunstone I would say that yes. We can truncate it even further. This represent a value that you know what this pipeline were for. I would say that Commit Hash is less important then combination of branch and commit message. We could possible hide commit hash if it takes too much somewhere in tooltip (not sure).

@annabeldunstone @hazelyang

We will also have a manual actions on pipeline in 8.10 so we will possibly have to add extra button (Play?) in last column: https://gitlab.com/gitlab-org/gitlab-ce/issues/17010 (look at screenshots).

Maybe we could also think how we could redesign current buttons? because they are taking a lot of space and will probably toke some more.

@hazelyang

What about adding branch name to C: Dropping branch name in the same line as ID and SHA? Usually we have long commit messages so it should basically fit there :)

Other then I like the design C: Dropping branch name with branch name instead of ID.

I see bigger value in showing branch, sha and commit message then in including 7-digit number of Pipeline.

It looks awesome!

I think branch name is pretty important. Commit is a little less important, but probably still important. I think both of these can be condensed in the Commit column though, so they don't take up horizontal space. What if we squeezed the pipeline ID into that same column? Just to throw this out, what if we put the pipeline ID, branch, and commit all on the same line, then the gravatar and commit message on the second line? I kinda like having the gravatar be on the left rather than in the middle of a line.

@markpundsack

I added play button in the last column and put pipeline ID, branch, and commit on the same line.

---

Clicking deploy

---

Hiding cancel button and retry button

@hazelyang Looks pretty good!

Do we ever need to show all 4 actions at the same time? Retry, Deploy, and Cancel probably don't happen at the same time.

@markpundsack

Retry and Cancel are exclusive.

So we can have: Run, Retry or Cancel and Download.

Maybe we should have only this dropdown with all options instead?

• Run manual actions
• Retry or Cancel
• Artifacts

@ayufan I think we can skip Run manual actions while builds are running or if a build failed. So we'd only ever have 2 buttons at the same time. We don't need a dropdown then.

@hazelyang do we have a mobile design for the Pipelines view? Is the intention to just have it scroll horizontally on mobile? :)

Also, what happens if the stages have longer names?

@markpundsack

I did expect that you can run some actions on failed pipelines, but I see that it can be good simplification. I need to think about it more.

mentioned in issue #19168 (closed)

Related issue #19168 (closed):

In pipeline view, add an icon that differentiates "running" and "pending" builds and show "duration" for running tests

Given that the new UI doesn't show a textual description of the pipeline state, there's a need for a new icon that would let the user tell apart "running" and "pending" builds. How about an hourglass icon?

As a side note, why isn't "duration" displayed for running tests in that view?

@connorshea If you have suggestion, please let me know.

My proposed design for mobile:

• Maybe we could only allow the table to scroll horizontally instead of a whole page.
• Let the status labels be simple, so there is more space to see more content on a small screen. I think people can learn the status from icons.

---

The stages have longer names

• Maybe we could show the complete name on mobile but shorten it and show the complete one with tooltip on desktop.

##### Tooltip on desktop

mentioned in issue #19333 (closed)

@hazelyang nice!

I assume the commit message in mockup #1 (closed) would have an ellipsis (...) at the end if it was longer than two lines?

mentioned in issue #17010 (closed)

mentioned in issue #18479 (closed)

@connorshea Yes.

With seriously limited screen size, we could think about things like only showing the stage(s) that failed, or putting all the stages on a line under the rest of the content. Are New Pipeline and CI Lint really important enough to take up that real estate?

@markpundsack

We could also show only the name of last stage that is running, succeeded or failed. In ideal world there would be at most one stage that is running.

@hazelyang Could you prepare a MR where we could checkout your changes and start working on merging them?

@ayufan You can find the mockups in GitLab_8.10_Hazel in gitlab-design. If you have questions, please let me know.

@hazelyang Thanks.

@annabeldunstone Could you work on this?

I feel like I mentioned this somewhere else, but can we change "New Pipeline to "Run Pipeline"?

Damn, ever since I took a look at the CircleCI interface, I can't help but think I want the branch name before the pipeline number. The branch name is really the first thing I scan for. But then you'd have the pipeline number and the commit SHA right next to each other, which probably doesn't look good.

@ayufan Will start working on this today. Looks great @hazelyang! @dzaporozhets do you have an opinion on using the icons for duration/time ago? I remember we took them out a few weeks ago.

@annabeldunstone no I don't mind. We removed icons because we used only duration and if you have only one time its no sense to introduce icon. In your screenshot there are 2 lines with different time: it helps visually distinguish duration from start time

@markpundsack added "New Pipeline" button update to CI plan https://gitlab.com/gitlab-org/gitlab-ce/issues/18920

How do people feel about the 06:10 compress format for duration? Is there any confusion whether it means minutes:seconds vs hours:minutes? If so, would 6m 10s be better?

We may have to do 00:43:24 if we're sticking with the compressed format, which I prefer.

It may be one of those things that once you realize what it is, it's not a problem anymore, especially if hover shows a longer format like Duration: 6 minutes, 10 seconds. I don't think people are confused by CircleCI's usage. The vast majority of pipelines should finish in less than an hour, so prefixes with 00: seems mostly unnecessary. If we prefer that general format, I'm fine with trying it as 06:10 and seeing if it causes any confusion.

@markpundsack For the edge cases where the duration goes over an hour, are you suggesting we keep it in minutes still? As in 68:34?

I wasn't specifically suggesting that. Just not to prefix with 00: when it is less than an hour. I don't have strong feelings about 68:34 vs 01:08:34. I can see arguments either way (as long as minutes is still only 2 digits). The latter is probably better.

I'm not sure if we already came up with solution for this, but where should the tags be in both Pipelines and Builds?
Here are the current tags in Pipelines:


And here are the tags in Builds:

Apologies if these are already in the designs somewhere; I'm just not sure where to find them!

@hazelyang When you get a chance, could you please create an SVG of this icon and drop it into gitlab-design > images > svg. Thanks!

@annabeldunstone I prefer the tags to be added after the SHA as in latest in the Pipelines image rather than taking up a separate column in the Builds image.

To be clear, I think there are three different things that all could be called "tags".

1. the latesttag to indicate that the pipeline is the latest run for the given branch
2. the ruby, mysql tags which come from .gitlab-ci.yml and used to filter which runners the jobs can run on
3. Not shown - the git tag of the commit

The git tag (3) may not be shown explicitly as a tag currently in Builds because the column is called Ref, and if it were a tag, then we'd just put the tag there. But in Pipelines, I believe we should be showing the branch always, so if it was also tagged, that should be additional information. I'd like to see that show up to the right of the commit SHA.

The runner tag (2) probably shouldn't show up in Pipelines at all since they can be job-specific. It's also just not that important on that page.

mentioned in issue #19618 (closed)

@hazelyang Could you also make this icon into an SVG? I don't see it in font awesome

mentioned in merge request !5156 (merged)

OK, I was wrong about the Pipelines view and tags. We're currently doing the same thing as Builds, where we show the git tag instead of the branch.

To me, that makes it look like v1.0.0 is a branch name, but it isn't . I'd rather make that explicit and put git tags after the SHA, and make it actually look like a tag (colored non-pressable button).

What do you think?

@markpundsack I'm not sure what you mean. This is what I currently have for Pipelines, and master test, etc are clickable branch names, not tags.

@annabeldunstone Take a look at https://gitlab.com/markpundsack/docker-example/pipelines. The v1.0.0 one is a tag, not a branch. It links to https://gitlab.com/markpundsack/docker-example/commits/v1.0.0, which also makes it look like a branch, but you can see in the drop-down that it's a tag.

@markpundsack Ohhh okay. So it can either be a branch or a tag and there's no way of telling what it is just by looking. I'll need some help from a backend dev to separate those as I'm not sure how pipeline.ref is working.

Also, just a thought- do we want to make that tag v1.0.0, for example, unclickable? It seems like it would still be useful to be able to go straight to that link from the pipelines page.

@markpundsack I'm thinking this should be opened as a separate issue. Once the branch names/tags are separated out we can figure out how to style them

Yeah, we use "ref" everywhere, which can be so many things. Separate issue is fine. Incidentally, people are requesting be able to get the branch explicitly in CI environment variables, so perhaps if that happens, pipeline.branch will be a thing. :)

@annabeldunstone I added icons to gitlab-design/images/svg.

@annabeldunstone

You can get the information if ref is tag by checking: pipeline.tag (true or false)

@ayufan So that will let you know if ref is a tag, but can you figure out the branch in that case?

The branch on which tag was created? There's no such information in Git :) http://stackoverflow.com/a/27154277

Talked with @annabeldunstone about this, but recording here for others. One option for handling tags is to include a tag icon to the left of the ref name if it's a tag, and include a branch icon if it's a branch. Then maybe we can drop the [tag] badge.

One problem with this is that we currently using something like the branch icon for forks.

GitHub and Bitbucket use more of a balanced prong thing for forks:

and offshoot prong for branches:

I'm guessing that's because fontawesome only has one symbol, and they call it code-fork. I'd love to see us create custom icons more in line with GitHub and Bitbucket.

Status changed to closed by merge request !5156 (merged)

mentioned in commit c8ba4ac4

mentioned in issue #19751 (closed)

Moved last comment to #19751 (closed).

Mentioned in issue #18249 (closed)