Commit 160c2311 authored by Olliver Schinagl's avatar Olliver Schinagl

doc: Professionalize only:changes section

Using we and you isn't very pleasant to read nor is it professional. So
lets remove these invocations to have a more pleasant read.
Signed-off-by: default avatarOlliver Schinagl <oliver@schinagl.nl>
parent 02d5d2bd
...@@ -499,9 +499,9 @@ docker build: ...@@ -499,9 +499,9 @@ docker build:
- more_scripts/*.{rb,py,sh} - more_scripts/*.{rb,py,sh}
``` ```
In the scenario above, if you are pushing multiple commits to GitLab to an In the scenario above, when pushing multiple commits to GitLab to an existing
existing branch, GitLab creates and triggers the `docker build` job, provided that branch, GitLab creates and triggers `docker build` job, provided that one of the
one of the commits contains changes to either: commits contains changes to either:
- The `Dockerfile` file. - The `Dockerfile` file.
- Any of the files inside `docker/scripts/` directory. - Any of the files inside `docker/scripts/` directory.
...@@ -514,21 +514,20 @@ the section below. ...@@ -514,21 +514,20 @@ the section below.
##### Using `changes` with new branches and tags ##### Using `changes` with new branches and tags
If you are pushing a **new** branch or a **new** tag to GitLab, the policy When pushing a **new** branch or a **new** tag to GitLab, the policy always
always evaluates to true and GitLab will create a job. This feature is not evaluates to true and GitLab will create a job. This feature is not connected
connected with merge requests yet, and because GitLab is creating pipelines with merge requests yet and, because GitLab is creating pipelines before a user
before an user can create a merge request we don't know a target branch at can create a merge request, it is unknown what the target branch is at this point.
this point.
##### Using `changes` with `merge_requests` ##### Using `changes` with `merge_requests`
With [pipelines for merge requests](../merge_request_pipelines/index.md), With [pipelines for merge requests](../merge_request_pipelines/index.md),
make it possible to define if a job should be created base on files modified it is possible to define a job to be created based on files modified
in a merge request. in a merge request.
For example: For example:
``` ```yaml
docker build service one: docker build service one:
script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG . script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
only: only:
...@@ -539,9 +538,9 @@ docker build service one: ...@@ -539,9 +538,9 @@ docker build service one:
- service-one/**/* - service-one/**/*
``` ```
In the scenario above, if you create or update a merge request that changes In the scenario above, if a merge request is created or updated that changes
either files in `service-one` folder or `Dockerfile`, GitLab creates and triggers either files in `service-one` directory or the `Dockerfile`, GitLab creates
the `docker build service one` job. and triggers the `docker build service one` job.
### `tags` ### `tags`
......
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