Commit cd42e9ad authored by Winnie Hellmann's avatar Winnie Hellmann Committed by Evan Read

Documentation for delayed jobs

parent f810ff63
...@@ -193,6 +193,18 @@ stage has a job with a manual action. ...@@ -193,6 +193,18 @@ stage has a job with a manual action.
![Pipelines example](img/pipelines.png) ![Pipelines example](img/pipelines.png)
### Delay a particular job in the pipeline graph
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.
When you do not want to run a job immediately, you can [delay the job to run after a certain period](yaml/README.md#delayed).
This is especially useful for timed incremental rollout that new code is rolled out gradually.
For example, if you start rolling out new code and users do not experience trouble, GitLab automatically completes the deployment from 0% to 100%.
Alternatively, if you start rolling out and you noticed that a few users experience trouble with the version,
you can stop the timed incremental rollout by canceling the pipeline, and [rolling](environments.md#rolling-back-changes) it back to the stable version.
![Pipelines example](img/pipeline_incremental_rollout.png)
### Ordering of jobs in pipeline graphs ### Ordering of jobs in pipeline graphs
**Regular pipeline graph** **Regular pipeline graph**
...@@ -211,6 +223,7 @@ by name. The order of severity is: ...@@ -211,6 +223,7 @@ by name. The order of severity is:
- pending - pending
- running - running
- manual - manual
- scheduled
- canceled - canceled
- success - success
- skipped - skipped
......
...@@ -673,6 +673,42 @@ user wants to trigger an action. In other words, in order to trigger a manual ...@@ -673,6 +673,42 @@ user wants to trigger an action. In other words, in order to trigger a manual
action assigned to a branch that the pipeline is running for, user needs to action assigned to a branch that the pipeline is running for, user needs to
have ability to merge to this branch. have ability to merge to this branch.
### `when:delayed`
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21767) in GitLab 11.4.
Delayed job are for executing scripts after a certain period.
This is useful if you want to avoid jobs entering `pending` state immediately.
You can set the period with `start_in` key. The value of `start_in` key is an elapsed time in seconds, unless a unit is
provided. `start_key` must be less than or equal to one hour. Examples of valid values include:
- `10 seconds`
- `30 minutes`
- `1 hour`
When there is a delayed job in a stage, the pipeline will not progress until the delayed job has finished.
This means this keyword can also be used for inserting delays between different stages.
The timer of a delayed job starts immediately after the previous stage has completed.
Similar to other types of jobs, a delayed job's timer will not start unless the previous stage passed.
The following example creates a job named `timed rollout 10%` that is executed 30 minutes after the previous stage has completed:
```yaml
timed rollout 10%:
stage: deploy
script: echo 'Rolling out 10% ...'
when: delayed
start_in: 30 minutes
```
You can stop the active timer of a delayed job by clicking the **Unschedule** button.
This job will never be executed in the future unless you execute the job manually.
You can start a delayed job immediately by clicking the **Play** button.
GitLab runner will pick your job soon and start the job.
## `environment` ## `environment`
> **Notes:** > **Notes:**
......
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