Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2019-10-03 06:06:07 +00:00
parent 427b23c127
commit ed58c35137
5 changed files with 42 additions and 29 deletions

View File

@ -117,7 +117,7 @@ The following table lists available parameters for jobs:
| [`extends`](#extends) | Configuration entries that this job is going to inherit from. |
| [`pages`](#pages) | Upload the result of a job to use with GitLab Pages. |
| [`variables`](#variables) | Define job variables on a job level. |
| [interruptible](#interruptible) | Defines if a job can be canceled when made redundant by a newer run |
| [`interruptible`](#interruptible) | Defines if a job can be canceled when made redundant by a newer run. |
NOTE: **Note:**
Parameters `types` and `type` are [deprecated](#deprecated-parameters).
@ -2155,19 +2155,19 @@ staging:
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/23464) in GitLab 12.3.
`interruptible` is used to indicate that a job should be canceled if made redundant by a newer run of the same job. Defaults to `false`.
`interruptible` is used to indicate that a job should be canceled if made redundant by a newer pipeline run. Defaults to `false`.
This value will only be used if the [automatic cancellation of redundant pipelines feature](../../user/project/pipelines/settings.md#auto-cancel-pending-pipelines)
is enabled.
When enabled, a pipeline on the same branch will be canceled when:
- It is made redundant by a newer pipeline run.
- Either all jobs are set as interruptible, or any uninterruptible jobs are not yet pending.
- Either all jobs are set as interruptible, or any uninterruptible jobs have not started.
Pending jobs are always considered interruptible.
TIP: **Tip:**
Set jobs as uninterruptible that should behave atomically and should never be canceled once started.
Set jobs as interruptible that can be safely canceled once started (for instance, a build job).
Here is a simple example:
@ -2175,23 +2175,33 @@ Here is a simple example:
stages:
- stage1
- stage2
- stage3
step-1:
stage: stage1
script:
- echo "Can be canceled"
- echo "Can be canceled."
interruptible: true
step-2:
stage: stage2
script:
- echo "Can not be canceled"
interruptible: false
- echo "Can not be canceled."
step-3:
stage: stage3
script:
- echo "Because step-2 can not be canceled, this step will never be canceled, even though set as interruptible."
interruptible: true
```
In the example above, a new pipeline run will cause an existing running pipeline to be:
- Canceled, if only `step-1` is running or pending.
- Not canceled, once `step-2` becomes pending.
- Not canceled, once `step-2` starts running.
NOTE: **Note:**
Once an uninterruptible job is running, the pipeline will never be canceled, regardless of the final job's state.
### `include`

View File

@ -64,7 +64,10 @@ GitLab.com uses the SAML NameID to identify users. The NameID element:
- Is a required field in the SAML response.
- Must be unique to each user.
- Must be a persistent value that will never change, such as a unique ID or username. Email could also be used as the NameID, but only if it can be guaranteed to never change.
- Must be a persistent value that will never change, such as a randomly generated unique user ID.
- Is case sensitive. The NameID must match exactly on subsequent login attempts, so should not rely on user input that could change between upper and lower case.
We strongly recommend against using Email as the NameID as it is hard to guarantee it will never change, for example when a person's name changes. Similarly usernames should be avoided if possible.
### Assertions

View File

@ -122,30 +122,33 @@ lein cloverage | perl -pe 's/\e\[?.*?[\@-~]//g'
## Visibility of pipelines
Access to pipelines and job details (including output of logs and artifacts)
is checked against your current user access level and the **Public pipelines**
project setting under your project's **Settings > CI/CD > General pipelines settings**.
Pipeline visibility is determined by:
- Your current [user access level](../../permissions.md).
- The **Public pipelines** project setting under your project's **Settings > CI/CD > General pipelines**.
This also determines the visibility of these related features:
- Job output logs
- Job artifacts
- The [pipeline security dashboard](../../application_security/security_dashboard/index.md#pipeline-security-dashboard) **(ULTIMATE)**
If **Public pipelines** is enabled (default):
- For **public** projects, anyone can view the pipelines and access the job details
(output logs and artifacts).
- For **public** projects, anyone can view the pipelines and related features.
- For **internal** projects, any logged in user can view the pipelines
and access the job details
(output logs and artifacts).
- For **private** projects, any member (guest or higher) can view the pipelines
and access the job details
(output logs and artifacts).
and related features.
- For **private** projects, any project member (guest or higher) can view the pipelines
and related features.
If **Public pipelines** is disabled:
- For **public** projects, anyone can view the pipelines, but only members
(reporter or higher) can access the job details (output logs and artifacts).
(reporter or higher) can access the related features.
- For **internal** projects, any logged in user can view the pipelines.
However, only members (reporter or higher) can access the job details (output logs
and artifacts).
- For **private** projects, only members (reporter or higher)
can view the pipelines and access the job details (output logs and artifacts).
However, only members (reporter or higher) can access the job related features.
- For **private** projects, only project members (reporter or higher)
can view the pipelines or access the related features.
## Auto-cancel pending pipelines

View File

@ -1617,9 +1617,6 @@ msgstr ""
msgid "Analytics"
msgstr ""
msgid "Analytics|Timeframe"
msgstr ""
msgid "Ancestors"
msgstr ""

View File

@ -27,7 +27,7 @@ describe Todos::Destroy::PrivateFeaturesService do
context 'when user_id is provided' do
subject { described_class.new(project.id, user.id).execute }
context 'when all feaures have same visibility as the project' do
context 'when all features have same visibility as the project' do
it 'removes only user issue todos' do
expect { subject }.not_to change { Todo.count }
end
@ -92,7 +92,7 @@ describe Todos::Destroy::PrivateFeaturesService do
context 'when user_id is not provided' do
subject { described_class.new(project.id).execute }
context 'when all feaures have same visibility as the project' do
context 'when all features have same visibility as the project' do
it 'does not remove any todos' do
expect { subject }.not_to change { Todo.count }
end