Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in / Register
Toggle navigation
G
gitlab-ce
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
1
Merge Requests
1
Analytics
Analytics
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Commits
Issue Boards
Open sidebar
nexedi
gitlab-ce
Commits
09075759
Commit
09075759
authored
Oct 02, 2018
by
Grzegorz Bizon
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Copy-edit docs for only: changes feature
parent
a52960f5
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
11 additions
and
10 deletions
+11
-10
doc/ci/yaml/README.md
doc/ci/yaml/README.md
+11
-10
No files found.
doc/ci/yaml/README.md
View file @
09075759
...
...
@@ -467,18 +467,19 @@ docker build:
```
In the scenario above, if you are pushing multiple commits to GitLab, to an
exising branch, GitLab is going to create and trigger
`docker build`
if one of
the commits contains changes to the
`Dockerfile`
file or any of the files
inside
`docker/scripts/`
directory.
exising branch, GitLab is going to create and trigger
`docker build`
job,
provided that one of the commits contains changes to the
`Dockerfile`
file or
changes to any of the files
inside
`docker/scripts/`
directory.
CAUTION:
**Warning:**
If you are pushing a
**new**
branch or a tag to GitLab, only/changes is going
to always evaluate to truth and GitLab will create a job. This feature is not
connected with merge requests yet, GitLab is creating pipelines before an user
creates a merge requests and specifies a target branch. Without a target branch
it is not possible to know what the common ancestor is in case of pushing a new
branch, thus we always create a job in that case. This feature works best for
stable branches like
`master`
.
If you are pushing a
**new**
branch or a new tag to GitLab, only/changes is
going to always evaluate to truth and GitLab will create a job. This feature is
not combined with merge requests yet, and because GitLab is creating pipelines
before an user can create a merge request we don't know a target branch at
this point. Without a target branchit is not possible to know what the common
ancestor is, thus we always create a job in that case. This feature works best for
stable branches like
`master`
because in that case GitLab uses previous commit,
that is present in a branch, to compare against a newly pushed latest SHA.
## `tags`
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment