Add latest changes from gitlab-org/gitlab@master
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Add dedicated Release page for viewing a single Release
|
||||
merge_request: 26502
|
||||
author:
|
||||
type: added
|
|
@ -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">
|
||||
|
|
|
@ -54,7 +54,7 @@ Authenticate to GitLab using the Atlassian Crowd OmniAuth provider.
|
|||
|
||||
**Source:**
|
||||
|
||||
```
|
||||
```yaml
|
||||
- { name: 'crowd',
|
||||
args: {
|
||||
crowd_server_url: 'CROWD_SERVER_URL',
|
||||
|
|
|
@ -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".
|
||||
```
|
||||
|
||||
|
|
|
@ -495,7 +495,7 @@ work:
|
|||
|
||||
1. On the **secondary** nodes, change `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
```
|
||||
```ruby
|
||||
geo_postgresql['fdw_external_user'] = 'gitlab_geo_fdw'
|
||||
```
|
||||
|
||||
|
|
|
@ -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.
|
||||
```
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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 .
|
||||
|
|
|
@ -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"}
|
||||
```
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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.
|
||||
```
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
@ -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 ;"
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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. |
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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`
|
||||
|
||||
|
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 6.2 KiB After Width: | Height: | Size: 6.2 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 4.9 KiB After Width: | Height: | Size: 4.9 KiB |
|
@ -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.
|
||||
|
||||
![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. -->
|
|
@ -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`
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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):
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
![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).
|
||||
|
|