@@ -166,6 +176,19 @@ need to configure anything to have these appear.
...
@@ -166,6 +176,19 @@ need to configure anything to have these appear.
If they aren't working as expected, or if you'd like to see what's available, our [CI feature index](../README.md#feature-set) has the full list
If they aren't working as expected, or if you'd like to see what's available, our [CI feature index](../README.md#feature-set) has the full list
of bundled features and links to the documentation for each.
of bundled features and links to the documentation for each.
### Templates
For advanced CI/CD teams, project templates can enable the reuse of pipeline configurations,
as well as encourage inner sourcing.
In self-managed GitLab instances, you can build an [Instance Template Repository](../../user/admin_area/settings/instance_template_repository.md).
Development teams across the whole organization can select templates from a dropdown menu.
A group administrator is able to set a group to use as the source for the
[custom project templates](../../user/admin_area/custom_project_templates.md), which can
be used by all projects in the group. An instance adminsitrator can set a group as
the source for [instance project templates](../../user/group/custom_project_templates.md),
which can be used by projects in that instance.
## Converting Declarative Jenkinsfiles
## Converting Declarative Jenkinsfiles
Declarative Jenkinsfiles contain "Sections" and "Directives" which are used to control the behavior of your
Declarative Jenkinsfiles contain "Sections" and "Directives" which are used to control the behavior of your
...
@@ -186,7 +209,7 @@ to different Runners (execution agents).
...
@@ -186,7 +209,7 @@ to different Runners (execution agents).
The `agent` section also allows you to define which Docker images should be used for execution, for which we use
The `agent` section also allows you to define which Docker images should be used for execution, for which we use
the [`image`](../yaml/README.md#image) keyword. The `image` can be set on a single job or at the top level, in which
the [`image`](../yaml/README.md#image) keyword. The `image` can be set on a single job or at the top level, in which
case it will apply to all jobs in the pipeline.
case it will apply to all jobs in the pipeline:
```yaml
```yaml
my_job:
my_job:
...
@@ -198,7 +221,7 @@ my_job:
...
@@ -198,7 +221,7 @@ my_job:
The `post` section defines the actions that should be performed at the end of the pipeline. GitLab also supports
The `post` section defines the actions that should be performed at the end of the pipeline. GitLab also supports
this through the use of stages. You can define your stages as follows, and any jobs assigned to the `before_pipeline`
this through the use of stages. You can define your stages as follows, and any jobs assigned to the `before_pipeline`
or `after_pipeline` stages will run as expected. You can call these stages anything you like.
or `after_pipeline` stages will run as expected. You can call these stages anything you like:
```yaml
```yaml
stages:
stages:
...
@@ -209,7 +232,8 @@ stages:
...
@@ -209,7 +232,8 @@ stages:
-after_pipeline
-after_pipeline
```
```
Setting a step to be performed before and after any job can be done via the [`before_script` and `after_script` keywords](../yaml/README.md#before_script-and-after_script).
Setting a step to be performed before and after any job can be done via the
[`before_script` and `after_script` keywords](../yaml/README.md#before_script-and-after_script):
```yaml
```yaml
default:
default:
...
@@ -242,7 +266,7 @@ my_job:
...
@@ -242,7 +266,7 @@ my_job:
#### `steps`
#### `steps`
The `steps` section is equivalent to the [`script` section](../yaml/README.md#script) of an individual job. This is
The `steps` section is equivalent to the [`script` section](../yaml/README.md#script) of an individual job. This is
a simple YAML array with each line representing an individual command to be run.
a simple YAML array with each line representing an individual command to be run:
```yaml
```yaml
my_job:
my_job:
...
@@ -259,7 +283,7 @@ my_job:
...
@@ -259,7 +283,7 @@ my_job:
In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime.
In GitLab, we use the [`variables` keyword](../yaml/README.md#variables) to define different variables at runtime.
These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/README.md),
These can also be set up through the GitLab UI, under CI/CD settings. See also our [general documentation on variables](../variables/README.md),
including the section on [protected variables](../variables/README.md#protected-environment-variables) which can be used
including the section on [protected variables](../variables/README.md#protected-environment-variables) which can be used
to limit access to certain variables to certain environments or runners.
to limit access to certain variables to certain environments or runners:
```yaml
```yaml
variables:
variables:
...
@@ -302,7 +326,8 @@ variable entry.
...
@@ -302,7 +326,8 @@ variable entry.
GitLab does support a [`when` keyword](../yaml/README.md#when) which is used to indicate when a job should be
GitLab does support a [`when` keyword](../yaml/README.md#when) which is used to indicate when a job should be
run in case of (or despite) failure, but most of the logic for controlling pipelines can be found in
run in case of (or despite) failure, but most of the logic for controlling pipelines can be found in
our very powerful [`only/except` rules system](../yaml/README.md#onlyexcept-basic)(see also our [advanced syntax](../yaml/README.md#onlyexcept-basic))
our very powerful [`only/except` rules system](../yaml/README.md#onlyexcept-basic)
(see also our [advanced syntax](../yaml/README.md#onlyexcept-basic)):
@@ -51,10 +51,8 @@ We recommend setting the NameID format to `Persistent` unless using a field (suc
...
@@ -51,10 +51,8 @@ We recommend setting the NameID format to `Persistent` unless using a field (suc
### SSO enforcement
### SSO enforcement
SSO enforcement was:
-[Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5291) in GitLab 11.8.
-[Improved](https://gitlab.com/gitlab-org/gitlab/issues/9255) in GitLab 11.11 with ongoing enforcement in the GitLab UI.
-[Introduced in GitLab 11.8](https://gitlab.com/gitlab-org/gitlab/issues/5291).
-[Improved upon in GitLab 11.11 with ongoing enforcement in the GitLab UI](https://gitlab.com/gitlab-org/gitlab/issues/9255).
With this option enabled, users must use your group's GitLab single sign on URL to be added to the group or be added via SCIM. Users cannot be added manually, and may only access project/group resources via the UI by signing in through the SSO URL.
With this option enabled, users must use your group's GitLab single sign on URL to be added to the group or be added via SCIM. Users cannot be added manually, and may only access project/group resources via the UI by signing in through the SSO URL.
...
@@ -66,7 +64,7 @@ When SSO enforcement is enabled for a group, users cannot share a project in the
...
@@ -66,7 +64,7 @@ When SSO enforcement is enabled for a group, users cannot share a project in the
#### Group-managed accounts
#### Group-managed accounts
> [Introduced in GitLab 12.1](https://gitlab.com/groups/gitlab-org/-/epics/709).
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/709) in GitLab 12.1.
When SSO is being enforced, groups can enable an additional level of protection by enforcing the creation of dedicated user accounts to access the group.
When SSO is being enforced, groups can enable an additional level of protection by enforcing the creation of dedicated user accounts to access the group.
...
@@ -90,7 +88,7 @@ Since use of the group-managed account requires the use of SSO, users of group-m
...
@@ -90,7 +88,7 @@ Since use of the group-managed account requires the use of SSO, users of group-m
##### Credentials inventory for Group-managed accounts **(ULTIMATE)**
##### Credentials inventory for Group-managed accounts **(ULTIMATE)**
> [Introduced in GitLab 12.8](https://gitlab.com/gitlab-org/gitlab/issues/38133)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/38133) in GitLab 12.8.
Owners who manage user accounts in a group can view the following details of personal access tokens and SSH keys:
Owners who manage user accounts in a group can view the following details of personal access tokens and SSH keys:
...
@@ -104,7 +102,7 @@ This feature is similar to the [Credentials inventory for self-managed instances
...
@@ -104,7 +102,7 @@ This feature is similar to the [Credentials inventory for self-managed instances
##### Outer forks restriction for Group-managed accounts
##### Outer forks restriction for Group-managed accounts
> [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/34648)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/34648) in GitLab 12.9.
Groups with enabled group-managed accounts can allow or disallow forking of projects outside of root group
Groups with enabled group-managed accounts can allow or disallow forking of projects outside of root group
by using separate toggle. If forking is disallowed any project of given root group or its subgroups can be forked to
by using separate toggle. If forking is disallowed any project of given root group or its subgroups can be forked to
...
@@ -112,11 +110,12 @@ a subgroup of the same root group only.
...
@@ -112,11 +110,12 @@ a subgroup of the same root group only.
##### Other restrictions for Group-managed accounts
##### Other restrictions for Group-managed accounts
> [Introduced in GitLab 12.9](https://gitlab.com/gitlab-org/gitlab/issues/12420)
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/12420) in GitLab 12.9.
Projects within groups with enabled group-managed accounts are not to be shared with:
Projects within groups with enabled group-managed accounts are not to be shared with:
- Groups outside of the parent group
- Groups outside of the parent group.
- Members who are not users managed by this group
- Members who are not users managed by this group.
This restriction also applies to projects forked from or to those groups.
This restriction also applies to projects forked from or to those groups.