- /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

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

Changelog: changed

Docs reviews are not optional, but the timing is flexible

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

- For internal_users.rb

Changelog: fixed

This reverts merge request !171439

This check detects changes to the `internal.rb` for *_bot users, or when they are used in `user_type: `
It adds a comment to the overall MR

Changelog: changed

Co-authored-by: Peter Leitzen <pleitzen@gitlab.com>

This Dangerfile used to report CSS utils that were built using string
interpolation. Since introducing it, we have created an ESLint and a
Rubocop rules to perform the same checks, thus providing a better
developer experience for spotting this offences.

The Dangerfile can therefore be removed.

Since https://gitlab.com/gitlab-org/gitlab/-/merge_requests/165146 we
now have a CI job that enforces a required stop has passed before we can
finalize a background migration.

Additionally these danger warnings are quite noisy. For example all the
discussions I had to resolve in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/169518 .

This note does also mention "Check the timings" and theoretically there
may be a case to wait for 2 required stops for any migration that is
very slow but I don't believe we do this in practice. For now I think
we've settled on the following requirements before finalizing:

1. It is finished on GitLab.com
2. We've passed a required stop

And we already have adequate enforcement for these so I don't think this
warning is really helping us anymore.

This commit introduces a new Dangerfile to check for AI logging compliance:

- Detect usage of GitLab::Llm::Logger.build.info and .error methods
- Warn when AI logging is not gated behind expanded_ai_logging flag
- List files with potentially non-compliant AI logging
- Add relevant labels to merge requests with AI logging

This check helps ensure adherence to GitLab's AI data usage policies and
promotes proper AI logging practices across the codebase.

Since https://gitlab.com/gitlab-org/gitlab/-/merge_requests/163878 we
have a check against using legacy utilities. This makes this danger
message kind of obsolete.

The check against interpolated utility classes could be a rubocop /
eslint rule instead.

If a developer sets a cookie from Rails with a `:domain` attribute, they
must remember to un-set this cookie when a user signs out. This can be
hard to remember to do.

This change adds a Danger bot reminder whenever setting cookies is
detected in application code, and also documentation of development
guidelines when working with cookies.

Remove spec

Settings sections can be searched through the command palette.
But this only works if they are kept in sync with the files that drive
that search.

Co-authored-by: Peter Leitzen <pleitzen@gitlab.com>

This Dangerfile dates back to when we gradually adopted prettier. Now
our code base is fully prettier compliant and we have a separate
static-analysis job for prettier _and_ we run it part of lefthook. So
this Danger job just adds noise to the already long danger output and
potentially takes a long time.

Let's remove it, it outlived it's purpose.

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

Refactor with Job Struct

This is a major refactor commit

Finish refactor and unit tests

Suggest to use `feature_category: ...`.

To help make the migration process easier

This reverts merge request !154168

The current fallback note for an unfilled `feature_issue_url:` does not
provide enough context to make it obvious what it's referring to. This
MR adds the file path to direct the author of the MR in the right
direction.

Before:

```
- [ ] config/feature_flags/beta/flag_with_blank_feature_url.yml#L3: Consider filling `feature_issue_url:`
- [ ] Consider filling `feature_issue_url:`
```

After:

```
- [ ] config/feature_flags/beta/flag_with_blank_feature_url.yml#L3: Consider filling `feature_issue_url:`
- [ ] config/feature_flags/beta/flag_with_missing_feature_url.yml: Consider filling `feature_issue_url:`
```

To help make the migration process easier

Changelog: other
EE: true