Commit a67bb1f0 authored by Sean Packham (GitLab)'s avatar Sean Packham (GitLab)

Merge branch 'docs/refactor-pipeline-schedules' into 'master'

Refactor pipeline schedules docs

See merge request !11470
parents d08f6bdc ae96126e
...@@ -66,7 +66,8 @@ learn how to leverage its potential even more. ...@@ -66,7 +66,8 @@ learn how to leverage its potential even more.
submodules are involved submodules are involved
- [Auto deploy](autodeploy/index.md) - [Auto deploy](autodeploy/index.md)
- [Use SSH keys in your build environment](ssh_keys/README.md) - [Use SSH keys in your build environment](ssh_keys/README.md)
- [Trigger jobs through the GitLab API](triggers/README.md) - [Trigger pipelines through the GitLab API](triggers/README.md)
- [Trigger pipelines on a schedule](../user/project/pipelines/schedules.md)
## Review Apps ## Review Apps
......
# Triggering jobs through the API # Triggering pipelines through the API
> **Note**: > **Notes**:
- [Introduced][ci-229] in GitLab CE 7.14. - [Introduced][ci-229] in GitLab CE 7.14.
- GitLab 8.12 has a completely redesigned job permissions system. Read all - GitLab 8.12 has a completely redesigned job permissions system. Read all
about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers). about the [new model and its implications](../../user/project/new_ci_build_permissions_model.md#job-triggers).
...@@ -208,7 +208,7 @@ curl --request POST \ ...@@ -208,7 +208,7 @@ curl --request POST \
https://gitlab.example.com/api/v4/projects/9/trigger/pipeline https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
``` ```
### Using webhook to trigger job ### Using a webhook to trigger a pipeline
You can add the following webhook to another project in order to trigger a job: You can add the following webhook to another project in order to trigger a job:
...@@ -216,4 +216,18 @@ You can add the following webhook to another project in order to trigger a job: ...@@ -216,4 +216,18 @@ You can add the following webhook to another project in order to trigger a job:
https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN&variables[UPLOAD_TO_S3]=true https://gitlab.example.com/api/v4/projects/9/ref/master/trigger/pipeline?token=TOKEN&variables[UPLOAD_TO_S3]=true
``` ```
### Using cron to trigger nightly pipelines
>**Note:**
The following behavior can also be achieved through GitLab's UI with
[pipeline schedules](../../user/project/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`
branch of project with ID `9` every night at `00:30`:
```bash
30 0 * * * curl --request POST --form token=TOKEN --form ref=master https://gitlab.example.com/api/v4/projects/9/trigger/pipeline
```
[ci-229]: https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229 [ci-229]: https://gitlab.com/gitlab-org/gitlab-ci/merge_requests/229
# Pipeline Schedules # Pipeline Schedules
> **Note**: > **Notes**:
- This feature was introduced in 9.1 as [Trigger Schedule][ce-105533] - This feature was introduced in 9.1 as [Trigger Schedule][ce-10533].
- In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853] - In 9.2, the feature was [renamed to Pipeline Schedule][ce-10853].
- Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler).
Pipeline schedules can be used to run pipelines only once, or for example every Pipeline schedules can be used to run pipelines only once, or for example every
month on the 22nd for a certain branch. month on the 22nd for a certain branch.
## Using Pipeline Schedules ## Using Pipeline schedules
In order to schedule a pipeline:
In order to schedule pipelines, navigate to your their pages **Pipelines ➔ Schedules** 1. Navigate to your project's **Pipelines ➔ Schedules** and click the
and click the **New Schedule** button. **New Schedule** button.
1. Fill in the form
1. Hit **Save pipeline schedule** for the changes to take effect.
![New Schedule Form](img/pipeline_schedules_new_form.png) ![New Schedule Form](img/pipeline_schedules_new_form.png)
After entering the form, hit **Save Schedule** for the changes to have effect. >**Attention:**
You can check a next execution date of the scheduled trigger, which is automatically calculated by a server. The pipelines won't be executed precisely, because schedules are handled by
Sidekiq, which runs according to its interval.
See [advanced admin configuration](#advanced-admin-configuration) for more
information.
## Taking ownership 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) ![Schedules list](img/pipeline_schedules_list.png)
Pipelines are executed as a user, which owns a schedule. This influences what ## 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 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. a pipeline, you can take ownership by clicking the **Take ownership** button.
The next time a pipeline is scheduled, your credentials will be used. The next time a pipeline is scheduled, your credentials will be used.
> **Notes**: ![Schedules list](img/pipeline_schedules_ownership.png)
- Those pipelines won't be executed precicely. Because schedules are handled by
Sidekiq, which runs according to its interval. For exmaple, if you set a schedule to >**Note:**
create a pipeline every minute (`* * * * *`) and the Sidekiq worker performs 00:00 When the owner of the schedule doesn't have the ability to create pipelines
and 12:00 o'clock every day (`0 */12 * * *`), only 2 pipelines will be created per day. anymore, due to e.g., being blocked or removed from the project, the schedule
To change the Sidekiq worker's frequency, you have to edit the `trigger_schedule_worker_cron` is deactivated. Another user can take ownership and activate it, so the
value in your `gitlab.rb` and restart GitLab. The Sidekiq worker's configuration schedule can be run again.
on GiLab.com is able to be looked up at [here](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/gitlab.yml.example#L185).
- Cron notation is parsed by [Rufus-Scheduler](https://github.com/jmettraux/rufus-scheduler). ## Advanced admin configuration
- When the owner of the schedule does not have the ability to create pipelines
anymore, due to e.g. being blocked or removed from the project, the schedule is The pipelines won't be executed precisely, because schedules are handled by
deactivated. Another user can take ownership and activate it, so the schedule is Sidekiq, which runs according to its interval. For example, if you set a
run again. schedule to create a pipeline every minute (`* * * * *`) and the Sidekiq worker
runs on 00:00 and 12:00 every day (`0 */12 * * *`), only 2 pipelines will be
created per day. To change the Sidekiq worker's frequency, you have to edit the
`trigger_schedule_worker_cron` value in your `gitlab.rb` and restart GitLab.
For GitLab.com, you can check the [dedicated settings page][settings]. If you
don't have admin access to the server, ask your administrator.
[ce-10533]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10533 [ce-10533]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10533
[ce-10853]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10853 [ce-10853]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10853
[settings]: https://about.gitlab.com/gitlab-com/settings/#cron-jobs
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment