| <aid="devopsadoptionsnapshotcodeownersusedcount"></a>`codeOwnersUsedCount` | [`Int`](#int) | Total number of projects with existing CODEOWNERS file. |
| <aid="devopsadoptionsnapshotcoveragefuzzingenabledcount"></a>`coverageFuzzingEnabledCount` | [`Int`](#int) | Total number of projects with enabled coverage fuzzing. |
| <aid="devopsadoptionsnapshotdastenabledcount"></a>`dastEnabledCount` | [`Int`](#int) | Total number of projects with enabled DAST. |
| <aid="devopsadoptionsnapshotdependencyscanningenabledcount"></a>`dependencyScanningEnabledCount` | [`Int`](#int) | Total number of projects with enabled dependency scanning. |
| <aid="devopsadoptionsnapshotdeploysucceeded"></a>`deploySucceeded` | [`Boolean!`](#boolean) | At least one deployment succeeded. |
@@ -43,7 +43,7 @@ If your merge request description does not include these items, the review will
If new migrations are introduced, in the MR **you are required to provide**:
- The output of both migrating and rolling back for all migrations
- The output of both migrating (`db:migrate`) and rolling back (`db:rollback`) for all migrations.
If new queries have been introduced or existing queries have been updated, **you are required to provide**:
...
...
@@ -104,7 +104,7 @@ the following preparations into account.
`db/schema_migrations` were added or removed.
- Make migrations reversible by using the `change` method or include a `down` method when using `up`.
- Include either a rollback procedure or describe how to rollback changes.
- Add the output of both migrating and rolling back for all migrations into the MR description.
- Add the output of both migrating (`db:migrate`) and rolling back (`db:rollback`) for all migrations into the MR description.
- Ensure the down method reverts the changes in `db/structure.sql`.
- Update the migration output whenever you modify the migrations during the review process.
- Add tests for the migration in `spec/migrations` if necessary. See [Testing Rails migrations at GitLab](testing_guide/testing_migrations_guide.md) for more details.
The following table, while not exhaustive, shows some examples of the supported
upgrade paths.
...
...
@@ -213,7 +213,7 @@ upgrade paths.
Upgrading the *major* version requires more attention.
Backward-incompatible changes and migrations are reserved for major versions.
We cannot guarantee that upgrading between major versions will be seamless.
It is suggested to upgrade to the latest available *minor* version within
It is required to upgrade to the latest available *minor* version within
your major version before proceeding to the next major version.
Doing this addresses any backward-incompatible changes or deprecations
to help ensure a successful upgrade to the next major release.
...
...
@@ -373,11 +373,9 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap
- In GitLab 13.3 some [pipeline processing methods were deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/218536)
and this code was completely removed in GitLab 14.0. If you plan to upgrade from
**GitLab 13.2 or older** directly to 14.0, you should not have any pipelines running
when you upgrade. The pipelines might report the wrong status when the upgrade completes.
You should shut down GitLab and wait for all pipelines on runners to complete, then upgrade
GitLab to 14.0. Alternatively, you can first upgrade GitLab to a version between 13.3 and
13.12, then upgrade to 14.0.
**GitLab 13.2 or older** directly to 14.0 ([unsupported](#upgrading-to-a-new-major-version)), you should not have any pipelines running
when you upgrade or the pipelines might report the wrong status when the upgrade completes.
You should instead follow a [supported upgrade path](#upgrade-paths).
- The support of PostgreSQL 11 [has been dropped](../install/requirements.md#database). Make sure to [update your database](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) to version 12 before updating to GitLab 14.0.
### 13.11.0
...
...
@@ -477,7 +475,7 @@ So, if you are using multiple Rails servers and specifically upgrading from 13.0
all servers must first be upgraded to 13.1.Z before upgrading to 13.2.0 or later:
1. Ensure all GitLab web nodes are running GitLab 13.1.Z.
1.Optionally, enable the `global_csrf_token` feature flag to enable new
1.Enable the `global_csrf_token` feature flag to enable new