A repo does not need pushes before it will be repo-checked. There are
other sources where commits can come from (e.g. import or webIDE).

In the test I made the method of breaking a repo more robust. And
added a few test examples.

See also gitlab-org/gitlab-ce#45046.

In case the repository checks are disabled, do not send the
mails. Otherwise it might send the same failures over and over again.

Update instalation from source guide

See merge request gitlab-org/gitlab-ce!18691

Resolve "Specify variables when executing a manual pipeline from the UI"

Closes #44059

See merge request gitlab-org/gitlab-ce!18440

Partially revert ebcd5711 to fix runner pages

See merge request gitlab-org/gitlab-ce!18763

fix Web IDE file tree scroll issue

See merge request gitlab-org/gitlab-ce!18721

Resolve "Move `import_status` out of `projects`"

See merge request gitlab-org/gitlab-ce!18688

Resolve "Import/Export (import) is broken due to the addition of a CI table"

Closes #46049

See merge request gitlab-org/gitlab-ce!18745

Ensure web hook 'blocked URL' errors are stored in as web hook logs and properly surfaced to the user

See merge request gitlab-org/gitlab-ce!18746

[ci skip]

Enforce application wide terms

Closes #44798

See merge request gitlab-org/gitlab-ce!18570

AutoDevOps Docs fix invalid external link

Closes #46056

See merge request gitlab-org/gitlab-ce!18748

Ignore knapsack and rspec_flaky

See merge request gitlab-org/gitlab-ce!18747

Backport IdentityLinker#failed? from GroupSaml callback flow

See merge request gitlab-org/gitlab-ce!18749

Ensure when accessing Rails, we really get ::Rails (and not Sidekiq::Rails)

See merge request gitlab-org/gitlab-ce!18730

Replace commits spinach tests with RSpec analog

See merge request gitlab-org/gitlab-ce!18743

Ensure web hook 'blocked URL' errors are stored in as web hook logs and properly surfaced to the user

As described in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18738 there is a problem and the larger fix may take longer so we can just revert this small change for now

Add note about rebase/squash duplication in Gitaly

See merge request gitlab-org/gitlab-ce!18741

`InternalRedirect` prevents Open redirect issues by only allowing
redirection to paths on the same host.

It cleans up any unwanted strings from the path that could point to
another host (fe. //about.gitlab.com/hello). While preserving the
querystring and fragment of the uri.

It is already used by:

- `TermsController`
- `ContinueParams`
  - `ImportsController`
  - `ForksController`
- `SessionsController`: Only for verifying the host in CE. EE allows
   redirecting to a different instance using Geo.

This enforces the terms in the web application. These cases are
specced:

- Logging in: When terms are enforced, and a user logs in that has not
  accepted the terms, they are presented with the screen. They get
  directed to their customized root path afterwards.
- Signing up: After signing up, the first screen the user is presented
  with the screen to accept the terms. After they accept they are
  directed to the dashboard.
- While a session is active:
  - For a GET: The user will be directed to the terms page first,
    after they accept the terms, they will be directed to the page
    they were going to
  - For any other request: They are directed to the terms, after they
    accept the terms, they are directed back to the page they came
    from to retry the request. Any information entered would be
    persisted in localstorage and available on the page.

When a user accepts, we store this in the agreements to keep track of
which terms they accepted. We also update the flag on the user.

This will act as a cache, otherwise we would need to load the
`term_agreements` for a user on each request.

Using this field the result we're interested in is loaded when the
current user is loaded, without causing an extra query.

When terms are present, they can be viewed on `/-/users/terms`.

We will reuse the the dropdown, but exclude some menu items based on
permissions.

So moving the menu to a partial, and adding checks for each menu item here.

This allows admins to define terms in the application settings.

Every time the terms are adjusted, a new version is stored and becomes
the 'active' version. This allows tracking which specific version was
accepted by a user.

That way we can link a users acceptance of terms directly to a terms record.

Add a flag to applications settings to enforce users to accept terms
before using the GitLab instance

https://gitlab.com/gitlab-org/gitlab-ce/issues/23036