Danger defines its own `fail` method which caused false positives and
forced inline disables.

- Mention group
- Label support

charlie ablett 创作于 1 year ago ，Jennifer Li 提交于 1 year ago

- Mention group
- Label support

Fail the danger job if a merge request is missing the
~database-testing-automation and isn't on gitlab-org/gitlab
branch label.

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/419001

This prevents errors like:

[!] Invalid `Dangerfile` file: undefined method `present?' for
Danger gem might fix the issue. Your Danger version: 8.6.1, latest
Danger version: 9.3.0

For all new added migrations, the timestamp is checked against current
date and if it's older than three weeks, a warning is displayed in the
Danger message.

- Skip database warnings
- Skip product intelligence review
- Skip data team warnings

Because of limited capacity, the migration testing pipeline is still
manual only. As a result, I'm adding a reminder to the danger message
so that folks kick off the testing pipeline.
Also deduplicates database files and fixes docs review for database docs

Relates to https://gitlab.com/gitlab-org/gitlab/issues/328367

This will reduce the boilerplate code.

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

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

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

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

Please refer to https://gitlab.com/gitlab-org/gitlab/-/issues/341758 for details.

Changelog: changed
EE: true

This opens up the possibility to actually re-use Danger rules accross
projects.

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

This reverts merge request !58130

This opens up the possibility to actually re-use Danger rules accross
projects.

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

The gem provides helpers that can be reused by multiple projects.

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

- for db changes we should always be in non ee.

Changes introduced in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40641 cause this
error:

undefined method has_database_scoped_labels?
from danger/database/Dangerfile:62

I realized since we already detect the category of changes, we can
easily apply the relevant "specialization" labels based on that.

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

Relates to https://gitlab.com/gitlab-org/gitlab/issues/29465

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

Add some extra checkboxes to the database MR template,
e.g. ask author to add SQL and query plan to the
description.

This changes any mention of gitlab-ce to gitlab-foss, and any mention of
gitlab-ee to just gitlab.

This class encapsulates our use of the Danger gem.

This class encapsulates our use of the Danger gem.

This reverts merge request !16168

This reverts merge request !32196

Convert a bunch of Danger rules so they can run
locally.

Convert a bunch of Danger rules so they can run
locally.

See https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6069

Stop using two separate lists for the conditions which files require a
database review.

Related discussion:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30156#note_187732053

This backports all EE schema changes to CE, including EE migrations,
ensuring both use the same schema.

== Updated tests

A spec related to ghost and support bot users had to be modified to make
it pass. The spec in question assumes that the "support_bot" column
exists when defining the spec. In the single codebase setup this is not
the case, as the column is backported in a later migration. Any attempt
to use a different schema version or use of "around" blocks to
conditionally disable specs won't help, as reverting the backport
migration would also drop the "support_bot" column. Removing the
"support_bot" tests entirely appears to be the only solution.

We also need to update some foreign key tests now that we have
backported the EE columns. Fortunately, these changes are very minor.

== Backporting migrations

This commit moves EE specific migrations (except those for the Geo
tracking database) and related files to CE, and also removes any traces
of the ee/db directory.

Some migrations had to be modified or removed, as they no longer work
with the schema being backported. These migrations were all quite old,
so we opted for removing them where modifying them would take too much
time and effort.

Some old migrations were modified in EE, while also existing in CE. In
these cases we took the EE code, and in one case removed them entirely.
It's not worth spending time trying to merge these changes somehow as we
plan to remove old migrations around the release of 12.0, see
https://gitlab.com/gitlab-org/gitlab-ce/issues/59177 for more details.

This backports all EE schema changes to CE, including EE migrations,
ensuring both use the same schema.

== Updated tests

A spec related to ghost and support bot users had to be modified to make
it pass. The spec in question assumes that the "support_bot" column
exists when defining the spec. In the single codebase setup this is not
the case, as the column is backported in a later migration. Any attempt
to use a different schema version or use of "around" blocks to
conditionally disable specs won't help, as reverting the backport
migration would also drop the "support_bot" column. Removing the
"support_bot" tests entirely appears to be the only solution.

We also need to update some foreign key tests now that we have
backported the EE columns. Fortunately, these changes are very minor.

== Backporting migrations

This commit moves EE specific migrations (except those for the Geo
tracking database) and related files to CE, and also removes any traces
of the ee/db directory.

Some migrations had to be modified or removed, as they no longer work
with the schema being backported. These migrations were all quite old,
so we opted for removing them where modifying them would take too much
time and effort.

Some old migrations were modified in EE, while also existing in CE. In
these cases we took the EE code, and in one case removed them entirely.
It's not worth spending time trying to merge these changes somehow as we
plan to remove old migrations around the release of 12.0, see
https://gitlab.com/gitlab-org/gitlab-ce/issues/59177 for more details.

Danger apparently has three different objects which could contain files
you often want to check:

 - git.added_files
 - git.modified_files
 - git.renamed_files

The problem: If a file is renamed, `modified_files` contains the file
path before the rename. In some Danger checks we use `added_files` +
`modified_files`, which might contain the deleted paths of renamed
files, but missing the new paths of renamed files.

So we need to consider `renamed_files` as well.