Add latest changes from gitlab-org/gitlab@master

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`
 

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
 

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
 

locale/gitlab.pot

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

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