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
eaa8cc1c
Commit
eaa8cc1c
authored
Feb 22, 2019
by
Marcel Amirault
Committed by
Evan Read
Feb 22, 2019
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Docs: (EE-Port) Fix all anchors related to YAML
parent
d6fa18c9
Changes
19
Hide whitespace changes
Inline
Side-by-side
Showing
19 changed files
with
30 additions
and
30 deletions
+30
-30
doc/ci/caching/index.md
doc/ci/caching/index.md
+3
-3
doc/ci/docker/using_docker_images.md
doc/ci/docker/using_docker_images.md
+2
-2
doc/ci/environments.md
doc/ci/environments.md
+5
-5
doc/ci/examples/dependency_scanning.md
doc/ci/examples/dependency_scanning.md
+1
-1
doc/ci/examples/license_management.md
doc/ci/examples/license_management.md
+1
-1
doc/ci/examples/sast.md
doc/ci/examples/sast.md
+1
-1
doc/ci/pipelines.md
doc/ci/pipelines.md
+1
-1
doc/ci/ssh_keys/README.md
doc/ci/ssh_keys/README.md
+1
-1
doc/ci/yaml/README.md
doc/ci/yaml/README.md
+3
-3
doc/user/admin_area/settings/continuous_integration.md
doc/user/admin_area/settings/continuous_integration.md
+2
-2
doc/user/gitlab_com/index.md
doc/user/gitlab_com/index.md
+1
-1
doc/user/project/merge_requests/browser_performance_testing.md
...ser/project/merge_requests/browser_performance_testing.md
+1
-1
doc/user/project/merge_requests/container_scanning.md
doc/user/project/merge_requests/container_scanning.md
+1
-1
doc/user/project/merge_requests/dast.md
doc/user/project/merge_requests/dast.md
+1
-1
doc/user/project/merge_requests/dependency_scanning.md
doc/user/project/merge_requests/dependency_scanning.md
+1
-1
doc/user/project/merge_requests/license_management.md
doc/user/project/merge_requests/license_management.md
+1
-1
doc/user/project/merge_requests/sast.md
doc/user/project/merge_requests/sast.md
+1
-1
doc/user/project/pages/introduction.md
doc/user/project/pages/introduction.md
+2
-2
doc/user/project/pipelines/job_artifacts.md
doc/user/project/pipelines/job_artifacts.md
+1
-1
No files found.
doc/ci/caching/index.md
View file @
eaa8cc1c
...
...
@@ -52,7 +52,7 @@ artifacts are also available in between stages within a pipeline. So if you
build your application by downloading all the required modules, you might want
to declare them as artifacts so that each subsequent stage can depend on them
being there. There are some optimizations like declaring an
[
expiry time
](
../yaml/README.md#artifacts
-
expire_in
)
so you don't keep artifacts
[
expiry time
](
../yaml/README.md#artifactsexpire_in
)
so you don't keep artifacts
around too long, and using
[
dependencies
](
../yaml/README.md#dependencies
)
to
control exactly where artifacts are passed around.
...
...
@@ -87,7 +87,7 @@ cache, when declaring `cache` in your jobs, use one or a mix of the following:
that share their cache.
-
[
Use sticky Runners
](
../runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects
)
that will be only available to a particular project.
-
[
Use a `key`
](
../yaml/README.md#cache
-
key
)
that fits your workflow (e.g.,
-
[
Use a `key`
](
../yaml/README.md#cachekey
)
that fits your workflow (e.g.,
different caches on each branch). For that, you can take advantage of the
[
CI/CD predefined variables
](
../variables/README.md#predefined-environment-variables
)
.
...
...
@@ -169,7 +169,7 @@ job:
```
For more fine tuning, read also about the
[
`cache: policy`
](
../yaml/README.md#cache
-
policy
)
.
[
`cache: policy`
](
../yaml/README.md#cachepolicy
)
.
## Common use cases
...
...
doc/ci/docker/using_docker_images.md
View file @
eaa8cc1c
...
...
@@ -391,9 +391,9 @@ CI jobs:
from
`Dockerfile`
that may be overridden in
`.gitlab-ci.yml`
)
1.
The Runner attaches itself to a running container.
1.
The Runner prepares a script (the combination of
[
`before_script`
](
../yaml/README.md#before_script
)
,
[
`before_script`
](
../yaml/README.md#before_script
-and-after_script
)
,
[
`script`
](
../yaml/README.md#script
)
,
and
[
`after_script`
](
../yaml/README.md#after_script
)
).
and
[
`after_script`
](
../yaml/README.md#
before_script-and-
after_script
)
).
1.
The Runner sends the script to the container's shell STDIN and receives the
output.
...
...
doc/ci/environments.md
View file @
eaa8cc1c
...
...
@@ -103,7 +103,7 @@ the Git SHA and environment name.
To sum up, with the above
`.gitlab-ci.yml`
we have achieved that:
-
All branches will run the
`test`
and
`build`
jobs.
-
The
`deploy_staging`
job will run
[
only
](
yaml/README.md#only
)
on the
`master`
-
The
`deploy_staging`
job will run
[
only
](
yaml/README.md#only
-and-except-simplified
)
on the
`master`
branch which means all merge requests that are created from branches don't
get to deploy to the staging server
-
When a merge request is merged, all jobs will run and the
`deploy_staging`
...
...
@@ -401,7 +401,7 @@ Let's briefly see where URL that's defined in the environments is exposed.
## Making use of the environment URL
The
[
environment URL
](
yaml/README.md#environment
s-
url
)
is exposed in a few
The
[
environment URL
](
yaml/README.md#environmenturl
)
is exposed in a few
places within GitLab.
| In a merge request widget as a link | In the Environments view as a button | In the Deployments view as a button |
...
...
@@ -652,9 +652,9 @@ Below are some links you may find interesting:
[
deployments
]:
#deployments
[
permissions
]:
../user/permissions.md
[
variables
]:
variables/README.md
[
env-name
]:
yaml/README.md#environment
-
name
[
only
]:
yaml/README.md#only-and-except
[
onstop
]:
yaml/README.md#environment
-
on_stop
[
env-name
]:
yaml/README.md#environmentname
[
only
]:
yaml/README.md#only-and-except
-simplified
[
onstop
]:
yaml/README.md#environmenton_stop
[
ce-7015
]:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7015
[
gitlab-flow
]:
../workflow/gitlab_flow.md
[
gitlab runner
]:
https://docs.gitlab.com/runner/
...
...
doc/ci/examples/dependency_scanning.md
View file @
eaa8cc1c
...
...
@@ -37,7 +37,7 @@ dependency_scanning:
The above example will create a
`dependency_scanning`
job in your CI/CD pipeline
and scan your dependencies for possible vulnerabilities. The report will be saved as a
[
Dependency Scanning report artifact
](
../../ci/yaml/README.md#artifactsreportsdependency_scanning
)
[
Dependency Scanning report artifact
](
../../ci/yaml/README.md#artifactsreportsdependency_scanning
-ultimate
)
that you can later download and analyze.
Due to implementation limitations we always take the latest Dependency Scanning artifact available.
...
...
doc/ci/examples/license_management.md
View file @
eaa8cc1c
...
...
@@ -30,7 +30,7 @@ license_management:
The above example will create a
`license_management`
job in your CI/CD pipeline
and scan your dependencies to find their licenses. The report will be saved as a
[
License Management report artifact
](
../../ci/yaml/README.md#artifactsreportslicense_management
)
[
License Management report artifact
](
../../ci/yaml/README.md#artifactsreportslicense_management
-ultimate
)
that you can later download and analyze.
Due to implementation limitations we always take the latest License Management artifact available.
...
...
doc/ci/examples/sast.md
View file @
eaa8cc1c
...
...
@@ -37,7 +37,7 @@ sast:
The above example will create a
`sast`
job in your CI/CD pipeline
and scan your dependencies for possible vulnerabilities. The report will be saved as a
[
SAST report artifact
](
../../ci/yaml/README.md#artifactsreportssast
)
[
SAST report artifact
](
../../ci/yaml/README.md#artifactsreportssast
-ultimate
)
that you can later download and analyze.
Due to implementation limitations we always take the latest SAST artifact available.
...
...
doc/ci/pipelines.md
View file @
eaa8cc1c
...
...
@@ -197,7 +197,7 @@ stage has a job with a manual action.
> [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#when
-
delayed
)
.
When you do not want to run a job immediately, you can
[
delay the job to run after a certain period
](
yaml/README.md#whendelayed
)
.
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,
...
...
doc/ci/ssh_keys/README.md
View file @
eaa8cc1c
...
...
@@ -92,7 +92,7 @@ to access it. This is where an SSH key pair comes in handy.
```
NOTE: **Note:**
The [`before_script`](../yaml/README.md#before
-
script) can be set globally
The [`before_script`](../yaml/README.md#before
_script-and-after_
script) can be set globally
or per-job.
1.
Make sure the private server's
[
SSH host keys are verified
](
#verifying-the-ssh-host-keys
)
.
...
...
doc/ci/yaml/README.md
View file @
eaa8cc1c
...
...
@@ -1208,7 +1208,7 @@ job:
`expire_in`
allows you to specify how long artifacts should live before they
expire and therefore deleted, counting from the time they are uploaded and
stored on GitLab. If the expiry time is not defined, it defaults to the
[
instance wide setting
](
../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration
)
[
instance wide setting
](
../../user/admin_area/settings/continuous_integration.md#default-artifacts-expiration
-core-only
)
(30 days by default, forever on GitLab.com).
You can use the
**Keep**
button on the job page to override expiration and
...
...
@@ -1247,7 +1247,7 @@ this with [JUnit reports](#artifactsreportsjunit).
NOTE:
**Note:**
The test reports are collected regardless of the job results (success or failure).
You can use
[
`artifacts:expire_in`
](
#artifacts
-
expire_in
)
to set up an expiration
You can use
[
`artifacts:expire_in`
](
#artifactsexpire_in
)
to set up an expiration
date for their artifacts.
NOTE:
**Note:**
...
...
@@ -1427,7 +1427,7 @@ deploy:
> Introduced in GitLab 10.3.
If the artifacts of the job that is set as a dependency have been
[
expired
](
#artifacts
-
expire_in
)
or
[
expired
](
#artifactsexpire_in
)
or
[
erased
](
../../user/project/pipelines/job_artifacts.md#erasing-artifacts
)
, then
the dependent job will fail.
...
...
doc/user/admin_area/settings/continuous_integration.md
View file @
eaa8cc1c
...
...
@@ -38,7 +38,7 @@ To change it:
The default expiration time of the
[
job artifacts
](
../../../administration/job_artifacts.md
)
can be set in the Admin area of your GitLab instance. The syntax of duration is
described in
[
`artifacts:expire_in`
](
../../../ci/yaml/README.md#artifacts
-
expire_in
)
described in
[
`artifacts:expire_in`
](
../../../ci/yaml/README.md#artifactsexpire_in
)
and the default value is
`30 days`
. On GitLab.com they
[
never expire
](
../../gitlab_com/index.md#gitlab-ci-cd
)
.
...
...
@@ -47,7 +47,7 @@ and the default value is `30 days`. On GitLab.com they
1.
Hit
**Save changes**
for the changes to take effect.
This setting is set per job and can be overridden in
[
`.gitlab-ci.yml`
](
../../../ci/yaml/README.md#artifacts
-
expire_in
)
.
[
`.gitlab-ci.yml`
](
../../../ci/yaml/README.md#artifactsexpire_in
)
.
To disable the expiration, set it to
`0`
. The default unit is in seconds.
## Shared Runners pipeline minutes quota **[STARTER ONLY]**
...
...
doc/user/gitlab_com/index.md
View file @
eaa8cc1c
...
...
@@ -60,7 +60,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md).
| Setting | GitLab.com | Default |
| ----------- | ----------------- | ------------- |
| Artifacts maximum size | 1G | 100M |
| Artifacts
[
expiry time
](
../../ci/yaml/README.md#artifacts
-
expire_in
)
| kept forever | deleted after 30 days unless otherwise specified |
| Artifacts
[
expiry time
](
../../ci/yaml/README.md#artifactsexpire_in
)
| kept forever | deleted after 30 days unless otherwise specified |
## Repository size limit
...
...
doc/user/project/merge_requests/browser_performance_testing.md
View file @
eaa8cc1c
...
...
@@ -37,7 +37,7 @@ For instance, consider the following workflow:
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
Performance report artifact
](
../../../ci/yaml/README.md#artifactsreportsperformance
)
.
[
Performance report artifact
](
../../../ci/yaml/README.md#artifactsreportsperformance
-premium
)
.
For more information on how the Performance job should look like, check the
example on
[
Testing Browser Performance
](
../../../ci/examples/browser_performance.md
)
.
...
...
doc/user/project/merge_requests/container_scanning.md
View file @
eaa8cc1c
...
...
@@ -34,7 +34,7 @@ to perform audits for your Docker-based apps.
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
Container Scanning report artifact
](
../../../ci/yaml/README.md#artifactsreportscontainer_scanning
)
.
[
Container Scanning report artifact
](
../../../ci/yaml/README.md#artifactsreportscontainer_scanning
-ultimate
)
.
For more information on how the Container Scanning job should look like, check the
example on
[
Container Scanning with GitLab CI/CD
](
../../../ci/examples/container_scanning.md
)
.
...
...
doc/user/project/merge_requests/dast.md
View file @
eaa8cc1c
...
...
@@ -30,7 +30,7 @@ applications while you are developing and testing your applications.
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
DAST report artifact
](
../../../ci/yaml/README.md#artifactsreportsdast
)
.
[
DAST report artifact
](
../../../ci/yaml/README.md#artifactsreportsdast
-ultimate
)
.
For more information on how the DAST job should look like, check the
example on
[
Dynamic Application Security Testing with GitLab CI/CD
](
../../../ci/examples/dast.md
)
.
...
...
doc/user/project/merge_requests/dependency_scanning.md
View file @
eaa8cc1c
...
...
@@ -40,7 +40,7 @@ check [GitLab Dependency Scanning documentation](https://gitlab.com/gitlab-org/s
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
Dependency Scanning report artifact
](
../../../ci/yaml/README.md#artifactsreportsdependency_scanning
)
.
[
Dependency Scanning report artifact
](
../../../ci/yaml/README.md#artifactsreportsdependency_scanning
-ultimate
)
.
For more information on how the Dependency Scanning job should look like, check the
example on
[
Dependency Scanning with GitLab CI/CD
](
../../../ci/examples/dependency_scanning.md
)
.
...
...
doc/user/project/merge_requests/license_management.md
View file @
eaa8cc1c
...
...
@@ -41,7 +41,7 @@ The following languages and package managers are supported.
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
License Management report artifact
](
../../../ci/yaml/README.md#artifactsreportslicense_management
)
.
[
License Management report artifact
](
../../../ci/yaml/README.md#artifactsreportslicense_management
-ultimate
)
.
For more information on how the License Management job should look like, check the
example on
[
Dependencies license management with GitLab CI/CD
](
../../../ci/examples/license_management.md
)
.
...
...
doc/user/project/merge_requests/sast.md
View file @
eaa8cc1c
...
...
@@ -49,7 +49,7 @@ The following languages and frameworks are supported.
## How it works
First of all, you need to define a job in your
`.gitlab-ci.yml`
file that generates the
[
SAST report artifact
](
../../../ci/yaml/README.md#artifactsreportssast
)
.
[
SAST report artifact
](
../../../ci/yaml/README.md#artifactsreportssast
-ultimate
)
.
For more information on how the SAST job should look like, check the
example on
[
Static Application Security Testing with GitLab CI/CD
](
../../../ci/examples/sast.md
)
.
...
...
doc/user/project/pages/introduction.md
View file @
eaa8cc1c
...
...
@@ -151,7 +151,7 @@ Depending on how you plan to publish your website, the steps defined in the
Be aware that Pages are by default branch/tag agnostic and their deployment
relies solely on what you specify in
`.gitlab-ci.yml`
. If you don't limit the
`pages`
job with the
[
`only` parameter
](
../../../ci/yaml/README.md#only-and-except
)
,
`pages`
job with the
[
`only` parameter
](
../../../ci/yaml/README.md#only-and-except
-simplified
)
,
whenever a new commit is pushed to whatever branch or tag, the Pages will be
overwritten. In the example below, we limit the Pages to be deployed whenever
a commit is pushed only on the
`master`
branch:
...
...
@@ -252,7 +252,7 @@ get you started.
Remember that GitLab Pages are by default branch/tag agnostic and their
deployment relies solely on what you specify in
`.gitlab-ci.yml`
. You can limit
the
`pages`
job with the
[
`only` parameter
](
../../../ci/yaml/README.md#only-and-except
)
,
the
`pages`
job with the
[
`only` parameter
](
../../../ci/yaml/README.md#only-and-except
-simplified
)
,
whenever a new commit is pushed to a branch that will be used specifically for
your pages.
...
...
doc/user/project/pipelines/job_artifacts.md
View file @
eaa8cc1c
...
...
@@ -195,5 +195,5 @@ artifacts and the job's trace.
In order to retrieve a job artifact of a different project, you might need to use a private token in order to
[
authenticate and download
](
../../../api/jobs.md#get-job-artifacts
)
the artifacts.
[
expiry date
]:
../../../ci/yaml/README.md#artifacts
-
expire_in
[
expiry date
]:
../../../ci/yaml/README.md#artifactsexpire_in
[
ce-14399
]:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14399
\ No newline at end of file
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