What does this MR do and why?

Tiny UI improvements to make my life easier one click at a time:

Screenshots or screen recordings

Before:

After:

Before:

After:

How to set up and validate locally

• Go to yourgitlab.com/project_path/-/jobs/JOB_ID/artifacts/browse
  • Where JOB_ID is ID of job with artifact files.
  • There should be download button for each file (not for directory)
• Go to yourgitlab.com/project_path/-/jobs?kind=BUILD
  • There should be link to artifact browser for jobs that have artifacts

@justin_ho thanks, I did really miss that one.

@harvie thanks. I approve of this change. I'm just not able to reproduce this in my local so I'd request @justin_ho to point to me if he sees any concerns during FE review. Approving based on what the added screenshots communicate and given permissions remain intact(who can do what).

They frequently don't realize that 'Troubleshoot' and 'Fix pipeline with Duo' are separate features.

@rutshah understandable. In hindsight, in the presence of Fix... , troubleshoot sounds like a misleading label since it only tells you the reason for failure and not take any steps to troubleshoot. We can take multiple steps:

1. For DAP users, we can change the troubleshoot button to a split dropdown that shows Fix... by default and troubleshoot when users select the dropdown. WDYT?
2. We'll have to be a little strategic before implementing this, and think critically about how we want to handle list like failed job widget where trouble shoot appears many time.
3. We can even take a call to replace Troubleshoot entirely for DAP users given we have a tracking available to show their preference for one over the other.

What happens at this step when the chat opens? What is the workflow step that the user and agent are engaged in? Asking because I wonder how much of this envisioned workflow crosses over with HITL work that is planned.

@amandarueda when we were defining the workflow steps, we were not aware of the HITL notes. Nonetheless, we've take a conservative approach where critical actions are concerned. When CI agent chat opens:

1. Agent begins analysing the project and outlining the structure of the to be proposed configuration with explanation. This step requires an approval or users can choose to make adjustments
2. Then agent surfaces the suggested configuration, with reasoning and gives users an option to commit it to a new branch(not main so the risk is low) upon approval
3. Provides user option to view configuration in Visual editor and/or create an MR to commit the configuration to main branch

Let us know if you see any concerns with this approach. You can get a better idea of the flow from the linked Figma file if needed. cc @csaez-ext