1.**Prometheus** (needed for Auto Monitoring) - To enable Auto Monitoring, you
-**Prometheus** (needed for Auto Monitoring) - To enable Auto Monitoring, you
will need Prometheus installed somewhere (inside or outside your cluster) and
configured to scrape your Kubernetes cluster. To get response metrics
(in addition to system metrics), you need to
...
...
@@ -147,7 +148,7 @@ NOTE: **Note**
A wildcard DNS A record matching the base domain(s) is required, for example,
given a base domain of `example.com`, you'd need a DNS entry like:
```
```text
*.example.com 3600 A 1.2.3.4
```
...
...
@@ -224,7 +225,7 @@ full use of Auto DevOps are available. If this is your fist time, we recommend y
GitLab.com users can enable/disable Auto DevOps at the project-level only. Self-managed users
can enable/disable Auto DevOps at the project-level, group-level or instance-level.
### Enabling/disabling Auto DevOps at the instance-level (Administrators only)
### At the instance level (Administrators only)
Even when disabled at the instance level, group owners and project maintainers can still enable
Auto DevOps at the group and project level, respectively.
...
...
@@ -234,7 +235,7 @@ Auto DevOps at the group and project level, respectively.
1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps.
1. Click **Save changes** for the changes to take effect.
### Enabling/disabling Auto DevOps at the group-level
### At the group level
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/52447) in GitLab 11.10.
...
...
@@ -250,7 +251,7 @@ When enabling or disabling Auto DevOps at group-level, group configuration will
the subgroups and projects inside that group, unless Auto DevOps is specifically enabled or disabled on
the subgroup or project.
### Enabling/disabling Auto DevOps at the project-level
### At the project level
If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one exists, remove it.
...
...
@@ -263,7 +264,7 @@ If enabling, check that your project doesn't have a `.gitlab-ci.yml`, or if one
When the feature has been enabled, an Auto DevOps pipeline is triggered on the default branch.
### Feature flag to enable for a percentage of projects
### Enable for a percentage of projects
There is also a feature flag to enable Auto DevOps by default to your chosen percentage of projects.
...
...
@@ -371,7 +372,7 @@ Any differences between the source and target branches are also
Static Application Security Testing (SAST) uses the
[SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
analysis on the current code and checks for potential security issues. The
the Auto SAST stage will be skipped on licenses other than Ultimate and requires GitLab Runner 11.5 or above.
Auto SAST stage will be skipped on licenses other than Ultimate and requires GitLab Runner 11.5 or above.
Once the report is created, it's uploaded as an artifact which you can later download and
check out.
...
...
@@ -488,7 +489,7 @@ Any security warnings are also shown in the merge request widget. Read how
Auto Browser Performance Testing utilizes the [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) to measure the performance of a web page. A JSON report is created and uploaded as an artifact, which includes the overall performance score for each page. By default, the root page of Review and Production environments will be tested. If you would like to add additional URL's to test, simply add the paths to a file named `.gitlab-urls.txt` in the root directory, one per line. For example: