- /scripts/generate-failed-test-on-omnibus-mr-message.rb
- /scripts/generate-message-to-run-e2e-pipeline.rb
- /doc/development/testing_guide/end_to_end/beginners_guide/page_objects.md
- /doc/development/testing_guide/end_to_end/beginners_guide/resources.md
- /doc/development/testing_guide/end_to_end/_index.md
- /doc/development/ai_features/duo_chat.md
- /spec/scripts/generate_message_to_run_e2e_pipeline_spec.rb
- /.gitlab/issue_templates/Feature Flag Roll Out.md
- /danger/stable_branch_patch/Dangerfile
- /qa/qa/scenario/test/sanity/selectors.rb

To be run in backport MRs
to test upgrade from patch and to patch
before it's released

Signed-off-by: Nailia Iskhakova <niskhakova@gitlab.com>

In preparation for adding support for PG 17, these tests
ensures the basic level of compatibility for Postgres

Note: PG17 integration jobs for opensearch and es8 were
disabled for now, as they'll exceed the limits of jobs
that a pipeline can have

Changelog: changed

Files that can affect docs builds should be listed
as requiring optional TW approval, to include TW team
when needed

As PG16 is the production DB, is important
to have all related specs running.

Changelog: changed

This reverts merge request !172742

There are many RuboCop cops used internally, which have inline
documentation.

These cops can now have documentation generated for them automatically,
so GitLab developers and contributors can reference our documentation
and examples, to better understand the cops as well as the reasoning
behind our decisions.

Also make sure to run rubocop-docs and eslint-docs
jobs when the underlying tooling is updated

Changelog: performance

This fixes that the `ui-docs-links lint` references the old
`DocumentationLinks` linter that was removed in [1].

[1]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/181453

Also updates links to gitlab-docs project

Include compile-production-assets and build-assets-image job when VERSION file is updated in the stable branch

Paths in review apps are different with new site

One of the optimizations for the build and deploy process is to cache
assets as a generic package that can then be consumed by the build
process.

Assets in this context refers to frontend assets built by the
gitlab:assets:compile rake task, which calls out to yarn. We compute a
cached-assets-hash over all frontend files. If none of these source
files changed, the build can reuse the previously compiled assets and
save approximately 40 minutes of build time.

The way this process is intended to work is via a scheduled pipeline on
gitlab-org/gitlab that runs every 2 hours. It checks the
cached-assets-hash, if no package exists, it builds an assets package
and publishes it to the package registry on gitlab-org/gitlab.

This logic was introduced by https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96297. It was most recently updated by https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179950.

That MR introduced a subtle bug: By changing the order of setting
`$GITLAB_ASSETS_HASH` and including
`scripts/gitlab_component_helpers.sh`, that helper library no longer is
able to consume the `$GITLAB_ASSETS_HASH` and instead defaults to the
string `"NO_HASH"`.

There is no logic to fail, when no hash is supplied. And so we compute
a package URL containing the string `NO_HASH`. The job then publishes a
package to that URL, and on the next run it will skip re-compiling
assets, because there already is a package present under `NO_HASH`.

The current cached assets package is 9 days old:

```
$ curl -I https://gitlab.com/api/v4/projects/278964/packages/generic/assets/production-ee-NO_HASH/assets-production-ee-NO_HASH-v2.tar.gz

last-modified: Wed, 05 Feb 2025 22:06:11 GMT
```

The saving grace is that this bug was only introduced for the scheduled
job, and not for the jobs consuming that cache. Thus we avoid building
and deploying omnibus packages or CNG images which contain a stale
cache. We got lucky here.

The only real consequence is that we no longer get any cache hits, so
the build process will always need to rebuild assets, even if none
changed. This was surfaced as part of
https://gitlab.com/gitlab-com/gl-infra/production/-/issues/19280.

This patch fixes the bug by re-introducing the original order. This
allows the cache-assets:production job to produce valid assets cache
packages again, which will speed up builds and deploys in cases where no
assets were changed, which is crucial for rolling forward urgent fixes,
as it cuts 40m from time-to-production.

Additional measures we should consider for more safety:

- Check for NO_HASH and bail out.
- After downloading an assets archive, validate the contained
  cached-assets-hash against the one from the filesystem.

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

Changelog: changed