Improve non-triggered manual action job detail page

@markpundsack I read this through several times and I have no idea what it means.

Traditionally. We only assign UX when UX is in process. Not to classify it as a UX issue. But I didn't see you ping any UX people so I am not sure if you want UX help here.

Milestone changed to %Backlog in gitlab-foss

mentioned in issue gitlab-foss#26471 (closed)

assigned to @dimitrieh

added ~897282 label

@dimitrieh This is still an issue for manual actions. Any ideas for how to handle them better?

mentioned in issue gitlab-foss#30573 (closed)

Another report in https://gitlab.com/gitlab-org/gitlab-ce/issues/30573

The only place I can trigger the manual builds is the pipeline overview that shows all jobs of the pipeline. When following the link to the manual job, it is shown as pending - build id is already created, environment blurb and, commit info is shown, the "build details" column and the log output are initialised already, showing a spinner that the job hasn't started yet.

I'm severely missing a big fat button on that build page that allows me to trigger the manual build, at least once all dependencies are met.

The build page should show

the spinner, accompanied by a link/name of the dependency it is waiting for

the play button to start the job now

the spinner, with the log output of the running job

the log output of the finished job

Currently steps 1 & 2 in that process are not distinguishable, there is no info what it is waiting for (dependencies or user input) and no possible action.

Something else I just noticed: When using environments, the manual build page states "This job is creating a deployment to production". This should be phrased as "This job will create a deployment to production" until it is started.

changed milestone to %9.3 in gitlab-foss

@dimitrieh This is biting me more and more these days, as I often click on a manual job to trigger it, but accidentally just click on the job name itself which shows the job detail page, but doesn't trigger it to run. It's confusing because the job detail page shows a spinner, misleading me to think that it's running, when it's not.

In addition, there should be some way to trigger the manual job from the job detail page because that's the page I'm on when I realize my mistake.

Tentatively scheduling for 9.3.

changed title from Improve display of non-triggered manual action builds to Improve non-triggered manual action job detail page

@markpundsack Should there even be a job page for these kinds of non-run ? This is of course also true for "created" jobs which have not yet run:

I know this is like this, just because the system uses some default, but this is actually indeed a little weird. Your points in the description are true:

We should not have a build log
We should have way to trigger manual actions (this is only for non-triggered manual action pages)
The details in the sidebar should be accurate

So in that sense, would the simplest solution not be to just not link these pages. Make the links unclickable... as "they are not there yet"...

Perhaps this should then be communicated more clearly with a tooltip:

Job name - Job has not been triggered yet.
Job name - Job has not been triggered yet by manual action.

If we do want a different solution we are up for an empty state imo, with:

We should not have a build log
Empty state displaying that this job still has to be triggered
If manual action, show an empty state with an actionable item

The details in the sidebar should be accurate

This refers to the fact that there are almost no details in the sidebar in these job pages, As they have no details yet. Thus the following can just be hidden:

@markpundsack @filipa @grzesiek let me know which option you prefer. I think the first one is the simplest though.

cc: @ayufan

@dimitrieh I think that it makes sense to hide job log container if we can not expect any trace from this job in this state (created, manual), and hide irrelevant data.

The problem is that this can change, and we support some functionality of real-time page on job details page. So it is possible that someone clicks play button when the page is viewed by someone else and the status changes to "running", we should keep that in mind.

@dimitrieh I don't have strong feelings on that. Blocking the page completely might work fine, although the devil is in the details. Do we then have to create disabled states for pipeline graphs so it's obvious I can't click on nodes? What happens if I try anyway?

Following up on @grzesiek's points about realtime, I could see someone clicking on a created job and leaving it open expecting it to update when the job actually starts.

@filipa As this is mostly up your alley :) If you are tackling this in addition to the things you are already doing at the job page, can you assign yourself

Following up on @grzesiek's points about realtime, I could see someone clicking on a created job and leaving it open expecting it to update when the job actually starts.

Valid point!

Design

information in sidebar which is not available as the job has not started/been triggered yet has been hidden.
title bar shows "created by" instead of "triggered by"
empty state added for
- manual action needed
- created, but not run yet

svg's:

note: according to https://gitlab.com/gitlab-org/gitlab-ce/issues/32380 the button can have a disabled state if it needs another manual action first

cc: @hazelyang (what do you think?)

updated issue description

changed the description

added gitlab-foss~~2024186 gitlab-foss~~127616 and removed UX in GitLab FOSS labels

@dimitrieh I think they are good. Based on your ideas above, I changed these illustrations style slightly to make them similar to other illustrations. Feel free to edit them if there are something needed to modify.