We want all classes to have the same methods signature.

Signed-off-by: Rémy Coutable <remy@rymai.me>

When making an update or change to the GraphQL API,
the exiting, updated or new frontend components must remain -
backwards-compatible with the existing version of the GraphQL API.

MR authors and reviewers should be warned when they are changing
both frontend and backend GraphQL code.

The rake task `gettext:regenerate` takes around 50 seconds on my machine
to extract _all_ externalized strings from ruby, haml, erb, js and vue
sources. It is implemented in a blocking way and therefore parsing
roughly 20000 files takes a long time.

We are introducing a new tooling script `tooling/bin/gettext_extractor`
which is 3x faster by making the following improvements:

1. We parallelize the extraction of ruby, haml and erb with the
   `parallel` gem.
2. Instead of passing files through a parser stack and checking which
   files a parser can parse, we directly call the parser for each file
   type. The original implementation e.g. checked for every file,
   whether it is a glade file (whatever that is), which took a long
   time.
3. js and vue files are still parsed by a shell-out to the pre-existing
   node script: `scripts/frontend/extract_gettext_all.js`

This new parser is now used under the hood for the rake tasks:
`gettext:regenerate` and `gettext:update_check`.

There is still room for improvement, and we should look into the
following ideas:

1. We currently scan `ee/spec`, which probably should not scan. We still
   scan it for now, in order to have parity in results
2. The shell-out to node can be changed to stream the data, rather than
   blocking until all frontend files are scanned. However initial tests
   have not shown any performance improvements from that.
3. The `HamlParser` probably could use `GetText::RubyParser` instead of
   `RubyGettextExtractor` under the hood.
4. We likely can improve parsing performance _a lot_ by adding guard
   checks to see whether a file actually contains the literal names of
   the gettext methods, e.g. `_(`, `n_(` or `N_(`). We are already doing
   that in the Frontend script and improved performance by at least 20
   percent there: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115561#note_1324725274

Add a comment to MRs targeting stable branches
on canonical when the package-and-test job fails

The packag-and-test pipeline was recently renamed to package-and-test-ee
on https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113818, this
commit updates the name on the Danget stable branch checks.

Signed-off-by: Rémy Coutable <remy@rymai.me>

The package-and-test bridge can be canceled which interrupts the
generation of the downstream pipeline. This commit updates Danger stable
branch checks to account for these scenarios. This will avoid Danger
code failures when no downstream pipeline can be found, e.g. https://gitlab.com/gitlab-org/gitlab/-/jobs/3943016314.

Passing in the permitted classes as the second argument was deprecated
in Psych 3 (https://github.com/ruby/psych/pull/378) and removed in
Psych 4 (https://github.com/ruby/psych/pull/487).

Ruby 3.1 ships with Psych 4, so to make the code work for Ruby 2.7 and
up, use the `permitted_classes` keyword argument.

Part of https://gitlab.com/gitlab-org/gitlab/-/issues/396231

Changelog: changed

Danger currently reports feature_category as missing on the top
level `RSpec.describe` if the describe declaration spans more than
2 lines.

OK:
```
RSpec.describe SomeClass, :js,
  feature_category: 'category' do
```

'Fetaure category missing':
```
RSpec.describe SomeClass,
  :js,
  feature_category: 'category' do
```

This change allows this check to support top level `RSpec.describe`
declarations that span up to 5 lines.

The package-and-test execution is required for merge requests targeting
stable branches. Danger should fail when the package-and-test status is
canceled or manual, or when the pipeline is not present. Previous to
this commit there was a bug in the logic: Danger failed when the
package-and-test pipeline was being created, this is because it
only considered the downstream pipeline status rather than the bridge
status.

This commit ensures both status, the brige and the downstream pipeline
are considered, avoiding the Danger failure when the package-and-test is
being created.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2839

The execution of package-and-test pipeline is required on merge request
targeting stable branches as a way to guarantee the changes introduced
are compliant from the Quality side. This is not necessary for
documentation changes or for merge request fixing flaky failures, so in
this case it's fine to skip the Danger message.

This commit updates the stable branch checks to skip the
package-and-test message on trivial merge requests with documentation
changes only or with fixes for flaky failures.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2839

We are using this method already but it only exists
from Ruby 3.0 onward.

We can for now address this with a simple monkey patch.

After the rollout, it can be removed.

As part of extending the maintenance policy, the package-and-test
pipeline execution should be enforced on stable branches. When this
pipeline is manual or canceled, Danger should fail indicating the MR
author an action is required from them.

This commit ensure Danger considers the downstream pipeline status,
rather than the bridge status.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2839

The package-and-test pipeline is automatically executed on merge
requests targeting stable branches. Pending on the status, different
messages are posted by Danger guiding engineers on its usage. This
commit hightlights and records these messages for awareness.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2839

While testing the release tooling for the maintenance policy, it was
noted documentation MRs fail with a Danger check. The check validates
merge requests targeting stable branches have the `type::bug` label, for
documentation changes it shouldn't be required to have the label because
doc updates are not bug fixes. This commit skips the danger check on
documentation merge requests.

Related to https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/2839

Danger bot comments on merge request with
a note linking to documentation when there is a change
of sidekiq worker arguments

- Fail Danger on stable branches with pipeline::expidite
- Add message detailing what to do on package-and-test
  failures on stable branch MRs
- Check package-and-test status and fail if it has not
  started running

Updates Danger rules on stable branches to only warn
if the version is outside of the maintenance policy.

Not based on a k8s secret it contains, but rather
based on the namespace name