Add feedback if a runner was successfully created

Details

In #383139 (closed) we make a more robust UI for creating a runner. There are steps the user has to take to create the runner in the CLI. Once created, we do not provide the user with any feedback in the UI on whether it was successful or if it failed.

Proposal

• Add a badge next to Step 2 heading that includes the status of if the runner registered (statuses listed in #387882[runner-registered.png])
• Add a confirmation modal when leaving the registration page if the user decides to leave before the runner is registered successfully (#387882[leaving.png])

Designs in design management

added UX [Deprecated] Category:Runner Fleet featureaddition grouprunner typefeature labels

marked this issue as related to #383139 (closed)

added devopsverify sectionops labels

added to epic &7633 (closed)

changed milestone to %Backlog

mentioned in issue #383139 (closed)

changed the description

mentioned in issue #388954 (closed)

mentioned in issue gitlab-runner#28997 (closed)

mentioned in issue gitlab-design#2204 (closed)

assigned to @gdoyle

added workflowdesign label

changed the description

changed the description

added 3 designs

@mrincon @pedropombeiro @tschmitke My weekly loom video has arrived I would appreciate your feedback on the proposal variations I created! Also, please let me know if checking if the runner is online is a stretch.

https://www.loom.com/share/30759cf5815f49929d780aa4ea226577

Thanks @gdoyle! I also prefer the 3rd scenario, but the 2nd is already good enough. We could even start with the 2nd as an MVP and later on implement the changes for the 3rd, if that saves us time.

Also, please let me know if checking if the runner is online is a stretch.

We should be able to poll for the paused and contactedAt properties to determine that (not sure how Apollo caching might affect that, maybe @mrincon can chime in).

I also prefer the 3rd scenario, but the 2nd is already good enough. We could even start with the 2nd as an MVP and later on implement the changes for the 3rd, if that saves us time.

@pedropombeiro Agreed - I'll let @mrincon weigh in on if there are major frontend differences between options 2 and 3.

I'm going to actually leave the polling part for another issue, so we can just concentrate on checking if the runner is registered in this iteration

started a discussion on runner-creating-1.png

removed 3 designs

added 3 designs

added Technical Writing label

marked this issue as related to #392923 (closed)

started a discussion on runner-checking.png

mentioned in issue #392923 (closed)

changed the description

added workflowplanning breakdown label and removed workflowdesign label

unassigned @gdoyle

mentioned in merge request !113557 (merged)

@gdoyle I was looking for a way to prevent users from "losing" the token after displayed, and this modal caught my attention. Is the modal part something we could put in workflowready for development?

Motivation: After merging !114742 (merged) I would like to shorten the time the token is available to a few minutes, but users may lose access to the token, so I'd like to prevent them from leaving the page.

@mrincon Of course! I wasn't sure if I should've added this to workflowplanning breakdown or workflowready for development so that's why it is workflowplanning breakdown. I'll separate the modal into its own issue and tag you there

cc: @nicolewilliams

@mrincon As for the feedback proposal in this issue is it reasonable to add this to the 15.11 iteration plan?

@gdoyle, sorry for the slow response. I tried to fit this one into %15.11 but it is already packed, let's move it to %16.0

Sounds good to me

hey team, I'm moving this to Backlog since it isn't scheduled for 16.0. Please add to the discussion for the 16.1 planning issue if it is ready for scheduling. Thanks!

Just in case, we already have an iteration of this implemented by !113557 (merged)

marked this issue as related to #396895 (closed)

removed 1 design

changed milestone to %16.0

added 1 deleted label

changed milestone to %Backlog

mentioned in issue gitlab-design#2324 (closed)

I'm closing this out since we already have a good solution with feedback that the runner is ready to pick up jobs. I'll be focusing on Tell the user how to bring their runner online (#392950) instead which connects with the user leaving the creation flow mid-way.

closed