Unfortunately I do not have capacity to review this - passing to next reviewer on roulette @allison_villa

Please flush out the MR description there was no context on why this change was necessary

A good aria-label would be:

aria-label="Purchase credits (opens in new window)"

There should be an aria-label for accessibility. Since the button opens in a new window (target="_blank"), it's especially important to indicate that to screen reader users.

Since it looks like more work needs to be done on this I will unassign myself as a reviewer since I am going on extended PTO

What does this MR do and why?

Problem: When users trigger a manual deploy action or rollback/re-deploy an environment, there is no success feedback — the button click happens silently with no indication of what happened.

Solution: Show a "Deployment started" toast notification with a "View job" link after a successful manual deploy or rollback action. The job URL is captured from the REST API redirect response (response.request.responseURL).

References

#388950

Screenshots or screen recordings

Before	After

How to set up and validate locally

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Sorry for the delay. I am going on PTO but based on the code this looks good and since we are using GlToast in the background all accessibility requirements are dealt with as well so great job @k0ndratov. I am passing to @shampton for maintainer review. I will admit that I was hesitant to actually test this code in the gdk because I am not too familiar with how environments operate there so I will ask that is verified before we merge.

I would also recommend adding the below to the MR description so reviewers can more easily know how to test your code

How to set up and validate locally

1. Manual Action Toast

1. Navigate to a project's Operate > Environments page
2. Find an environment with available manual actions (e.g., a scheduled job action)
3. Click on the manual action button
4. Expected: A toast notification appears with the message "Deployment started" and a "View job" link
5. Click the "View job" link
6. Expected: You are redirected to the job details page

2. Rollback Toast

1. Navigate to a project's Operate > Environments page
2. Find an environment with a deployment history
3. Click the rollback button on a previous deployment
4. Confirm the rollback action in the modal
5. Expected: A toast notification appears with the message "Deployment started" and a "View job" link
6. Click the "View job" link
7. Expected: You are redirected to the re-deployment job details page

Can you please review this when you get a chance @jerasmus

What does this MR do and why?

Fixes #586191 - File tree browser preserves scroll position when switching between files in Chrome and Arc browsers.

When navigating between files using the repository file tree browser in Chromium-based browsers (Chrome, Arc), the scroll position from the previous file was incorrectly preserved. This caused the viewer to jump to an arbitrary position in the newly selected file rather than starting at the top.

The fix calls scrollUp() in the onFileClick() method to reset scroll position at the moment of user interaction, preventing Chromium's scroll restoration logic from interfering.

References

Closes #586191

Related to !220743

Screenshots or screen recordings

How to set up and validate locally

1. Navigate to a repository with the file tree browser enabled
2. Open a file and scroll down to a position partway through the file
3. Click on a different file in the file tree browser
4. Verify that the new file opens scrolled to the top (not at the previous scroll position)
5. Test in Chrome, Arc, Firefox, and Safari to ensure cross-browser compatibility

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Joseph Fletcher (3beaf052) at 09 Mar 21:45

Joseph Fletcher (c4322a1d) at 05 Mar 21:17

Joseph Fletcher (7716e76e) at 05 Mar 20:28

... and 895 more commits

Joseph Fletcher (13437d06) at 05 Mar 19:27

... and 894 more commits

Joseph Fletcher (23e21fdf) at 05 Mar 19:25

... and 893 more commits

LGTM @psjakubowska can you please do maintainer review

What does this MR do and why?

Fixes the collapsible commit info component improperly rendering commit.titleHtml by using text interpolation ({{ }}) instead of the v-safe-html directive. This caused HTML entities (e.g., &, <, >) and rendered references (e.g., #1) to display as raw escaped text instead of properly formatted HTML.

• Replaced {{ commit.titleHtml }} with v-safe-html:[$options.safeHtmlConfig]="commit.titleHtml" in collapsible_commit_info.vue
• This is consistent with how commit_info.vue and table/row.vue already render titleHtml
• The existing safeHtmlConfig ({ ADD_TAGS: ['gl-emoji'] }) is sufficient since the backend's SingleLinePipeline only produces <a> (already in DOMPurify defaults) and <gl-emoji> tags

References

Closes #592157

Screenshots or screen recordings

Before	After

How to set up and validate locally

1. Resize the browser to a small viewport width (e.g., < 576px) to trigger the mobile layout
2. Navigate to a repository's file tree and a commit whose title contains HTML entities (e.g., &) or issue/MR references (e.g., #1)
3. Click into a file to navigate via the repository app
4. Expand the collapsible commit info and verify the commit title renders as formatted HTML (links are clickable, entities are decoded) rather than raw escaped text
5. Navigate directly to a file URL (e.g., http://localhost:3000/<project>/-/blob/main/README.md) or refresh the page while viewing a file
6. Expand the collapsible commit info and verify the commit title renders correctly as formatted HTML

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Hi @vyaklushin can you please restart the MWPS. I haveaddress all the issues block it previously

Joseph Fletcher (5ffedf5d) at 04 Mar 17:08

... and 347 more commits

@ahuss7 There should not be because the language classes shoudld be standardized by this point. Here is a breakdown of the flow for easy visualization

1. Markdown Source (Input)

```ruby
def hello
end

Language state: ruby (string identifier)

2. Markdown Parser (CommonMark/Kramdown)

<pre><code class="language-ruby">def hello
end</code></pre>

Language state: class="language-ruby" (CSS class format)

3. Rouge Syntax Highlighter

Before Step 4:

<span id="LC1" class="line" lang="ruby">
  <span class="k">def</span> <span class="nf">hello</span>
</span>

Language state: lang="ruby" ❌ (invalid HTML)

After Step 4:

<span id="LC1" class="line" data-lang="ruby">
  <span class="k">def</span> <span class="nf">hello</span>
</span>

Language state: data-lang="ruby" ✅ (valid HTML)

4. CodeLanguageFilter Processing

Input (from various sources):

<pre><code class="language-ruby">...</code></pre>
<!-- OR -->
<pre lang="ruby"><code>...</code></pre>
<!-- OR -->
<pre data-lang="ruby"><code>...</code></pre>

Output (standardized):

<pre data-canonical-lang="ruby" data-lang="ruby">
  <code>...</code>
</pre>

Language state:

• data-canonical-lang="ruby" (programmatic use)
• data-lang="ruby" (display use)

5. AsciiDoc Pipeline (Parallel)

Before Step 4:

<pre lang="ruby"><code>puts "hello"</code></pre>

Language state: lang="ruby" ❌ (invalid)

After Step 4:

<pre data-lang="ruby"><code>puts "hello"</code></pre>

Language state: data-lang="ruby" ✅ (valid)

6. Final Rendered HTML

<pre data-canonical-lang="ruby" data-lang="ruby">
  <span id="LC1" class="line" data-lang="ruby">
    <span class="k">def</span> <span class="nf">hello</span>
  </span>
</pre>

Language state: Consistent data-lang="ruby" throughout ✅

The pre checks did not like it see below:

danger ❯

Results:

Errors:
- [ ] Adding calls to `html_escape_once` or `escape_once` to the codebase is forbidden!
We are in the process of removing all calls to these methods --- they mix unescaped
and escaped content in a way which cannot be unmixed, and often leads to XSS.

We should always know whether any string content is considered text (and _must_ be escaped
when included in HTML) or HTML (and can be included safely) --- any in-between means we have
lost track of what can be trusted, and need to revisit the data flow.

Please remove the added calls to `html_escape_once` or `escape_once`.
Use `html_escape` if the input is text, and ask for help if you need it!