From ed58c351374814027fbb2383ddecb9fa38de0c57 Mon Sep 17 00:00:00 2001 From: GitLab Bot Date: Thu, 3 Oct 2019 06:06:07 +0000 Subject: [PATCH] Add latest changes from gitlab-org/gitlab@master --- doc/ci/yaml/README.md | 26 ++++++++++----- doc/user/group/saml_sso/index.md | 5 ++- doc/user/project/pipelines/settings.md | 33 ++++++++++--------- locale/gitlab.pot | 3 -- .../destroy/private_features_service_spec.rb | 4 +-- 5 files changed, 42 insertions(+), 29 deletions(-) diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 95b57421a6f..4bb065f08b0 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -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` diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md index f718f01aba5..a2ba616d818 100644 --- a/doc/user/group/saml_sso/index.md +++ b/doc/user/group/saml_sso/index.md @@ -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 diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md index a901da978f0..74f48d24ba3 100644 --- a/doc/user/project/pipelines/settings.md +++ b/doc/user/project/pipelines/settings.md @@ -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 diff --git a/locale/gitlab.pot b/locale/gitlab.pot index 0c7ddc1e07e..bf696f2f414 100644 --- a/locale/gitlab.pot +++ b/locale/gitlab.pot @@ -1617,9 +1617,6 @@ msgstr "" msgid "Analytics" msgstr "" -msgid "Analytics|Timeframe" -msgstr "" - msgid "Ancestors" msgstr "" diff --git a/spec/services/todos/destroy/private_features_service_spec.rb b/spec/services/todos/destroy/private_features_service_spec.rb index 7831e3a47e0..dfe9f42e8b1 100644 --- a/spec/services/todos/destroy/private_features_service_spec.rb +++ b/spec/services/todos/destroy/private_features_service_spec.rb @@ -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