Fixed row margins on Pipeline Settings page in order to unify styles On the ```project-name/pipelines/settings``` page, I removed the ```.row``` styling on ```.build-status``` and ```.coverage-report``` as it was causing those rows to not have the same margins as the "CI/CD Pipeline" row. Now, they are even as you can see below:   Closes #25098 cc: @filipa See merge request !7881
24726 Remove Across GitLab from side navigation ## What does this MR do? Removes Across GitLab header from side navigation ## Screenshots (if relevant) Before:  After:  ## Does this MR meet the acceptance criteria? - [ ] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [ ] API support added - Tests - [ ] Added for this feature/bug - [ ] All builds are passing - [ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [ ] Branch has no merge conflicts with `master` (if it does - rebase it please) - [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? Closes #24726 See merge request !7883
Pipelines tabs
## What does this MR do?
Changes the URL when the builds tab is clicked making it possible to be shared.
1. Adds a standard way to handle linked tabs:
* This behaviour is already present in the merge requests, commit and user `show` page.
* This MR introduces a reusable way to accomplish this behaviour for pages with static content.
2. Adds test:
* For the linked tabs reusable class
* For the pipelines tabs
## Why was this MR needed?
To allow having a sharable URL that represented the opened tab
## Does this MR meet the acceptance criteria?
- [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #24814
See merge request !7709
Remove the help text under the sidebar subscribe button and style it inline ## What does this MR do? Remove the help text under the sidebar subscribe button and style it inline ## Are there points in the code the reviewer needs to double check? ## Why was this MR needed? Current help text is over obvious and pushes references too far down. Also the subscribe button is now consistently styled and not a complete block button anymore. approved by @awhildy ## Screenshots (if relevant) before:  after:  ## Does this MR meet the acceptance criteria? - [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added - [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - [ ] API support added - Tests - [ ] Added for this feature/bug - [x] All builds are passing - [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if it does - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? Closes #24281 See merge request !7389
Resolve "missing design for wiki page" ### To Do: - [x] Move page navigation from sub-menu to sidebar menu - [x] Update wiki page header - [x] Update wiki edit page actions and header - [x] Update `Git access` page design - [ ] ~~Add search to sidebar navigation~~ ### Screen Shots: #### `@media (min-width: $screen-lg)`     #### `@media (min-width: $screen-md)`   #### `@media (min-width: $screen-sm)`   ## Does this MR meet the acceptance criteria? - [x] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - Tests - [x] All builds are passing - [x] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html) - [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if it does - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? Closes #18546 See merge request !7429
Resolve "Merge request dashboard page takes over a minute to load" See merge request !7760
Replace references to MergeRequestDiff#commits with st_commits when we care only about the number of commits See merge request !7668
`any?` on an AR relation performs a `SELECT COUNT`, which we don't need. 1. We are very likely to have issues or MRs, so the `SELECT COUNT` is often unnecessary. 2. Even where there are no items returned, the overhead of the `SELECT *` instead of `SELECT COUNT` is relatively small. Calling `to_a` on the relation lets us use `Enumerable#any?`, which will return immediately if there are objects returned.