- Manually specifying the job definition. Not recommended unless using GitLab
11.8 and earlier.
### Including the provided template
NOTE: **Note:**
The CI/CD Container Scanning template is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
A CI/CD [Container Scanning template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
with the default Container Scanning job definition is provided as a part of your GitLab
installation that you can [include](../../../ci/yaml/README.md#includetemplate)
in your `.gitlab-ci.yml` file.
To enable Container Scanning using the provided template, add the following to
your `.gitlab-ci.yml` file:
Add the following to your `.gitlab-ci.yml` file:
```yaml
include:
...
...
@@ -89,12 +73,12 @@ include:
The included template will:
- Create a `container_scanning` job in your CI/CD pipeline.
- Pull the already built Docker image from your project's
is used to run the tests on the specified URL and scan it for possible vulnerabilities.
There are two ways to define the URL to be scanned by DAST:
- Set the `DAST_WEBSITE`[variable](../../../ci/yaml/README.md#variables).
- Add it in an `environment_url.txt` file at the root of your project.
#### Authenticated scan
### Authenticated scan
It's also possible to authenticate the user before performing the DAST checks:
...
...
@@ -117,12 +103,12 @@ variables:
DAST_AUTH_EXCLUDE_URLS:http://example.com/sign-out,http://example.com/sign-out-2# optional, URLs to skip during the authenticated scan; comma-separated, no spaces in between
that's provided as a part of your GitLab installation.
For GitLab versions earlier than 11.9, you can copy and use the job as defined
that template.
This can be done in two ways:
- For GitLab 11.9 and later, including the provided `Dependency-Scanning.gitlab-ci.yml` template (recommended).
- Manually specifying the job definition. Not recommended unless using GitLab
11.8 and earlier.
### Including the provided template
NOTE: **Note:**
The CI/CD Dependency Scanning template is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
A CI/CD [Dependency Scanning template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/Dependency-Scanning.gitlab-ci.yml)
with the default Dependency Scanning job definition is provided as a part of your GitLab
installation which you can [include](../../../ci/yaml/README.md#includetemplate)
in your `.gitlab-ci.yml` file.
To enable Dependency Scanning using the provided template, add the following to
your `.gitlab-ci.yml` file:
Add the following to your `.gitlab-ci.yml` file:
```yaml
include:
...
...
@@ -108,12 +93,12 @@ include:
The included template will create a `dependency_scanning` job in your CI/CD
pipeline and scan your project's source code for possible vulnerabilities.
that you can later download and analyze. Due to implementation limitations, we
always take the latest Dependency Scanning artifact available.
#### Customizing the Dependency Scanning settings
### Customizing the Dependency Scanning settings
The Dependency Scanning settings can be changed through [environment variables](#available-variables) by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`.
...
...
@@ -131,7 +116,7 @@ variables:
Because template is [evaluated before](../../../ci/yaml/README.md#include) the pipeline
configuration, the last mention of the variable will take precedence.
#### Overriding the Dependency Scanning template
### Overriding the Dependency Scanning template
If you want to override the job definition (for example, change properties like
`variables` or `dependencies`), you need to declare a `dependency_scanning` job
...
...
@@ -146,7 +131,7 @@ dependency_scanning:
CI_DEBUG_TRACE:"true"
```
#### Available variables
### Available variables
Dependency Scanning can be [configured](#customizing-the-dependency-scanning-settings)
using environment variables.
...
...
@@ -164,82 +149,6 @@ using environment variables.
| `DS_PULL_ANALYZER_IMAGE_TIMEOUT` | Time limit when pulling the image of an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
| `DS_RUN_ANALYZER_TIMEOUT` | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
### Manual job definition for GitLab 11.5 and later
For GitLab 11.5 and GitLab Runner 11.5 and later, the following `dependency_scanning`
job can be added:
```yaml
dependency_scanning:
image:docker:stable
variables:
DOCKER_DRIVER:overlay2
allow_failure:true
services:
-docker:stable-dind
script:
-export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
that's provided as a part of your GitLab installation.
For GitLab versions earlier than 11.9, you can copy and use the job as defined
that template.
This can be done in two ways:
- For GitLab 11.9 and later, including the provided `License-Management.gitlab-ci.yml` template (recommended).
- Manually specifying the job definition. Not recommended unless using GitLab
11.8 and earlier.
The License Management settings can be changed through environment variables by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Management documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
### Including the provided template
NOTE: **Note:**
The CI/CD License Management template is supported on GitLab 11.9 and later versions.
For earlier versions, use the [manual job definition](#manual-job-definition-for-gitlab-115-and-later).
A CI/CD [License Management template](https://gitlab.com/gitlab-org/gitlab-ee/blob/master/lib/gitlab/ci/templates/Security/License-Management.gitlab-ci.yml)
with the default License Management job definition is provided as a part of your GitLab
installation which you can [include](../../../ci/yaml/README.md#includetemplate)
in your `.gitlab-ci.yml` file.
To enable License Management using the provided template, add the following to
your `.gitlab-ci.yml` file:
Add the following to your `.gitlab-ci.yml` file:
```yaml
include:
...
...
@@ -101,14 +84,17 @@ include:
The included template will create a `license_management` job in your CI/CD pipeline
and scan your dependencies to find their licenses.
is used to detect the languages/frameworks and in turn analyzes the licenses.
#### Installing custom dependencies
The License Management settings can be changed through environment variables by using the
[`variables`](../../../ci/yaml/README.md#variables) parameter in `.gitlab-ci.yml`. These variables are documented in the [License Management documentation](https://gitlab.com/gitlab-org/security-products/license-management#settings).
### Installing custom dependencies
> Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 11.4.
...
...
@@ -136,7 +122,7 @@ variables:
In this example, `my-custom-install-script.sh` is a shell script at the root
directory of your project.
#### Overriding the template
### Overriding the template
If you want to override the job definition (for example, change properties like
`variables` or `dependencies`), you need to declare a `license_management` job
...
...
@@ -151,7 +137,7 @@ license_management:
CI_DEBUG_TRACE:"true"
```
#### Configuring Maven projects
### Configuring Maven projects
The License Management tool provides a `MAVEN_CLI_OPTS` environment variable which can hold
the command line arguments to pass to the `mvn install` command which is executed under the hood.
...
...
@@ -192,67 +178,6 @@ license_management:
LM_PYTHON_VERSION:3
```
### Manual job definition for GitLab 11.5 and later
For GitLab 11.5 and GitLab Runner 11.5 and later, the following `license_management`
@@ -17,6 +17,6 @@ Once you have configured and enabled Custom Issue Tracker Service you'll see a l
## Referencing issues
- Issues are referenced with `ANYTHING-<ID>`, where `ANYTHING` can be any string and `<ID>` is a number used in the target project of the custom integration (example `PROJECT-143`).
- Issues are referenced with `ANYTHING-<ID>`, where `ANYTHING` can be any string and `<ID>` is a number used in the target project of the custom integration (example `PROJECT-143`).
-`ANYTHING` is a placeholder to differentiate against GitLab issues, which are referenced with `#<ID>`. You can use a project name or project key to replace it for example.
- So with the example above, `PROJECT-143` would refer to `https://customissuetracker.com/project-name/143`.
\ No newline at end of file
- So with the example above, `PROJECT-143` would refer to `https://customissuetracker.com/project-name/143`.
@@ -48,7 +48,6 @@ Exported issues are always sorted by `Issue ID`.
Data will be encoded with a comma as the column delimiter, with `"` used to quote fields if needed, and newlines to separate rows. The first row will be the headers, which are listed in the following table along with a description of the values:
| Column | Description |
|---------|-------------|
| Issue ID | Issue `iid` |
...
...
@@ -71,7 +70,6 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
| Time Estimate | [Time estimate](../../../workflow/time_tracking.md#estimates) in seconds |
| Time Spent | [Time spent](../../../workflow/time_tracking.md#time-spent) in seconds |
## Limitations
As the issues will be sent as an email attachment, there is a limit on how much data can be exported. Currently this limit is 20MB to ensure successful delivery across a range of email providers. If this limit is reached we suggest narrowing the search before export, perhaps by exporting open and closed issues separately.
@@ -250,7 +250,7 @@ If you are storing LFS files outside of GitLab you can disable LFS on the projec
It is possible to host LFS objects externally by setting a custom LFS url with `git config -f .lfsconfig lfs.url https://example.com/<project>.git/info/lfs`.
You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store,
You might choose to do this if you are using an appliance like a Sonatype Nexus to store LFS data. If you choose to use an external LFS store,
GitLab will not be able to verify LFS objects which means that pushes will fail if you have GitLab LFS support enabled.
To stop push failure, LFS support can be disabled in the [Project settings](../../user/project/settings/index.md). This means you will lose GitLab LFS value-adds (Verifying LFS objects, UI integration for LFS).
