Add latest changes from gitlab-org/gitlab@master

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

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

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

changelogs/unreleased/nfriend-enable-release-show-page-feature-flag.yml

+---
+title: Add dedicated Release page for viewing a single Release
+merge_request: 26502
+author:
+type: added

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.                                                                                                      |
 
 <div align="right">
   <a type="button" class="btn btn-default" href="#overview">

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',

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".
 ```
 

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'
    ```
 

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,7 +157,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Rails did not provide a password when connecting to the database
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... Exception: fe_sendauth: no password supplied
@@ -170,7 +170,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Rails is unable to connect to the database
 
-    ```text
+   ```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
@@ -186,7 +186,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Rails has supplied the incorrect password
 
-    ```text
+   ```plaintext
    Checking Geo ...
    GitLab Geo is available ... Exception: FATAL:  password authentication failed for user "gitlab"
    FATAL:  password authentication failed for user "gitlab"
@@ -200,7 +200,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Check returns not a secondary node
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... yes
@@ -217,7 +217,7 @@ sudo gitlab-rake gitlab:geo:check
 
 1. Check returns Exception: PG::UndefinedTable: ERROR:  relation "geo_nodes" does not exist
 
-    ```text
+   ```plaintext
    Checking Geo ...
 
    GitLab Geo is available ... no
@@ -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.
 ```
 

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

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 <files>
    git add .

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"}
 ```

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

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.
       ```
 

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:

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 <PID>` 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
    ```
 

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 ;"

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 <sidekiq_pid>
 ```
 
 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 <sidekiq_pid>
 ```
 
 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
 ```

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

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

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

doc/api/pipeline_schedules.md

 # 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
 

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

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).

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`
 

doc/ci/pipelines/schedules.md

+---
+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.
+
+![New Schedule Form](img/pipeline_schedules_new_form.png)
+
+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.
+
+![Schedules list](img/pipeline_schedules_list.png)
+
+### 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).
+
+![Scheduled pipeline variables](img/pipeline_schedule_variables.png)
+
+### 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:
+
+![Play Pipeline Schedule](img/pipeline_schedule_play.png)
+
+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.
+
+![Schedules list](img/pipeline_schedules_ownership.png)
+
+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.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, e.g. `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->

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`

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).

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

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

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

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

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

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

doc/integration/vault.md

@@ -22,6 +22,7 @@ The following assumes you already have Vault installed and running.
       making sure to select the **OpenID** scope.
    1. Save application.
    1. Copy client ID and secret, or keep the page open for reference.
+
    ![GitLab OAuth provider](img/gitlab_oauth_vault_v12_6.png)
 
 1. **Enable OIDC auth on Vault:**
@@ -85,9 +86,11 @@ The following assumes you already have Vault installed and running.
    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:
+
    ![Sign into Vault with GitLab](img/sign_into_vault_with_gitlab_v12_6.png)
 
    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.
+
    ![Authorize Vault to connect with GitLab](img/authorize_vault_with_gitlab_v12_6.png)
 
 1. **Sign in using the Vault CLI** (optional):

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

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.
 

doc/user/project/pipelines/schedules.md

 ---
-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.
-
-![New Schedule Form](img/pipeline_schedules_new_form.png)
-
-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.
-
-![Schedules list](img/pipeline_schedules_list.png)
-
-### 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).
-
-![Scheduled pipeline variables](img/pipeline_schedule_variables.png)
-
-### 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:
-
-![Play Pipeline Schedule](img/pipeline_schedule_play.png)
-
-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.
-
-![Schedules list](img/pipeline_schedules_ownership.png)
-
-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.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, e.g. `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+This document was moved to [another location](../../../ci/pipelines/schedules.md).