diff --git a/app/controllers/projects/releases_controller.rb b/app/controllers/projects/releases_controller.rb
index d5f93c4baf64d24017248d5f67ef505b618720dd..d1f4b2653c50729b71e811fae62a0e2ccb8aaadc 100644
--- a/app/controllers/projects/releases_controller.rb
+++ b/app/controllers/projects/releases_controller.rb
@@ -8,7 +8,7 @@ class Projects::ReleasesController < Projects::ApplicationController
before_action do
push_frontend_feature_flag(:release_issue_summary, project)
push_frontend_feature_flag(:release_evidence_collection, project, default_enabled: true)
- push_frontend_feature_flag(:release_show_page, project)
+ push_frontend_feature_flag(:release_show_page, project, default_enabled: true)
end
before_action :authorize_update_release!, only: %i[edit update]
before_action :authorize_read_release_evidence!, only: [:evidence]
@@ -31,7 +31,7 @@ class Projects::ReleasesController < Projects::ApplicationController
end
def show
- return render_404 unless Feature.enabled?(:release_show_page, project)
+ return render_404 unless Feature.enabled?(:release_show_page, project, default_enabled: true)
respond_to do |format|
format.html do
diff --git a/app/presenters/release_presenter.rb b/app/presenters/release_presenter.rb
index 2f91495c34c8850c27856cc2fefa87c004a780a4..8cf7446ce644bd399ddbcf2b361959c3365904c8 100644
--- a/app/presenters/release_presenter.rb
+++ b/app/presenters/release_presenter.rb
@@ -20,7 +20,7 @@ class ReleasePresenter < Gitlab::View::Presenter::Delegated
end
def self_url
- return unless ::Feature.enabled?(:release_show_page, project)
+ return unless ::Feature.enabled?(:release_show_page, project, default_enabled: true)
project_release_url(project, release)
end
diff --git a/app/views/projects/pipeline_schedules/index.html.haml b/app/views/projects/pipeline_schedules/index.html.haml
index 4a0be9e67cb40b4f190fc660a4717666a3e275e0..2b2b79d886bb7b7a88979626fc43a4f16bd6e2e0 100644
--- a/app/views/projects/pipeline_schedules/index.html.haml
+++ b/app/views/projects/pipeline_schedules/index.html.haml
@@ -2,7 +2,7 @@
- page_title _("Pipeline Schedules")
-#pipeline-schedules-callout{ data: { docs_url: help_page_path('user/project/pipelines/schedules') } }
+#pipeline-schedules-callout{ data: { docs_url: help_page_path('ci/pipelines/schedules') } }
.top-area
- schedule_path_proc = ->(scope) { pipeline_schedules_path(@project, scope: scope) }
= render "tabs", schedule_path_proc: schedule_path_proc, all_schedules: @all_schedules, scope: @scope
diff --git a/changelogs/unreleased/nfriend-enable-release-show-page-feature-flag.yml b/changelogs/unreleased/nfriend-enable-release-show-page-feature-flag.yml
new file mode 100644
index 0000000000000000000000000000000000000000..882d489613d56c3c0546581afa7d0fad811e26c6
--- /dev/null
+++ b/changelogs/unreleased/nfriend-enable-release-show-page-feature-flag.yml
@@ -0,0 +1,5 @@
+---
+title: Add dedicated Release page for viewing a single Release
+merge_request: 26502
+author:
+type: added
diff --git a/doc/README.md b/doc/README.md
index 3efba168f480f696957e78721fc28842ccc4e5eb..1c0911cdbc0d11f1baafca126f0cde53a5069492 100644
--- a/doc/README.md
+++ b/doc/README.md
@@ -287,7 +287,7 @@ The following documentation relates to the DevOps **Release** stage:
| [GitLab CI/CD](ci/README.md) | Explore the features and capabilities of Continuous Deployment and Delivery with GitLab. |
| [GitLab Pages](user/project/pages/index.md) | Build, test, and deploy a static site directly from GitLab. |
| [Protected Runners](ci/runners/README.md#protected-runners) | Select Runners to only pick jobs for protected branches and tags. |
-| [Scheduled Pipelines](user/project/pipelines/schedules.md) | Execute pipelines on a schedule. |
+| [Scheduled Pipelines](ci/pipelines/schedules.md) | Execute pipelines on a schedule. |
diff --git a/doc/administration/auth/crowd.md b/doc/administration/auth/crowd.md
index da6c01ec3827c58faa4d40d758af645649cb7753..6c2e4edac31d1f97d290fc813782a7a8573b38a1 100644
--- a/doc/administration/auth/crowd.md
+++ b/doc/administration/auth/crowd.md
@@ -54,7 +54,7 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
**Source:**
- ```
+ ```yaml
- { name: 'crowd',
args: {
crowd_server_url: 'CROWD_SERVER_URL',
diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md
index db7c11ada10f452e67747ebfc8abcf59f81735a8..067fdfd0018e6d2c1463961ec6724f62763e33d8 100644
--- a/doc/administration/auth/ldap.md
+++ b/doc/administration/auth/ldap.md
@@ -405,7 +405,7 @@ production:
Tip: If you want to limit access to the nested members of an Active Directory
group, you can use the following syntax:
-```text
+```plaintext
(memberOf:1.2.840.113556.1.4.1941:=CN=My Group,DC=Example,DC=com)
```
@@ -423,13 +423,13 @@ The `user_filter` DN can contain special characters. For example:
- A comma:
- ```text
+ ```plaintext
OU=GitLab, Inc,DC=gitlab,DC=com
```
- Open and close brackets:
- ```text
+ ```plaintext
OU=Gitlab (Inc),DC=gitlab,DC=com
```
@@ -438,13 +438,13 @@ The `user_filter` DN can contain special characters. For example:
- Escape commas with `\2C`. For example:
- ```text
+ ```plaintext
OU=GitLab\2C Inc,DC=gitlab,DC=com
```
- Escape open and close brackets with `\28` and `\29`, respectively. For example:
- ```text
+ ```plaintext
OU=Gitlab \28Inc\29,DC=gitlab,DC=com
```
@@ -603,7 +603,7 @@ GitLab. Common combinations are `encryption: 'plain'` and `port: 389`, OR
If GitLab cannot reach your LDAP endpoint, you will see a message like this:
-```
+```plaintext
Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
```
diff --git a/doc/administration/auth/okta.md b/doc/administration/auth/okta.md
index c83645ffe740aa3338030eeacc517215f81912b0..4fd37b51f248467585de620f70ad0c79ed3516b5 100644
--- a/doc/administration/auth/okta.md
+++ b/doc/administration/auth/okta.md
@@ -86,9 +86,9 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
Edit `config/gitlab.yml`:
- ```yaml
- auto_link_saml_user: true
- ```
+ ```yaml
+ auto_link_saml_user: true
+ ```
1. Add the provider configuration.
diff --git a/doc/administration/geo/replication/database.md b/doc/administration/geo/replication/database.md
index 0e6583741bc10ca9d73c93818d367595664a5072..48681d0383832ba9e72f7b74bc53f25beafd4a9f 100644
--- a/doc/administration/geo/replication/database.md
+++ b/doc/administration/geo/replication/database.md
@@ -495,7 +495,7 @@ work:
1. On the **secondary** nodes, change `/etc/gitlab/gitlab.rb`:
- ```
+ ```ruby
geo_postgresql['fdw_external_user'] = 'gitlab_geo_fdw'
```
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index c3e1da3311fb75820872c4cb7b8962554880aab6..2eeca41724e76d7d41e35e85fc30d01ca0e29127 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -46,7 +46,7 @@ sudo gitlab-rake gitlab:geo:check
Example output:
-```text
+```plaintext
Checking Geo ...
GitLab Geo is available ... yes
@@ -79,7 +79,7 @@ sudo gitlab-rake geo:status
Example output:
-```text
+```plaintext
http://secondary.example.com/
-----------------------------------------------------
GitLab Version: 11.10.4-ee
@@ -134,11 +134,11 @@ sudo gitlab-rake gitlab:geo:check
It displays the current machine's node name and whether the matching database
record is a **primary** or **secondary** node.
-```
+```plaintext
This machine's Geo node name matches a database record ... yes, found a secondary node named "Shanghai"
```
-```
+```plaintext
This machine's Geo node name matches a database record ... no
Try fixing it:
You could add or update a Geo node database record, setting the name to "https://example.com/".
@@ -157,95 +157,95 @@ sudo gitlab-rake gitlab:geo:check
1. Rails did not provide a password when connecting to the database
- ```text
- Checking Geo ...
+ ```plaintext
+ Checking Geo ...
- GitLab Geo is available ... Exception: fe_sendauth: no password supplied
- GitLab Geo is enabled ... Exception: fe_sendauth: no password supplied
- ...
- Checking Geo ... Finished
- ```
+ GitLab Geo is available ... Exception: fe_sendauth: no password supplied
+ GitLab Geo is enabled ... Exception: fe_sendauth: no password supplied
+ ...
+ Checking Geo ... Finished
+ ```
- - Ensure that you have the `gitlab_rails['db_password']` set to the plain text-password used when creating the hash for `postgresql['sql_user_password']`.
+ - Ensure that you have the `gitlab_rails['db_password']` set to the plain text-password used when creating the hash for `postgresql['sql_user_password']`.
1. Rails is unable to connect to the database
- ```text
- Checking Geo ...
+ ```plaintext
+ Checking Geo ...
- GitLab Geo is available ... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on
- FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off
- GitLab Geo is enabled ... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on
- FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off
- ...
- Checking Geo ... Finished
- ```
+ GitLab Geo is available ... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on
+ FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off
+ GitLab Geo is enabled ... Exception: FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL on
+ FATAL: no pg_hba.conf entry for host "1.1.1.1", user "gitlab", database "gitlabhq_production", SSL off
+ ...
+ Checking Geo ... Finished
+ ```
- - Ensure that you have the IP address of the rails node included in `postgresql['md5_auth_cidr_addresses']`.
- - Ensure that you have included the subnet mask on the IP address: `postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']`.
+ - Ensure that you have the IP address of the rails node included in `postgresql['md5_auth_cidr_addresses']`.
+ - Ensure that you have included the subnet mask on the IP address: `postgresql['md5_auth_cidr_addresses'] = ['1.1.1.1/32']`.
1. Rails has supplied the incorrect password
- ```text
- Checking Geo ...
- GitLab Geo is available ... Exception: FATAL: password authentication failed for user "gitlab"
- FATAL: password authentication failed for user "gitlab"
- GitLab Geo is enabled ... Exception: FATAL: password authentication failed for user "gitlab"
- FATAL: password authentication failed for user "gitlab"
- ...
- Checking Geo ... Finished
- ```
+ ```plaintext
+ Checking Geo ...
+ GitLab Geo is available ... Exception: FATAL: password authentication failed for user "gitlab"
+ FATAL: password authentication failed for user "gitlab"
+ GitLab Geo is enabled ... Exception: FATAL: password authentication failed for user "gitlab"
+ FATAL: password authentication failed for user "gitlab"
+ ...
+ Checking Geo ... Finished
+ ```
- - Verify the correct password is set for `gitlab_rails['db_password']` that was used when creating the hash in `postgresql['sql_user_password']` by running `gitlab-ctl pg-password-md5 gitlab` and entering the password.
+ - Verify the correct password is set for `gitlab_rails['db_password']` that was used when creating the hash in `postgresql['sql_user_password']` by running `gitlab-ctl pg-password-md5 gitlab` and entering the password.
1. Check returns not a secondary node
- ```text
- Checking Geo ...
+ ```plaintext
+ Checking Geo ...
- GitLab Geo is available ... yes
- GitLab Geo is enabled ... yes
- GitLab Geo secondary database is correctly configured ... not a secondary node
- Database replication enabled? ... not a secondary node
- ...
- Checking Geo ... Finished
- ```
+ GitLab Geo is available ... yes
+ GitLab Geo is enabled ... yes
+ GitLab Geo secondary database is correctly configured ... not a secondary node
+ Database replication enabled? ... not a secondary node
+ ...
+ Checking Geo ... Finished
+ ```
- - Ensure that you have added the secondary node in the Admin Area of the **primary** node.
- - Ensure that you entered the `external_url` or `gitlab_rails['geo_node_name']` when adding the secondary node in the admin are of the **primary** node.
- - Prior to GitLab 12.4, edit the secondary node in the Admin Area of the **primary** node and ensure that there is a trailing `/` in the `Name` field.
+ - Ensure that you have added the secondary node in the Admin Area of the **primary** node.
+ - Ensure that you entered the `external_url` or `gitlab_rails['geo_node_name']` when adding the secondary node in the admin are of the **primary** node.
+ - Prior to GitLab 12.4, edit the secondary node in the Admin Area of the **primary** node and ensure that there is a trailing `/` in the `Name` field.
1. Check returns Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist
- ```text
- Checking Geo ...
-
- GitLab Geo is available ... no
- Try fixing it:
- Upload a new license that includes the GitLab Geo feature
- For more information see:
- https://about.gitlab.com/features/gitlab-geo/
- GitLab Geo is enabled ... Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist
- LINE 8: WHERE a.attrelid = '"geo_nodes"'::regclass
- ^
- : SELECT a.attname, format_type(a.atttypid, a.atttypmod),
- pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod,
- c.collname, col_description(a.attrelid, a.attnum) AS comment
- FROM pg_attribute a
- LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum
- LEFT JOIN pg_type t ON a.atttypid = t.oid
- LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation
- WHERE a.attrelid = '"geo_nodes"'::regclass
- AND a.attnum > 0 AND NOT a.attisdropped
- ORDER BY a.attnum
- ...
- Checking Geo ... Finished
- ```
-
- When performing a Postgres major version (9 > 10) update this is expected. Follow:
-
- - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
- - [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)
+ ```plaintext
+ Checking Geo ...
+
+ GitLab Geo is available ... no
+ Try fixing it:
+ Upload a new license that includes the GitLab Geo feature
+ For more information see:
+ https://about.gitlab.com/features/gitlab-geo/
+ GitLab Geo is enabled ... Exception: PG::UndefinedTable: ERROR: relation "geo_nodes" does not exist
+ LINE 8: WHERE a.attrelid = '"geo_nodes"'::regclass
+ ^
+ : SELECT a.attname, format_type(a.atttypid, a.atttypmod),
+ pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod,
+ c.collname, col_description(a.attrelid, a.attnum) AS comment
+ FROM pg_attribute a
+ LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum
+ LEFT JOIN pg_type t ON a.atttypid = t.oid
+ LEFT JOIN pg_collation c ON a.attcollation = c.oid AND a.attcollation <> t.typcollation
+ WHERE a.attrelid = '"geo_nodes"'::regclass
+ AND a.attnum > 0 AND NOT a.attisdropped
+ ORDER BY a.attnum
+ ...
+ Checking Geo ... Finished
+ ```
+
+ When performing a Postgres major version (9 > 10) update this is expected. Follow:
+
+ - [initiate-the-replication-process](database.md#step-3-initiate-the-replication-process)
+ - [Geo database has an outdated FDW remote schema](troubleshooting.md#geo-database-has-an-outdated-fdw-remote-schema-error)
## Fixing replication errors
@@ -483,7 +483,7 @@ when promoting a secondary to a primary node with strategies to resolve them.
When [promoting a **secondary** node](../disaster_recovery/index.md#step-3-promoting-a-secondary-node),
you might encounter the following error:
-```text
+```plaintext
Running gitlab-rake geo:set_secondary_as_primary...
rake aborted!
@@ -523,7 +523,7 @@ This section documents ways to fix potential Foreign Data Wrapper errors.
When setting up Geo, you might see this warning in the `gitlab-rake
gitlab:geo:check` output:
-```text
+```plaintext
GitLab Geo tracking database Foreign Data Wrapper schema is up-to-date? ... foreign data wrapper is not configured
```
@@ -607,7 +607,7 @@ To check the configuration:
1. Check that the foreign server mapping is correct via `\des+`. The
results should look something like this:
- ```
+ ```plaintext
gitlabhq_geo_production=# \des+
List of foreign servers
-[ RECORD 1 ]--------+------------------------------------------------------------
@@ -643,7 +643,7 @@ To check the configuration:
1. Check that the user mapping is configured properly via `\deu+`:
- ```
+ ```plaintext
gitlabhq_geo_production=# \deu+
List of user mappings
Server | User name | FDW Options
@@ -731,7 +731,7 @@ GitLab can error with a `Geo database has an outdated FDW remote schema` message
For example:
-```text
+```plaintext
Geo database has an outdated FDW remote schema. It contains 229 of 236 expected tables. Please refer to Geo Troubleshooting.
```
diff --git a/doc/administration/git_annex.md b/doc/administration/git_annex.md
index 49a22dc6a52484ccf584aea806d700dd449e3961..8f285cd9bcb1e85e261b7dee8a8accfaa0d1b44e 100644
--- a/doc/administration/git_annex.md
+++ b/doc/administration/git_annex.md
@@ -43,13 +43,13 @@ configuration options required to enable it.
For Debian-like systems (for example, Debian and Ubuntu) this can be achieved by running:
-```
+```shell
sudo apt-get update && sudo apt-get install git-annex
```
For RedHat-like systems (for example, CentOS and RHEL) this can be achieved by running:
-```
+```shell
sudo yum install epel-release && sudo yum install git-annex
```
@@ -108,7 +108,7 @@ git annex sync --content # sync the Git repo and large file to the GitLa
The output should look like this:
-```
+```plaintext
commit
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
@@ -154,7 +154,7 @@ are turned into symbolic links that point to data in `.git/annex/objects/`.
The `debian.iso` file in the example will contain the symbolic link:
-```
+```plaintext
.git/annex/objects/ZW/1k/SHA256E-s82701--6384039733b5035b559efd5a2e25a493ab6e09aabfd5162cc03f6f0ec238429d.png/SHA256E-s82701--6384039733b5035b559efd5a2e25a493ab6e09aabfd5162cc03f6f0ec238429d.iso
```
@@ -216,14 +216,14 @@ and the files are pushed to the GitLab repository.
If you get hit by this, you can run the following command inside the repository
that the warning was raised:
-```
+```shell
git config remote.origin.annex-ignore false
```
Consecutive runs of `git annex sync --content` **should not** produce this
warning and the output should look like this:
-```
+```plaintext
commit ok
pull origin
ok
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 20c57683708a2deb26a2b6b8cc455ae085827c82..783ae1e03174f8b1f3732f135065a03a7ff09c9e 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -121,7 +121,7 @@ node, using `psql` which is installed by GitLab Omnibus.
```sql
CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD 'PRAEFECT_SQL_PASSWORD';
- ```
+ ```
1. Reconnect to the PostgreSQL server, this time as the `praefect` user:
diff --git a/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md b/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md
index 3f983bebf27e9a08baf40141402b8e06c2274855..bfe18f697bfec6f7c6fc5eda129bd8a47547af7a 100644
--- a/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md
+++ b/doc/administration/lfs/migrate_from_git_annex_to_git_lfs.md
@@ -57,7 +57,7 @@ Fire up a terminal, navigate to your Git repository and:
1. Enable `git-lfs`:
- ```
+ ```shell
git lfs install
git lfs track
git add .
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index d224ba51bb308ff54524a7940b8a9abaa9096d2e..e45e39c46517fc9c9be0d5a9d0a07bdadb68fefc 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -353,7 +353,7 @@ GitLab uses background jobs for processing tasks which can take a long
time. All information about processing these jobs are written down to
this file. For example:
-```
+```plaintext
2014-06-10T07:55:20Z 2037 TID-tm504 ERROR: /opt/bitnami/apps/discourse/htdocs/vendor/bundle/ruby/1.9.1/gems/redis-3.0.7/lib/redis/client.rb:228:in `read'
2014-06-10T18:18:26Z 14299 TID-55uqo INFO: Booting Sidekiq 3.0.0 with redis options {:url=>"redis://localhost:6379/0", :namespace=>"sidekiq"}
```
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index 87114c154a205d66b8906d285f2fcbf5f1d11900..d29eb26643142e77aeed938c2b81925935db27a2 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -135,9 +135,9 @@ To use an external Prometheus server:
1. Install and set up a dedicated Prometheus instance, if necessary, using the [official installation instructions](https://prometheus.io/docs/prometheus/latest/installation/).
1. Add the Prometheus server IP address to the [monitoring IP whitelist](../ip_whitelist.md). For example:
- ```ruby
- gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
- ```
+ ```ruby
+ gitlab_rails['monitoring_whitelist'] = ['127.0.0.0/8', '192.168.0.1']
+ ```
1. To scrape NGINX metrics, you'll also need to configure NGINX to allow the Prometheus server
IP. For example:
diff --git a/doc/administration/operations/ssh_certificates.md b/doc/administration/operations/ssh_certificates.md
index 1fa3555e604ad6682600c90764658f2fe3dede82..5a9caa36cf8aae4a2d4571ce772641db01b0bfbb 100644
--- a/doc/administration/operations/ssh_certificates.md
+++ b/doc/administration/operations/ssh_certificates.md
@@ -40,7 +40,7 @@ it](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/htm
We assume that you already have SSH certificates set up, and have
added the `TrustedUserCAKeys` of your CA to your `sshd_config`, e.g.:
-```
+```plaintext
TrustedUserCAKeys /etc/security/mycompany_user_ca.pub
```
@@ -87,7 +87,7 @@ Then, in your `sshd_config` set up `AuthorizedPrincipalsCommand` for
the `git` user. Hopefully you can use the default one shipped with
GitLab:
-```
+```plaintext
Match User git
AuthorizedPrincipalsCommandUser root
AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers
@@ -95,7 +95,7 @@ Match User git
This command will emit output that looks something like:
-```
+```shell
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell username-{KEY_ID}",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty {PRINCIPAL}
```
@@ -108,7 +108,7 @@ some principal that's guaranteed to be part of the key for all users
who can log in to GitLab, or you must provide a list of principals,
one of which is going to be present for the user, e.g.:
-```
+```plaintext
[...]
AuthorizedPrincipalsCommand /opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell-authorized-principals-check %i sshUsers windowsUsers
```
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 8515cd909dbd8ba70728f196e8643f03b20ab7f8..36c5c29a6fb344b0468b95341bc3c0e1ea21789e 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -360,16 +360,16 @@ that method from working. Use the following workaround:
1. Append your GitLab server TLS/SSL certficate to `/opt/gitlab/embedded/ssl/certs/cacert.pem` where `gitlab-domain-example.com` is your GitLab application URL
- ```shell
- printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
- echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
- ```
+ ```shell
+ printf "\ngitlab-domain-example.com\n===========================\n" | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
+ echo -n | openssl s_client -connect gitlab-domain-example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | sudo tee --append /opt/gitlab/embedded/ssl/certs/cacert.pem
+ ```
1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances:
- ```shell
- sudo gitlab-ctl restart gitlab-pages
- ```
+ ```shell
+ sudo gitlab-ctl restart gitlab-pages
+ ```
CAUTION: **Caution:**
Some GitLab Omnibus upgrades will revert this workaround and you'll need to apply it again.
diff --git a/doc/administration/reply_by_email_postfix_setup.md b/doc/administration/reply_by_email_postfix_setup.md
index 3a28e37cfc003bec31f753674161d2c3b55b748f..c6da88a0eecbfc9fbe145aef4229030a0600612a 100644
--- a/doc/administration/reply_by_email_postfix_setup.md
+++ b/doc/administration/reply_by_email_postfix_setup.md
@@ -73,7 +73,7 @@ The instructions make the assumption that you will be using the email address `i
1. Send the new `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
- ```
+ ```plaintext
ehlo localhost
mail from: root@localhost
rcpt to: incoming@localhost
@@ -101,7 +101,7 @@ The instructions make the assumption that you will be using the email address `i
You should see output like this:
- ```
+ ```plaintext
"/var/mail/incoming": 1 message 1 unread
>U 1 root@localhost 59/2842 Re: Some issue
```
@@ -147,7 +147,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
You should see output like this:
- ```
+ ```plaintext
"/home/incoming/Maildir": 1 message 1 unread
>U 1 root@localhost 59/2842 Re: Some issue
```
@@ -253,7 +253,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
1. Send the `incoming` user a dummy email to test SMTP, by entering the following into the SMTP prompt:
- ```
+ ```plaintext
ehlo gitlab.example.com
mail from: root@gitlab.example.com
rcpt to: incoming@gitlab.example.com
@@ -277,7 +277,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
You should see output like this:
- ```
+ ```plaintext
"/home/incoming/Maildir": 1 message 1 unread
>U 1 root@gitlab.example.com 59/2842 Re: Some issue
```
@@ -313,7 +313,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
1. Sign in as the `incoming` user to test IMAP, by entering the following into the IMAP prompt:
- ```
+ ```plaintext
a login incoming PASSWORD
```
@@ -321,7 +321,7 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
You should see output like this:
- ```
+ ```plaintext
a OK LOGIN Ok.
```
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index c73539cbdb45552248001d71495f3d35f06fb9da..5ca1dd18da3737f58393184329c0f2d61d88dd4b 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -15,7 +15,7 @@ storage shards) to distribute the storage load between several mount points.
Example: this is OK:
-```
+```plaintext
default:
path: /mnt/git-storage-1
storage2:
@@ -24,7 +24,7 @@ storage2:
This is not OK because it nests storage paths:
-```
+```plaintext
default:
path: /mnt/git-storage-1
storage2:
diff --git a/doc/administration/static_objects_external_storage.md b/doc/administration/static_objects_external_storage.md
index 373e4366a1f48acad00f556aad0fc89e75e662c6..f649a1ebcd2805f8cad5172bd417a9b9526daaab 100644
--- a/doc/administration/static_objects_external_storage.md
+++ b/doc/administration/static_objects_external_storage.md
@@ -63,158 +63,158 @@ other CDNs or Function as a Service (FaaS) systems should work using the same pr
`pwgen -cn1 64` on a UNIX machine). Save this token for the admin panel, as
described in the [configuring](#configuring) section.
- ```js
- const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE
- const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE
- const CACHE_PRIVATE_OBJECTS = false
-
- const CORS_HEADERS = {
- 'Access-Control-Allow-Origin': '*',
- 'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
- 'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
- }
-
- self.addEventListener('fetch', event => event.respondWith(handle(event)))
-
- async function handle(event) {
- try {
- let response = await verifyAndHandle(event);
-
- // responses returned from cache are immutable, so we recreate them
- // to set CORS headers
- response = new Response(response.body, response)
- response.headers.set('Access-Control-Allow-Origin', '*')
-
- return response
- } catch (e) {
- return new Response('An error occurred!', {status: e.statusCode || 500})
- }
- }
-
- async function verifyAndHandle(event) {
- if (!validRequest(event.request)) {
- return new Response(null, {status: 400})
- }
-
- if (event.request.method === 'OPTIONS') {
- return handleOptions(event.request)
- }
-
- return handleRequest(event)
- }
-
- function handleOptions(request) {
- // Make sure the necessary headers are present
- // for this to be a valid pre-flight request
- if (
- request.headers.get('Origin') !== null &&
- request.headers.get('Access-Control-Request-Method') !== null &&
- request.headers.get('Access-Control-Request-Headers') !== null
- ) {
- // Handle CORS pre-flight request
- return new Response(null, {
- headers: CORS_HEADERS,
- })
- } else {
- // Handle standard OPTIONS request
- return new Response(null, {
- headers: {
- Allow: 'GET, HEAD, OPTIONS',
- },
- })
- }
- }
-
- async function handleRequest(event) {
- let cache = caches.default
- let url = new URL(event.request.url)
- let static_object_token = url.searchParams.get('token')
- let headers = new Headers(event.request.headers)
-
- url.host = ORIGIN_HOSTNAME
- url = normalizeQuery(url)
-
- headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN)
- if (static_object_token !== null) {
- headers.set('X-Gitlab-Static-Object-Token', static_object_token)
- }
-
- let request = new Request(url, { headers: headers })
- let cached_response = await cache.match(request)
- let is_conditional_header_set = headers.has('If-None-Match')
-
- if (cached_response) {
- return cached_response
- }
-
- // We don't want to override If-None-Match that is set on the original request
- if (cached_response && !is_conditional_header_set) {
- headers.set('If-None-Match', cached_response.headers.get('ETag'))
- }
-
- let response = await fetch(request, {
- headers: headers,
- redirect: 'manual'
- })
-
- if (response.status == 304) {
- if (is_conditional_header_set) {
- return response
- } else {
- return cached_response
- }
- } else if (response.ok) {
- response = new Response(response.body, response)
-
- // cache.put will never cache any response with a Set-Cookie header
- response.headers.delete('Set-Cookie')
-
- if (CACHE_PRIVATE_OBJECTS) {
- response.headers.delete('Cache-Control')
- }
-
- event.waitUntil(cache.put(request, response.clone()))
- }
-
- return response
- }
-
- function normalizeQuery(url) {
- let searchParams = url.searchParams
- url = new URL(url.toString().split('?')[0])
-
- if (url.pathname.includes('/raw/')) {
- let inline = searchParams.get('inline')
-
- if (inline == 'false' || inline == 'true') {
- url.searchParams.set('inline', inline)
- }
- } else if (url.pathname.includes('/-/archive/')) {
- let append_sha = searchParams.get('append_sha')
- let path = searchParams.get('path')
-
- if (append_sha == 'false' || append_sha == 'true') {
- url.searchParams.set('append_sha', append_sha)
- }
- if (path) {
- url.searchParams.set('path', path)
- }
- }
-
- return url
- }
-
- function validRequest(request) {
- let url = new URL(request.url)
- let path = url.pathname
-
- if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) {
- return true
- }
-
- return false
- }
- ```
+ ```js
+ const ORIGIN_HOSTNAME = 'gitlab.installation.com' // FIXME: SET CORRECT VALUE
+ const STORAGE_TOKEN = 'very-secure-token' // FIXME: SET CORRECT VALUE
+ const CACHE_PRIVATE_OBJECTS = false
+
+ const CORS_HEADERS = {
+ 'Access-Control-Allow-Origin': '*',
+ 'Access-Control-Allow-Methods': 'GET, HEAD, OPTIONS',
+ 'Access-Control-Allow-Headers': 'X-Csrf-Token, X-Requested-With',
+ }
+
+ self.addEventListener('fetch', event => event.respondWith(handle(event)))
+
+ async function handle(event) {
+ try {
+ let response = await verifyAndHandle(event);
+
+ // responses returned from cache are immutable, so we recreate them
+ // to set CORS headers
+ response = new Response(response.body, response)
+ response.headers.set('Access-Control-Allow-Origin', '*')
+
+ return response
+ } catch (e) {
+ return new Response('An error occurred!', {status: e.statusCode || 500})
+ }
+ }
+
+ async function verifyAndHandle(event) {
+ if (!validRequest(event.request)) {
+ return new Response(null, {status: 400})
+ }
+
+ if (event.request.method === 'OPTIONS') {
+ return handleOptions(event.request)
+ }
+
+ return handleRequest(event)
+ }
+
+ function handleOptions(request) {
+ // Make sure the necessary headers are present
+ // for this to be a valid pre-flight request
+ if (
+ request.headers.get('Origin') !== null &&
+ request.headers.get('Access-Control-Request-Method') !== null &&
+ request.headers.get('Access-Control-Request-Headers') !== null
+ ) {
+ // Handle CORS pre-flight request
+ return new Response(null, {
+ headers: CORS_HEADERS,
+ })
+ } else {
+ // Handle standard OPTIONS request
+ return new Response(null, {
+ headers: {
+ Allow: 'GET, HEAD, OPTIONS',
+ },
+ })
+ }
+ }
+
+ async function handleRequest(event) {
+ let cache = caches.default
+ let url = new URL(event.request.url)
+ let static_object_token = url.searchParams.get('token')
+ let headers = new Headers(event.request.headers)
+
+ url.host = ORIGIN_HOSTNAME
+ url = normalizeQuery(url)
+
+ headers.set('X-Gitlab-External-Storage-Token', STORAGE_TOKEN)
+ if (static_object_token !== null) {
+ headers.set('X-Gitlab-Static-Object-Token', static_object_token)
+ }
+
+ let request = new Request(url, { headers: headers })
+ let cached_response = await cache.match(request)
+ let is_conditional_header_set = headers.has('If-None-Match')
+
+ if (cached_response) {
+ return cached_response
+ }
+
+ // We don't want to override If-None-Match that is set on the original request
+ if (cached_response && !is_conditional_header_set) {
+ headers.set('If-None-Match', cached_response.headers.get('ETag'))
+ }
+
+ let response = await fetch(request, {
+ headers: headers,
+ redirect: 'manual'
+ })
+
+ if (response.status == 304) {
+ if (is_conditional_header_set) {
+ return response
+ } else {
+ return cached_response
+ }
+ } else if (response.ok) {
+ response = new Response(response.body, response)
+
+ // cache.put will never cache any response with a Set-Cookie header
+ response.headers.delete('Set-Cookie')
+
+ if (CACHE_PRIVATE_OBJECTS) {
+ response.headers.delete('Cache-Control')
+ }
+
+ event.waitUntil(cache.put(request, response.clone()))
+ }
+
+ return response
+ }
+
+ function normalizeQuery(url) {
+ let searchParams = url.searchParams
+ url = new URL(url.toString().split('?')[0])
+
+ if (url.pathname.includes('/raw/')) {
+ let inline = searchParams.get('inline')
+
+ if (inline == 'false' || inline == 'true') {
+ url.searchParams.set('inline', inline)
+ }
+ } else if (url.pathname.includes('/-/archive/')) {
+ let append_sha = searchParams.get('append_sha')
+ let path = searchParams.get('path')
+
+ if (append_sha == 'false' || append_sha == 'true') {
+ url.searchParams.set('append_sha', append_sha)
+ }
+ if (path) {
+ url.searchParams.set('path', path)
+ }
+ }
+
+ return url
+ }
+
+ function validRequest(request) {
+ let url = new URL(request.url)
+ let path = url.pathname
+
+ if (/^(.+)(\/raw\/|\/-\/archive\/)/.test(path)) {
+ return true
+ }
+
+ return false
+ }
+ ```
1. Create a new worker with this script.
1. Copy your values for `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index db8d186db43353b0e30f45fafa614e71b9022d8a..c1f2a5c92a3ebc577495c2892d4b358eea271b7c 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -33,7 +33,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
```ruby
irb(main):002:0> ActionMailer::Base.smtp_settings
- => {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}```
+ => {:address=>"localhost", :port=>25, :domain=>"localhost.localdomain", :user_name=>nil, :password=>nil, :authentication=>nil, :enable_starttls_auto=>true}
```
In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
@@ -56,13 +56,13 @@ For more advanced issues, `gdb` is a must-have tool for debugging issues.
To install on Ubuntu/Debian:
-```
+```shell
sudo apt-get install gdb
```
On CentOS:
-```
+```shell
sudo yum install gdb
```
@@ -103,14 +103,14 @@ downtime. Otherwise skip to the next section.
1. Run `sudo gdb -p ` to attach to the Unicorn process.
1. In the gdb window, type:
- ```
+ ```plaintext
call (void) rb_backtrace()
```
1. This forces the process to generate a Ruby backtrace. Check
`/var/log/gitlab/unicorn/unicorn_stderr.log` for the backtace. For example, you may see:
- ```ruby
+ ```plaintext
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `block in start'
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:33:in `loop'
from /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/metrics/sampler.rb:36:in `block (2 levels) in start'
@@ -124,13 +124,13 @@ downtime. Otherwise skip to the next section.
1. To see the current threads, run:
- ```
+ ```plaintext
thread apply all bt
```
1. Once you're done debugging with `gdb`, be sure to detach from the process and exit:
- ```
+ ```plaintext
detach
exit
```
@@ -162,7 +162,7 @@ separate Rails process to debug the issue:
1. Create a Personal Access Token for your user (Profile Settings -> Access Tokens).
1. Bring up the GitLab Rails console. For omnibus users, run:
- ```
+ ```shell
sudo gitlab-rails console
```
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 4ffce11aed07d6686b47d7a3037aa7e61ebfaaf9..38c0661da0652b9ca9eb8c01869bc2e9b99c02f4 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -202,9 +202,9 @@ and they will assist you with any issues you are having.
- How to get the manifest for a release. It can be useful because it contains the info about
all Kubernetes resources and dependent charts:
- ```shell
- helm get manifest
- ```
+ ```shell
+ helm get manifest
+ ```
## Installation of minimal GitLab config via Minukube on macOS
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index ab302c919b2062b41d3c2d6fe36e403d4dbe13ab..b793f0a2ebc32d97baac72583d0a59e8f4fb6214 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -99,13 +99,13 @@ References:
- [Customer ticket (internal) GitLab 12.1.6](https://gitlab.zendesk.com/agent/tickets/134307) and [Google doc (internal)](https://docs.google.com/document/d/19xw2d_D1ChLiU-MO1QzWab-4-QXgsIUcN5e_04WTKy4)
- [Issue #2 deadlocks can occur if an instance is flooded with pushes](https://gitlab.com/gitlab-org/gitlab/issues/33650). Provided for context about how GitLab code can have this sort of unanticipated effect in unusual situations.
-```
+```plaintext
ERROR: deadlock detected
```
Three applicable timeouts are identified in the issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528); our recommended settings are as follows:
-```
+```ini
deadlock_timeout = 5s
statement_timeout = 15s
idle_in_transaction_session_timeout = 60s
@@ -128,7 +128,7 @@ Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indica
See current settings with:
-```
+```shell
sudo gitlab-rails runner "c = ApplicationRecord.connection ; puts c.execute('SHOW statement_timeout').to_a ;
puts c.execute('SHOW lock_timeout').to_a ;
puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
diff --git a/doc/administration/troubleshooting/sidekiq.md b/doc/administration/troubleshooting/sidekiq.md
index 91361dddf02320d80089705104c219996a57787c..b72bce5b3c63ef47b1d5246b5819b2750ea9b316 100644
--- a/doc/administration/troubleshooting/sidekiq.md
+++ b/doc/administration/troubleshooting/sidekiq.md
@@ -31,7 +31,7 @@ Check in `/var/log/gitlab/sidekiq/current` or `$GITLAB_HOME/log/sidekiq.log` for
the backtrace output. The backtraces will be lengthy and generally start with
several `WARN` level messages. Here's an example of a single thread's backtrace:
-```
+```plaintext
2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: ActiveRecord::RecordNotFound: Couldn't find Note with 'id'=3375386
2016-04-13T06:21:20.022Z 31517 TID-orn4urby0 WARN: /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/activerecord-4.2.5.2/lib/active_record/core.rb:155:in `find'
/opt/gitlab/embedded/service/gitlab-rails/app/workers/new_note_worker.rb:7:in `perform'
@@ -55,7 +55,7 @@ respond to the `TTIN` signal, this is a good next step.
If `perf` is not installed on your system, install it with `apt-get` or `yum`:
-```
+```shell
# Debian
sudo apt-get install linux-tools
@@ -68,13 +68,13 @@ sudo yum install perf
Run perf against the Sidekiq PID:
-```
+```shell
sudo perf record -p
```
Let this run for 30-60 seconds and then press Ctrl-C. Then view the perf report:
-```
+```shell
sudo perf report
# Sample output
@@ -102,13 +102,13 @@ of the process (Sidekiq will not process jobs while `gdb` is attached).
Start by attaching to the Sidekiq PID:
-```
+```shell
gdb -p
```
Then gather information on all the threads:
-```
+```plaintext
info threads
# Example output
@@ -129,7 +129,7 @@ from /opt/gitlab/embedded/service/gem/ruby/2.1.0/gems/nokogiri-1.6.7.2/lib/nokog
If you see a suspicious thread, like the Nokogiri one above, you may want
to get more information:
-```
+```plaintext
thread 21
bt
@@ -147,7 +147,7 @@ bt
To output a backtrace from all threads at once:
-```
+```plaintext
set pagination off
thread apply all bt
```
@@ -155,7 +155,7 @@ thread apply all bt
Once you're done debugging with `gdb`, be sure to detach from the process and
exit:
-```
+```plaintext
detach
exit
```
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index b3d2a835dc67608ea27167d914749615642597e8..f53c4e63bcb58538754be1b4d2efafd6ca9699da 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -153,7 +153,7 @@ Note that Oracle Cloud S3 must be sure to use the following settings:
If `enable_signature_v4_streaming` is set to `true`, you may see the
following error:
-```
+```plaintext
STREAMING-AWS4-HMAC-SHA256-PAYLOAD is not supported
```
diff --git a/doc/api/admin_sidekiq_queues.md b/doc/api/admin_sidekiq_queues.md
index 73568581d7f772669da7292c57831a39cf7137b7..9d053714b5428856e816d220982f6e681004e3d5 100644
--- a/doc/api/admin_sidekiq_queues.md
+++ b/doc/api/admin_sidekiq_queues.md
@@ -17,7 +17,7 @@ The response has three fields:
This API endpoint is only available to admin users.
-```
+```plaintext
DELETE /admin/sidekiq/queues/:queue_name
```
diff --git a/doc/api/oauth2.md b/doc/api/oauth2.md
index 50452b61c9943ccfa3b82ca8fbb22d0890e53eda..e84f3509dcf1c12b35927701921c71b76d2028bd 100644
--- a/doc/api/oauth2.md
+++ b/doc/api/oauth2.md
@@ -49,7 +49,7 @@ The web application flow is:
1. Request authorization code. To do that, you should redirect the user to the
`/oauth/authorize` endpoint with the following GET parameters:
- ```
+ ```plaintext
https://gitlab.example.com/oauth/authorize?client_id=APP_ID&redirect_uri=REDIRECT_URI&response_type=code&state=YOUR_UNIQUE_STATE_HASH&scope=REQUESTED_SCOPES
```
@@ -60,7 +60,7 @@ The web application flow is:
would request `read_user` and `profile` scopes). The redirect will
include the GET `code` parameter, for example:
- ```
+ ```plaintext
http://myapp.com/oauth/redirect?code=1234567890&state=YOUR_UNIQUE_STATE_HASH
```
diff --git a/doc/api/pipeline_schedules.md b/doc/api/pipeline_schedules.md
index 9ff641fc5525371dd5598571184c9e2d56d396e5..580d7efb891c152e0e0bafd069d0daf736207378 100644
--- a/doc/api/pipeline_schedules.md
+++ b/doc/api/pipeline_schedules.md
@@ -1,6 +1,6 @@
# Pipeline schedules API
-You can read more about [pipeline schedules](../user/project/pipelines/schedules.md).
+You can read more about [pipeline schedules](../ci/pipelines/schedules.md).
## Get all pipeline schedules
diff --git a/doc/ci/README.md b/doc/ci/README.md
index 5206807cf7a0637ead82fbe4a61081d73ee4261a..3cf2efeae4535a1c6acbdd9374834be9d6589586 100644
--- a/doc/ci/README.md
+++ b/doc/ci/README.md
@@ -85,7 +85,7 @@ GitLab CI/CD supports numerous configuration options:
| [Environments](environments.md) | Deploy your application to different environments (e.g., staging, production). |
| [Job artifacts](../user/project/pipelines/job_artifacts.md) | Output, use, and reuse job artifacts. |
| [Cache dependencies](caching/index.md) | Cache your dependencies for a faster execution. |
-| [Schedule pipelines](../user/project/pipelines/schedules.md) | Schedule pipelines to run as often as you need. |
+| [Schedule pipelines](pipelines/schedules.md) | Schedule pipelines to run as often as you need. |
| [Custom path for `.gitlab-ci.yml`](../user/project/pipelines/settings.md#custom-ci-configuration-path) | Define a custom path for the CI/CD configuration file. |
| [Git submodules for CI/CD](git_submodules.md) | Configure jobs for using Git submodules.|
| [SSH keys for CI/CD](ssh_keys/README.md) | Using SSH keys in your CI pipelines. |
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 11a672fe1c6fc9b5cf60a9cd6ebb19934e9b443d..69618cbd218f8c45d8bbebff406dfe20358e546f 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -127,14 +127,14 @@ not without its own challenges:
and use it as your mount point (for a more thorough explanation, check [issue
#41227](https://gitlab.com/gitlab-org/gitlab-foss/issues/41227)):
- ```yaml
- variables:
- MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt
+ ```yaml
+ variables:
+ MOUNT_POINT: /builds/$CI_PROJECT_PATH/mnt
- script:
- - mkdir -p "$MOUNT_POINT"
- - docker run -v "$MOUNT_POINT:/mnt" my-docker-image
- ```
+ script:
+ - mkdir -p "$MOUNT_POINT"
+ - docker run -v "$MOUNT_POINT:/mnt" my-docker-image
+ ```
An example project using this approach can be found here: .
@@ -198,7 +198,7 @@ support this.
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
- ```
+ ```
1. You can now use `docker` in the build script (note the inclusion of the
`docker:19.03.1-dind` service):
diff --git a/doc/ci/introduction/index.md b/doc/ci/introduction/index.md
index a07252f48035cdb1838102e0114612d870f76664..069430579e31162521269ad54e34bce2bc59f3c6 100644
--- a/doc/ci/introduction/index.md
+++ b/doc/ci/introduction/index.md
@@ -206,7 +206,7 @@ With GitLab CI/CD you can also:
- Easily set up your app's entire lifecycle with [Auto DevOps](../../topics/autodevops/index.md).
- Deploy your app to different [environments](../environments.md).
- Install your own [GitLab Runner](https://docs.gitlab.com/runner/).
-- [Schedule pipelines](../../user/project/pipelines/schedules.md).
+- [Schedule pipelines](../pipelines/schedules.md).
- Check for app vulnerabilities with [Security Test reports](../../user/application_security/index.md). **(ULTIMATE)**
To see all CI/CD features, navigate back to the [CI/CD index](../README.md).
diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md
index db97a6b4f2ccb362b642e2dd99288817eb619584..17dc479e1b819f085b0c671af8778f1cafab6701 100644
--- a/doc/ci/jenkins/index.md
+++ b/doc/ci/jenkins/index.md
@@ -203,7 +203,7 @@ can provide any variables they like.
#### `triggers` / `cron`
Because GitLab is integrated tightly with Git, SCM polling options for triggers are not needed. We support an easy to use
-[syntax for scheduling pipelines](../../user/project/pipelines/schedules.md).
+[syntax for scheduling pipelines](../pipelines/schedules.md).
#### `tools`
diff --git a/doc/user/project/pipelines/img/pipeline_schedule_play.png b/doc/ci/pipelines/img/pipeline_schedule_play.png
similarity index 100%
rename from doc/user/project/pipelines/img/pipeline_schedule_play.png
rename to doc/ci/pipelines/img/pipeline_schedule_play.png
diff --git a/doc/user/project/pipelines/img/pipeline_schedule_variables.png b/doc/ci/pipelines/img/pipeline_schedule_variables.png
similarity index 100%
rename from doc/user/project/pipelines/img/pipeline_schedule_variables.png
rename to doc/ci/pipelines/img/pipeline_schedule_variables.png
diff --git a/doc/user/project/pipelines/img/pipeline_schedules_list.png b/doc/ci/pipelines/img/pipeline_schedules_list.png
similarity index 100%
rename from doc/user/project/pipelines/img/pipeline_schedules_list.png
rename to doc/ci/pipelines/img/pipeline_schedules_list.png
diff --git a/doc/user/project/pipelines/img/pipeline_schedules_new_form.png b/doc/ci/pipelines/img/pipeline_schedules_new_form.png
similarity index 100%
rename from doc/user/project/pipelines/img/pipeline_schedules_new_form.png
rename to doc/ci/pipelines/img/pipeline_schedules_new_form.png
diff --git a/doc/user/project/pipelines/img/pipeline_schedules_ownership.png b/doc/ci/pipelines/img/pipeline_schedules_ownership.png
similarity index 100%
rename from doc/user/project/pipelines/img/pipeline_schedules_ownership.png
rename to doc/ci/pipelines/img/pipeline_schedules_ownership.png
diff --git a/doc/ci/pipelines/schedules.md b/doc/ci/pipelines/schedules.md
new file mode 100644
index 0000000000000000000000000000000000000000..3bd42899542ba9480ea7c91bd662d07b3cdc4e15
--- /dev/null
+++ b/doc/ci/pipelines/schedules.md
@@ -0,0 +1,141 @@
+---
+type: reference, howto
+---
+
+# Pipeline schedules
+
+> - Introduced in GitLab 9.1 as [Trigger Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10533).
+> - [Renamed to Pipeline Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10853) in GitLab 9.2.
+
+NOTE: **Note:**
+Cron notation is parsed by [Fugit](https://github.com/floraison/fugit).
+
+Pipelines are normally run based on certain conditions being met. For example, when a branch is pushed to repository.
+
+Pipeline schedules can be used to also run [pipelines](../pipelines.md) at specific intervals. For example:
+
+- Every month on the 22nd for a certain branch.
+- Once every day.
+
+In addition to using the GitLab UI, pipeline schedules can be maintained using the
+[Pipeline schedules API](../../api/pipeline_schedules.md).
+
+## Configuring pipeline schedules
+
+To schedule a pipeline for project:
+
+1. Navigate to the project's **CI / CD > Schedules** page.
+1. Click the **New schedule** button.
+1. Fill in the **Schedule a new pipeline** form.
+1. Click the **Save pipeline schedule** button.
+
+
+
+NOTE: **Note:**
+Pipelines execution [timing is dependent](#advanced-configuration) on Sidekiq's own schedule.
+
+In the **Schedules** index page you can see a list of the pipelines that are
+scheduled to run. The next run is automatically calculated by the server GitLab
+is installed on.
+
+
+
+### Using variables
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12328) in GitLab 9.4.
+
+You can pass any number of arbitrary variables and they will be available in
+GitLab CI so that they can be used in your [`.gitlab-ci.yml` file](../../ci/yaml/README.md).
+
+
+
+### Using only and except
+
+To configure that a job can be executed only when the pipeline has been
+scheduled (or the opposite), you can use
+[only and except](../yaml/README.md#onlyexcept-basic) configuration keywords.
+
+For example:
+
+```yaml
+job:on-schedule:
+ only:
+ - schedules
+ script:
+ - make world
+
+job:
+ except:
+ - schedules
+ script:
+ - make build
+```
+
+### Advanced configuration
+
+The pipelines won't be executed exactly on schedule because schedules are handled by
+Sidekiq, which runs according to its interval.
+
+For example, only two pipelines will be created per day if:
+
+- You set a schedule to create a pipeline every minute (`* * * * *`).
+- The Sidekiq worker runs on 00:00 and 12:00 every day (`0 */12 * * *`).
+
+To change the Sidekiq worker's frequency:
+
+1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file.
+1. [Reconfigure GitLab](../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
+For GitLab.com, refer to the [dedicated settings page](../../user/gitlab_com/index.md#cron-jobs).
+
+## Working with scheduled pipelines
+
+Once configured, GitLab supports many functions for working with scheduled pipelines.
+
+### Running manually
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15700) in GitLab 10.4.
+
+To trigger a pipeline schedule manually, click the "Play" button:
+
+
+
+This will schedule a background job to run the pipeline schedule. A flash
+message will provide a link to the CI/CD Pipeline index page.
+
+NOTE: **Note:**
+To help avoid abuse, users are rate limited to triggering a pipeline once per
+minute.
+
+### Taking ownership
+
+Pipelines are executed as a user, who owns a schedule. This influences what projects and other resources the pipeline has access to.
+
+If a user does not own a pipeline, you can take ownership by clicking the **Take ownership** button.
+The next time a pipeline is scheduled, your credentials will be used.
+
+
+
+If the owner of a pipeline schedule doesn't have the ability to create
+pipelines on the target branch, the schedule will stop creating new
+pipelines.
+
+This can happen if, for example:
+
+- The owner is blocked or removed from the project.
+- The target branch or tag is protected.
+
+In this case, someone with sufficient privileges must take ownership of the
+schedule.
+
+
diff --git a/doc/ci/triggers/README.md b/doc/ci/triggers/README.md
index 7e187d58e211ebf5378ec4fc67e3b046cba2447e..4e597b883d05d94a67ad840e5822b680e901c02f 100644
--- a/doc/ci/triggers/README.md
+++ b/doc/ci/triggers/README.md
@@ -256,7 +256,7 @@ of all types of variables.
>**Note:**
The following behavior can also be achieved through GitLab's UI with
-[pipeline schedules](../../user/project/pipelines/schedules.md).
+[pipeline schedules](../pipelines/schedules.md).
Whether you craft a script or just run cURL directly, you can trigger jobs
in conjunction with cron. The example below triggers a job on the `master`
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index c768c833e7cd4c6a297dfc0cdd31fefa229c2be7..cbc6b9947b387ae0edf575022bc2b3e2cc87a892 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -377,7 +377,7 @@ variables, depending on where they are defined.
The order of precedence for variables is (from highest to lowest):
-1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables) or [scheduled pipeline variables](../../user/project/pipelines/schedules.md#using-variables).
+1. [Trigger variables](../triggers/README.md#making-use-of-trigger-variables) or [scheduled pipeline variables](../pipelines/schedules.md#using-variables).
1. Project-level [variables](#creating-a-custom-environment-variable) or [protected variables](#protected-environment-variables).
1. Group-level [variables](#group-level-environment-variables) or [protected variables](#protected-environment-variables).
1. YAML-defined [job-level variables](../yaml/README.md#variables).
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index edb311e8e8061588cd1cec908774787ab359c513..00b5d5d0d6de0c6681593e2bafc0edc102628091 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -4055,6 +4055,6 @@ but commented out to help encourage others to add to it in the future. -->
[ce-12909]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12909
[ce-19232]: https://gitlab.com/gitlab-org/gitlab-foss/issues/19232
[environment]: ../environments.md "CI/CD environments"
-[schedules]: ../../user/project/pipelines/schedules.md "Pipelines schedules"
+[schedules]: ../pipelines/schedules.md "Pipelines schedules"
[variables]: ../variables/README.md "CI/CD variables"
[push-option]: https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 6d9d375166bfc750f5738c0a574f9ca0f01ca92b..c0eb9c83e92a63a56703b528a50666fa74e0f0e7 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -123,7 +123,7 @@ pagination models.
To expose a collection of resources we can use a connection type. This wraps the array with default pagination fields. For example a query for project-pipelines could look like this:
-```
+```graphql
query($project_path: ID!) {
project(fullPath: $project_path) {
pipelines(first: 2) {
@@ -181,7 +181,7 @@ look like this:
To get the next page, the cursor of the last known element could be
passed:
-```
+```graphql
query($project_path: ID!) {
project(fullPath: $project_path) {
pipelines(first: 2, after: "Njc=") {
@@ -319,7 +319,6 @@ module Types
value 'CLOSED', value: 'closed', description: 'An closed Epic'
end
end
-
```
## Descriptions
diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md
index dd07a9cbfb789071830c62d0a6c1e5a255fc8f83..f89b238cd792e099c598bdb926045309a07fba60 100644
--- a/doc/development/application_limits.md
+++ b/doc/development/application_limits.md
@@ -22,22 +22,22 @@ limit values. It's recommended to create separate migration script files.
1. Add new column to the `plan_limits` table with non-null default value 0, eg:
- ```ruby
- add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false)
- ```
+ ```ruby
+ add_column(:plan_limits, :project_hooks, :integer, default: 0, null: false)
+ ```
- NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
- enabled.
+ NOTE: **Note:** Plan limits entries set to `0` mean that limits are not
+ enabled.
1. Insert plan limits values into the database using
`create_or_update_plan_limit` migration helper, eg:
- ```ruby
- create_or_update_plan_limit('project_hooks', 'free', 10)
- create_or_update_plan_limit('project_hooks', 'bronze', 20)
- create_or_update_plan_limit('project_hooks', 'silver', 30)
- create_or_update_plan_limit('project_hooks', 'gold', 100)
- ```
+ ```ruby
+ create_or_update_plan_limit('project_hooks', 'free', 10)
+ create_or_update_plan_limit('project_hooks', 'bronze', 20)
+ create_or_update_plan_limit('project_hooks', 'silver', 30)
+ create_or_update_plan_limit('project_hooks', 'gold', 100)
+ ```
### Plan limits validation
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 5a1b53bc2fb4118e51258b5cd56283587c47895e..c75de8e897075711c5c1e33c8c5d3b9ef2aec4e4 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -542,28 +542,28 @@ See the README for more information.
The GitLab init script starts and stops Unicorn and Sidekiq:
-```
+```plaintext
/etc/init.d/gitlab
Usage: service gitlab {start|stop|restart|reload|status}
```
Redis (key-value store/non-persistent database):
-```
+```plaintext
/etc/init.d/redis
Usage: /etc/init.d/redis {start|stop|status|restart|condrestart|try-restart}
```
SSH daemon:
-```
+```plaintext
/etc/init.d/sshd
Usage: /etc/init.d/sshd {start|stop|restart|reload|force-reload|condrestart|try-restart|status}
```
Web server (one of the following):
-```
+```plaintext
/etc/init.d/httpd
Usage: httpd {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}
@@ -573,7 +573,7 @@ Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}
Persistent database:
-```
+```plaintext
$ /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|restart|reload|force-reload|status} [version ..]
```
@@ -626,7 +626,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
In a nutshell, do the following:
-```
+```shell
sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
diff --git a/doc/development/chaos_endpoints.md b/doc/development/chaos_endpoints.md
index 2e55f19cd9102eea428d3879f00e96d9c844a695..26ff3d2def7b355741513b21b0bd353dfd753e7f 100644
--- a/doc/development/chaos_endpoints.md
+++ b/doc/development/chaos_endpoints.md
@@ -47,7 +47,7 @@ To simulate a memory leak in your application, use the `/-/chaos/leakmem` endpoi
NOTE: **Note:**
The memory is not retained after the request finishes. Once the request has completed, the Ruby garbage collector will attempt to recover the memory.
-```
+```plaintext
GET /-/chaos/leakmem
GET /-/chaos/leakmem?memory_mb=1024
GET /-/chaos/leakmem?memory_mb=1024&duration_s=50
@@ -72,7 +72,7 @@ This endpoint attempts to fully utilise a single core, at 100%, for the given pe
Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
If you're using Unicorn, this is done by killing the worker process.
-```
+```plaintext
GET /-/chaos/cpu_spin
GET /-/chaos/cpu_spin?duration_s=50
GET /-/chaos/cpu_spin?duration_s=50&async=true
@@ -96,7 +96,7 @@ This endpoint can be used to model yielding execution to another threads when ru
Depending on your rack server setup, your request may timeout after a predetermined period (normally 60 seconds).
If you're using Unicorn, this is done by killing the worker process.
-```
+```plaintext
GET /-/chaos/db_spin
GET /-/chaos/db_spin?duration_s=50
GET /-/chaos/db_spin?duration_s=50&async=true
@@ -119,7 +119,7 @@ This endpoint is similar to the CPU Spin endpoint but simulates off-processor ac
As with the CPU Spin endpoint, this may lead to your request timing out if duration_s exceeds the configured limit.
-```
+```plaintext
GET /-/chaos/sleep
GET /-/chaos/sleep?duration_s=50
GET /-/chaos/sleep?duration_s=50&async=true
@@ -142,7 +142,7 @@ This endpoint will simulate the unexpected death of a worker process using a `ki
NOTE: **Note:**
Since this endpoint uses the `KILL` signal, the worker is not given a chance to cleanup or shutdown.
-```
+```plaintext
GET /-/chaos/kill
GET /-/chaos/kill?async=true
```
diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md
index d91edba92db97989a333cd7fa4665641309e95e8..e577ba6ec8fca8d163fb5d0b05b495dcdeb0e857 100644
--- a/doc/development/database_debugging.md
+++ b/doc/development/database_debugging.md
@@ -39,7 +39,7 @@ If your test DB is giving you problems, it is safe to nuke it because it doesn't
Access the database via one of these commands (they all get you to the same place)
-```
+```ruby
gdk psql -d gitlabhq_development
bundle exec rails dbconsole RAILS_ENV=development
bundle exec rails db RAILS_ENV=development
diff --git a/doc/development/db_dump.md b/doc/development/db_dump.md
index 97762a62a806b75eb8309b3b85565d05aff6214e..bb740d12f7b50d7047572eaff71092eb0280cf00 100644
--- a/doc/development/db_dump.md
+++ b/doc/development/db_dump.md
@@ -10,7 +10,7 @@ data leaks.
On the staging VM, add the following line to `/etc/gitlab/gitlab.rb` to speed up
large database imports.
-```
+```shell
# On STAGING
echo "postgresql['checkpoint_segments'] = 64" | sudo tee -a /etc/gitlab/gitlab.rb
sudo touch /etc/gitlab/skip-auto-reconfigure
@@ -23,7 +23,7 @@ Next, we let the production environment stream a compressed SQL dump to our
local machine via SSH, and redirect this stream to a psql client on the staging
VM.
-```
+```shell
# On LOCAL MACHINE
ssh -C gitlab.example.com sudo -u gitlab-psql /opt/gitlab/embedded/bin/pg_dump -Cc gitlabhq_production |\
ssh -C staging-vm sudo -u gitlab-psql /opt/gitlab/embedded/bin/psql -d template1
@@ -37,14 +37,14 @@ use this procedure.
First, on the production server, create a list of directories you want to
re-create.
-```
+```shell
# On PRODUCTION
(umask 077; sudo find /var/opt/gitlab/git-data/repositories -maxdepth 1 -type d -print0 > directories.txt)
```
Copy `directories.txt` to the staging server and create the directories there.
-```
+```shell
# On STAGING
sudo -u git xargs -0 mkdir -p < directories.txt
```
diff --git a/doc/development/documentation/site_architecture/release_process.md b/doc/development/documentation/site_architecture/release_process.md
index 61df572a6d2606530f9a0d4add3b417debe329ca..59a8d3cff015c42596cb5984310f7ff159b648bf 100644
--- a/doc/development/documentation/site_architecture/release_process.md
+++ b/doc/development/documentation/site_architecture/release_process.md
@@ -70,9 +70,9 @@ this needs to happen when the stable branches for all products have been created
1. Run the raketask to create the single version:
- ```shell
- ./bin/rake "release:single[12.0]"
- ```
+ ```shell
+ ./bin/rake "release:single[12.0]"
+ ```
A new `Dockerfile.12.0` should have been created and committed to a new branch.
diff --git a/doc/development/import_project.md b/doc/development/import_project.md
index e92d18b7ace820723c3f6a06419fc53e61c23567..3cdf2b8977a1cff04cc0e4992da74f27f5021f49 100644
--- a/doc/development/import_project.md
+++ b/doc/development/import_project.md
@@ -115,13 +115,13 @@ The last option is to import a project using a Rails console:
project: project).restore
```
- We are storing all import failures in the `import_failures` data table.
+ We are storing all import failures in the `import_failures` data table.
- To make sure that the project import finished without any issues, check:
+ To make sure that the project import finished without any issues, check:
- ```ruby
- project.import_failures.all
- ```
+ ```ruby
+ project.import_failures.all
+ ```
## Performance testing
diff --git a/doc/integration/vault.md b/doc/integration/vault.md
index b3e77ce440d4ed4a100167885f0c28d23ab2eb7d..3ba401d8b35f3eb50ef8b570f6d0477c70d4381a 100644
--- a/doc/integration/vault.md
+++ b/doc/integration/vault.md
@@ -15,106 +15,109 @@ The following assumes you already have Vault installed and running.
1. **Get the OpenID Connect client ID and secret from GitLab:**
- First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
+ First you'll need to create a GitLab application to obtain an application ID and secret for authenticating into Vault. To do this, sign in to GitLab and follow these steps:
- 1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
- 1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris),
- making sure to select the **OpenID** scope.
- 1. Save application.
- 1. Copy client ID and secret, or keep the page open for reference.
- 
+ 1. On GitLab, click your avatar on the top-right corner, and select your user **Settings > Applications**.
+ 1. Fill out the application **Name** and [**Redirect URI**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris),
+ making sure to select the **OpenID** scope.
+ 1. Save application.
+ 1. Copy client ID and secret, or keep the page open for reference.
+
+ 
1. **Enable OIDC auth on Vault:**
- OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal.
+ OpenID Connect is not enabled in Vault by default. This needs to be enabled in the terminal.
- Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
+ Open a terminal session and run the following command to enable the OpenID Connect authentication provider in Vault:
- ```shell
- vault auth enable oidc
- ```
+ ```shell
+ vault auth enable oidc
+ ```
- You should see the following output in the terminal:
+ You should see the following output in the terminal:
- ```plaintext
- Success! Enabled oidc auth method at: oidc/
- ```
+ ```plaintext
+ Success! Enabled oidc auth method at: oidc/
+ ```
1. **Write the OIDC config:**
- Next, Vault needs to be given the application ID and secret generated by GitLab.
+ Next, Vault needs to be given the application ID and secret generated by GitLab.
- In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
+ In the terminal session, run the following command to give Vault access to the GitLab application you've just created with an OpenID scope. This allows Vault to authenticate through GitLab.
- Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
+ Replace `your_application_id` and `your_secret` in the example below with the application ID and secret generated for your app:
- ```shell
- $ vault write auth/oidc/config \
- oidc_discovery_url="https://gitlab.com" \
- oidc_client_id="your_application_id" \
- oidc_client_secret="your_secret" \
- default_role="demo" \
- bound_issuer="localhost"
- ```
+ ```shell
+ $ vault write auth/oidc/config \
+ oidc_discovery_url="https://gitlab.com" \
+ oidc_client_id="your_application_id" \
+ oidc_client_secret="your_secret" \
+ default_role="demo" \
+ bound_issuer="localhost"
+ ```
- You should see the following output in the terminal:
+ You should see the following output in the terminal:
- ```shell
- Success! Data written to: auth/oidc/config
- ```
+ ```shell
+ Success! Data written to: auth/oidc/config
+ ```
1. **Write the OIDC Role Config:**
- Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
+ Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
- This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
+ This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.
- ```shell
- vault write auth/oidc/role/demo \
- user_claim="sub" \
- allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \
- bound_audiences="your_application_id" \
- role_type="oidc" \
- oidc_scopes="openid" \
- policies=demo \
- ttl=1h
- ```
+ ```shell
+ vault write auth/oidc/role/demo \
+ user_claim="sub" \
+ allowed_redirect_uris="http://localhost:8250/oidc/callback,http://127.0.0.1:8200/ui/vault/auth/oidc/oidc/callback" \
+ bound_audiences="your_application_id" \
+ role_type="oidc" \
+ oidc_scopes="openid" \
+ policies=demo \
+ ttl=1h
+ ```
1. **Sign in to Vault:**
- 1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
- 1. If the `OIDC` method is not currently selected, open the dropdown and select it.
- 1. Click the **Sign in With GitLab** button, which will open a modal window:
- 
+ 1. Go to your Vault UI (example: [http://127.0.0.1:8200/ui/vault/auth?with=oidc](http://127.0.0.1:8200/ui/vault/auth?with=oidc)).
+ 1. If the `OIDC` method is not currently selected, open the dropdown and select it.
+ 1. Click the **Sign in With GitLab** button, which will open a modal window:
+
+ 
+
+ 1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
- 1. Click **Authorize** on the modal to allow Vault to sign in through GitLab. This will redirect you back to your Vault UI as a signed-in user.
- 
+ 
1. **Sign in using the Vault CLI** (optional):
- Vault also allows you to sign in via their CLI.
+ Vault also allows you to sign in via their CLI.
- After writing the same configurations from above, you can run the command below in your terminal to sign in with the role configuration created in step 4 above:
+ After writing the same configurations from above, you can run the command below in your terminal to sign in with the role configuration created in step 4 above:
- ```shell
- vault login -method=oidc port=8250 role=demo
- ```
+ ```shell
+ vault login -method=oidc port=8250 role=demo
+ ```
- Here is a short explaination of what this command does:
+ Here is a short explaination of what this command does:
- 1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
- 1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
- 1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris).
+ 1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
+ 1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
+ 1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris).
- Once you run the command above, it will present a link in the terminal.
- Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
+ Once you run the command above, it will present a link in the terminal.
+ Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
- 
+ 
- The terminal will output:
+ The terminal will output:
- ```plaintext
- Success! You are now authenticated. The token information displayed below
- is already stored in the token helper. You do NOT need to run "vault login"
- again. Future Vault requests will automatically use this token.
- ```
+ ```plaintext
+ Success! You are now authenticated. The token information displayed below
+ is already stored in the token helper. You do NOT need to run "vault login"
+ again. Future Vault requests will automatically use this token.
+ ```
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index aa7aba97c08d29aa329500baa845ee3c851d2b1c..e14e8ceb8c0fe3269dd42c1502a5b3c94fead9b4 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -239,7 +239,7 @@ Container Scanning can be executed on an offline air-gapped GitLab Ultimate inst
self-signed certificate, then you must set `DOCKER_INSECURE: true` in the above
`container_scanning` section of your `.gitlab-ci.yml`.
-It may be worthwhile to set up a [scheduled pipeline](../../project/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule. You can use the following `.gitlab-yml.ci` as a template:
+It may be worthwhile to set up a [scheduled pipeline](../../../ci/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule. You can use the following `.gitlab-yml.ci` as a template:
```yaml
image: docker:stable
@@ -270,9 +270,9 @@ image directly, follow these steps:
1. Run [Docker Desktop](https://www.docker.com/products/docker-desktop) or [Docker Machine](https://github.com/docker/machine).
1. Run the latest [prefilled vulnerabilities database](https://cloud.docker.com/repository/docker/arminc/clair-db) Docker image:
- ```shell
- docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
- ```
+ ```shell
+ docker run -p 5432:5432 -d --name clair-db arminc/clair-db:latest
+ ```
1. Configure an environment variable to point to your local machine's IP address (or insert your IP address instead of the `LOCAL_MACHINE_IP_ADDRESS` variable in the `CLAIR_DB_CONNECTION_STRING` in the next step):
@@ -282,16 +282,16 @@ image directly, follow these steps:
1. Run the analyzer's Docker image, passing the image and tag you want to analyze in the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` environment variables:
- ```shell
- docker run \
- --interactive --rm \
- --volume "$PWD":/tmp/app \
- -e CI_PROJECT_DIR=/tmp/app \
- -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
- -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
- -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
- registry.gitlab.com/gitlab-org/security-products/analyzers/klar
- ```
+ ```shell
+ docker run \
+ --interactive --rm \
+ --volume "$PWD":/tmp/app \
+ -e CI_PROJECT_DIR=/tmp/app \
+ -e CLAIR_DB_CONNECTION_STRING="postgresql://postgres:password@${LOCAL_MACHINE_IP_ADDRESS}:5432/postgres?sslmode=disable&statement_timeout=60000" \
+ -e CI_APPLICATION_REPOSITORY=registry.gitlab.com/gitlab-org/security-products/dast/webgoat-8.0@sha256 \
+ -e CI_APPLICATION_TAG=bc09fe2e0721dfaeee79364115aeedf2174cce0947b9ae5fe7c33312ee019a4e \
+ registry.gitlab.com/gitlab-org/security-products/analyzers/klar
+ ```
The results are stored in `gl-container-scanning-report.json`.
diff --git a/doc/user/application_security/security_dashboard/index.md b/doc/user/application_security/security_dashboard/index.md
index 4b8c7aaac15efd886b38d78c8d925fc1121d7b84..4ce6a9403c5063815df2e46142d2789fc3c673a6 100644
--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@@ -147,7 +147,7 @@ information on the Security Dashboard can become outdated as new vulnerabilities
are discovered.
To ensure the information on the Security Dashboard is regularly updated,
-[configure a scheduled pipeline](../../project/pipelines/schedules.md) to run a
+[configure a scheduled pipeline](../../../ci/pipelines/schedules.md) to run a
daily security scan. This will update the information displayed on the Security
Dashboard regardless of how often the default branch is updated.
diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md
index b13cb36f9d0a5140bcd7809c5581687b6a6454e5..3fa909357e6fa7c32dca683673bdeb62c7d54db1 100644
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@@ -501,20 +501,20 @@ To install applications using GitLab CI:
1. Connect the cluster to a [cluster management project](management_project.md).
1. In that project, add a `.gitlab-ci.yml` file with the following content:
- ```yaml
- include:
- - template: Managed-Cluster-Applications.gitlab-ci.yml
- ```
+ ```yaml
+ include:
+ - template: Managed-Cluster-Applications.gitlab-ci.yml
+ ```
1. Add a `.gitlab/managed-apps/config.yaml` file to define which
applications you would like to install. Define the `installed` key as
`true` to install the application and `false` to uninstall the
application. For example, to install Ingress:
- ```yaml
- ingress:
- installed: true
- ```
+ ```yaml
+ ingress:
+ installed: true
+ ```
1. Optionally, define `.gitlab/managed-apps//values.yaml` file to
customize values for the installed application.
diff --git a/doc/user/project/pipelines/schedules.md b/doc/user/project/pipelines/schedules.md
index 360897b530d01afc3724e0b0830b947a415ce591..a92464d681707b3705a23c11f399ff926f883281 100644
--- a/doc/user/project/pipelines/schedules.md
+++ b/doc/user/project/pipelines/schedules.md
@@ -1,141 +1,5 @@
---
-type: reference, howto
+redirect_to: '../../../ci/pipelines/schedules.md'
---
-# Pipeline schedules
-
-> - Introduced in GitLab 9.1 as [Trigger Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10533).
-> - [Renamed to Pipeline Schedule](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/10853) in GitLab 9.2.
-
-NOTE: **Note:**
-Cron notation is parsed by [Fugit](https://github.com/floraison/fugit).
-
-Pipelines are normally run based on certain conditions being met. For example, when a branch is pushed to repository.
-
-Pipeline schedules can be used to also run [pipelines](../../../ci/pipelines.md) at specific intervals. For example:
-
-- Every month on the 22nd for a certain branch.
-- Once every day.
-
-In addition to using the GitLab UI, pipeline schedules can be maintained using the
-[Pipeline schedules API](../../../api/pipeline_schedules.md).
-
-## Configuring pipeline schedules
-
-To schedule a pipeline for project:
-
-1. Navigate to the project's **CI / CD > Schedules** page.
-1. Click the **New schedule** button.
-1. Fill in the **Schedule a new pipeline** form.
-1. Click the **Save pipeline schedule** button.
-
-
-
-NOTE: **Note:**
-Pipelines execution [timing is dependent](#advanced-configuration) on Sidekiq's own schedule.
-
-In the **Schedules** index page you can see a list of the pipelines that are
-scheduled to run. The next run is automatically calculated by the server GitLab
-is installed on.
-
-
-
-### Using variables
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/12328) in GitLab 9.4.
-
-You can pass any number of arbitrary variables and they will be available in
-GitLab CI so that they can be used in your [`.gitlab-ci.yml` file](../../../ci/yaml/README.md).
-
-
-
-### Using only and except
-
-To configure that a job can be executed only when the pipeline has been
-scheduled (or the opposite), you can use
-[only and except](../../../ci/yaml/README.md#onlyexcept-basic) configuration keywords.
-
-For example:
-
-```yaml
-job:on-schedule:
- only:
- - schedules
- script:
- - make world
-
-job:
- except:
- - schedules
- script:
- - make build
-```
-
-### Advanced configuration
-
-The pipelines won't be executed exactly on schedule because schedules are handled by
-Sidekiq, which runs according to its interval.
-
-For example, only two pipelines will be created per day if:
-
-- You set a schedule to create a pipeline every minute (`* * * * *`).
-- The Sidekiq worker runs on 00:00 and 12:00 every day (`0 */12 * * *`).
-
-To change the Sidekiq worker's frequency:
-
-1. Edit the `gitlab_rails['pipeline_schedule_worker_cron']` value in your instance's `gitlab.rb` file.
-1. [Reconfigure GitLab](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
-
-For GitLab.com, refer to the [dedicated settings page](../../gitlab_com/index.md#cron-jobs).
-
-## Working with scheduled pipelines
-
-Once configured, GitLab supports many functions for working with scheduled pipelines.
-
-### Running manually
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15700) in GitLab 10.4.
-
-To trigger a pipeline schedule manually, click the "Play" button:
-
-
-
-This will schedule a background job to run the pipeline schedule. A flash
-message will provide a link to the CI/CD Pipeline index page.
-
-NOTE: **Note:**
-To help avoid abuse, users are rate limited to triggering a pipeline once per
-minute.
-
-### Taking ownership
-
-Pipelines are executed as a user, who owns a schedule. This influences what projects and other resources the pipeline has access to.
-
-If a user does not own a pipeline, you can take ownership by clicking the **Take ownership** button.
-The next time a pipeline is scheduled, your credentials will be used.
-
-
-
-If the owner of a pipeline schedule doesn't have the ability to create
-pipelines on the target branch, the schedule will stop creating new
-pipelines.
-
-This can happen if, for example:
-
-- The owner is blocked or removed from the project.
-- The target branch or tag is protected.
-
-In this case, someone with sufficient privileges must take ownership of the
-schedule.
-
-
+This document was moved to [another location](../../../ci/pipelines/schedules.md).