We do not need to link to index files, and in the future
it will be recommended to avoid it.

Changelog: changed

The intent of `:\d+\d+:` is probably to match `:35:7` from a log line like below:

```
lib/backup/tasks/task.rb:35:7: C: [Correctable] Style/EndlessMethod: Avoid endless method definitions.
```

Take the [raw_job_output.log] from https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179410 for example:

Before fix (incorrect):
```
$ grep --perl-regexp -o ":\d+\d+: \w: \[\S+\] ([\w/]+)" raw_job_output.log | awk '{print $4}' | sort | uniq -c
     10 Layout/TrailingWhitespace
      2 Style/SuperArguments
```

After fix (correct):
```
$ grep --perl-regexp -o ":\d+:\d+: \w: \[\S+\] ([\w/]+)" raw_job_output.log | awk '{print $4}' | sort | uniq -c
     30 Layout/EmptyLinesAroundMethodBody
     10 Layout/TrailingWhitespace
     70 Style/EndlessMethod
     14 Style/SuperArguments
```

[raw_job_output.log]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179410#raw_job_outputlog

- We started simplifying the template in [this MR][1]
- The Web IDE and Workspaces template should be
  the same except for some of the labels

[1]: https://gitlab.com/gitlab-org/gitlab-web-ide/-/merge_requests/410

Source gitlab_component_helpers before calling function

Remove single quote

scripts/compress-simplecov.rb does not exist, so we are getting an error
and don't minify the resultsets.

Runs the deprecations-and-removals job when breaking_windows.md is
changed. This makes MR pipelines fail when the file is updated manually.

Add custom exit code to internal pipeline doc

Ensure script is POSIX-compliant

Switch initial_exit_code_file to absolute path

Use set +e and set -e to prevent premature exit

Wait for pipe to complete before continue

Return correct spec list from scenario examples

Remove unnecessary ternary

Override default test suite for gitaly jobs

Fix error message

Bump RUBY_VERSION_NEXT to 3.4.1 and RUBYGEMS_VERSION to 3.6.3

This reverts merge request !179273

These jobs are expected to fail until the feature is complete. The jobs
were added as an aid for the development team to track progress.

We have a corresponding manually triggered job on test-on-omnibus so we
do not need to also included this job on nightly.

This is another fix for nightly jobs caused by
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175400.

The test sequencer used was determined entirely by the `vue3` flag.
Before the previous fix
(https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179427), that
flag was *not* being passed, meaning the regular fixture sequencer was
used, even though the the tests were being run under Vue 3.

So, this adds a new `--include-vue3-quarantined` flag to explicitly opt
in to including tests normally quarantined under Vue 3. The test
sequencer is then chosen based on that as well.

Finally, that flag is passed to the nightly `jest* vue3` jobs.

Instead of triggering a pipeline to create a TAG on AIGW, creating a tag
using an API endpoint is much simpler.

The failure here has been resolved, and therefore we should be good to
dequarantine this spec again.

Quarantined MR: https://gitlab.com/gitlab-org/gitlab/-/issues/436948
Failure Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/436948
Fixed By: https://gitlab.com/gitlab-org/gitlab/-/issues/391591

This makes sure the `--vue3` flag is explicitly passed to the nightly
Jest Vue 3 jobs to avoid this failure:

    Expected unset environment variable VUE_VERSION, or VUE_VERSION=2,
    got VUE_VERSION="3".

These nightly jobs are analysed and presented in
https://gitlab-org.gitlab.io/frontend/playground/jest-speed-reporter/vue3.html.

It showed a drop to zero of passing/failing specs under Vue 3 starting
2025-01-18. This the day after
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/175400 merged,
which changed how the `jest_ci.js` script checks its arguments.

Specifically, the `--vue3` flag (or lack of it) must agree with the
`VUE_VERSION` environment variable.

Every RSpec CI job uses the `setup_db` to set up a Postgres test
database. This takes about 1m 10s because the database has to be created
and then all migrations have to be applied.

In a pipeline that runs 150 RSpec jobs, this amounts to 3 hours of
work that is needlessly ran 150 times instead of once.

Therefore, this adds a CI job `db:setup pg14` that sets up a database
and makes it available as dump (using `pg_dumpall`) to all RSpec jobs
that test using Postgres 14.

By doing this, and applying the dump in each job with `psql`, we'll
reliably and (hopefully) permanently save about 50 seconds per RSpec
job, or about 3% of total job duration.

After fixing release-environments' QA in
https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/20838 and
https://gitlab.com/gitlab-org/release/tasks/-/issues/15464, set it as
a blocking step in the stable pipeline again, to validate changes to the
stable branches.

It has been moved.

This sets the same sharding values for the predictive versions of these
jobs as their non-predictive counterparts, in case the predictive set of
tests run is large.

This addresses the problem mentioned in the previous commit. See
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178401#note_2314230658
for more details.

In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173040, Jest's
output was moved from stdout/err to files to ease debugging of CI jobs.

It turns out that wasn't ideal, since stdout was useful for debugging
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178401#note_2314230658,
where a predictive version of this job was timing out.

The reason it was timing out was that that MR touched a file which many
specs depended upon; too many for a non-parallel, predictive job.

Since Jest writes nothing stdout other than the list of files it
will run (see scripts/frontend/parallel_ci_sequencer.js#L42-44), there's
little risk of the CI job log from getting filled up by it.