Add latest changes from gitlab-org/gitlab@master

data/whats_new/202310220001_16_5.yml

@@ -0,0 +1,60 @@
+- name: Compliance standards adherence report
+  description: | # Do not modify this line, instead modify the lines below.
+    The Compliance Center now includes a new tab for the standards adherence report.
+    This report initially includes a GitLab best practices standard, showing when the
+    projects in your group are not meeting the requirements for the checks included in the standard. The
+    three checks shown initially are:
+
+    - Approval rule exists to require at least 2 approvers on MRs
+    - Approval rule exists to disallow the MR author to merge
+    - Approval rule exists to disallow committers to the MR to merge
+
+    The report contains details on the status of each check on a per project basis. It will
+    also show you when the check was last run, which standard the check applies to,
+    and how to fix any failures or problems that might be shown on the report. Future iterations
+    will add more checks and expand the scope to include more regulations and standards.
+    Additionally, we will be adding improvements to group and filter the report, so you
+    can focus on the projects or standards that matter most to your organization.
+  stage: govern
+  self-managed: true
+  gitlab-com: true
+  available_in: [Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/compliance/compliance_center/#standards-adherence-dashboard'
+  image_url: 'https://about.gitlab.com/images/16_5/govern-compliance-standards-adherence-report.png'
+  published_at: 2023-10-22
+  release: 16.5
+- name: Create rules to set target branches for merge requests
+  description: | # Do not modify this line, instead modify the lines below.
+    Some projects use multiple long-term branches for development, like `develop` and `qa`. In these projects, you might want to keep `main` as the default branch since it represents the production state of the project. However, development work expects merge requests to target `develop` or `qa`. Target branch rules help ensure merge requests target the appropriate branch for your project and development workflow.
+
+    When you create a merge request, the rule checks the name of the branch. If the branch name matches the rule, the merge request pre-selects the branch you specified in the rule as the target. If the branch name does not match, the merge request targets the default branch of the project.
+  stage: create
+  self-managed: true
+  gitlab-com: true
+  available_in: [Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/project/repository/branches/#configure-rules-for-target-branches'
+  image_url: 'https://about.gitlab.com/images/16_5/create-target-branch-rules.png'
+  published_at: 2023-10-22
+  release: 16.5
+- name: Resolve an issue thread
+  description: | # Do not modify this line, instead modify the lines below.
+    Long-running issues with many threads can be challenging to read and track. You can now resolve a thread on an issue when the topic of discussion has concluded.
+  stage: plan
+  self-managed: true
+  gitlab-com: true
+  available_in: [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/discussions/#resolve-a-thread'
+  image_url: 'https://about.gitlab.com/images/16_5/resolve_functionality_for_issues.png'
+  published_at: 2023-10-22
+  release: 16.5
+- name: Fast-forward merge trains with semi-linear history
+  description: | # Do not modify this line, instead modify the lines below.
+    In 16.4, we released [Fast-forward merge trains](https://about.gitlab.com/releases/2023/09/22/gitlab-16-4-released/#fast-forward-merge-support-for-merge-trains), and as a continuation, we want to ensure we support all [merge methods](https://docs.gitlab.com/ee/user/project/merge_requests/methods/). Now, if you want to ensure your semi-linear commit history is maintained you can use Semi-linear fast-forward merge trains.
+  stage: verify
+  self-managed: true
+  gitlab-com: true
+  available_in: [Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/ci/pipelines/merge_trains.html'
+  image_url: 'https://about.gitlab.com/images/16_5/ff-merge.png'
+  published_at: 2023-10-22
+  release: 16.5

doc/administration/inactive_project_deletion.md

@@ -34,10 +34,13 @@ To configure deletion of inactive projects:
 1. Select **Save changes**.
 
 Inactive projects that meet the criteria are scheduled for deletion and a warning email is sent. If the
-projects remain inactive, they are deleted after the specified duration.
+projects remain inactive, they are deleted after the specified duration. These projects are deleted even if
+[the project is archived](../user/project/settings/index.md#archive-a-project).
 
 ### Configuration example
 
+#### Example 1
+
 If you use these settings:
 
 - **Delete inactive projects** enabled.
@@ -52,6 +55,20 @@ If a project is more than 50 MB and it is inactive for:
 - More than 6 months: A deletion warning email is sent. This mail includes the date that the project will be deleted.
 - More than 12 months: The project is scheduled for deletion.
 
+#### Example 2
+
+If you use these settings:
+
+- **Delete inactive projects** enabled.
+- **Delete inactive projects that exceed** set to `0`.
+- **Delete project after** set to `12`.
+- **Send warning email** set to `11`.
+
+If a project exists that has already been inactive for more than 12 months when you configure these settings:
+
+- A deletion warning email is sent immediately. This email includes the date that the project will be deleted.
+- The project is scheduled for deletion 1 month (12 months - 11 months) after warning email.
+
 ## Determine when a project was last active
 
 You can view a project's activities and determine when the project was last active in the following ways:

doc/development/documentation/styleguide/word_list.md

@@ -26,6 +26,15 @@ For guidance not on this page, we defer to these style guides:
 <!-- Disable trailing punctuation in heading rule https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md#md026---trailing-punctuation-in-heading -->
 <!-- markdownlint-disable MD026 -->
 
+## `.gitlab-ci.yml` file
+
+Use backticks and lowercase for **the `.gitlab-ci.yml` file**.
+
+When possible, use the full phrase: **the `.gitlab-ci.yml` file**
+
+Although users can specify another name for their CI/CD configuration file,
+in most cases, use **the `.gitlab-ci.yml` file** instead.
+
 ## `&`
 
 Do not use Latin abbreviations. Use **and** instead, unless you are documenting a UI element that uses an `&`.

doc/user/application_security/container_scanning/index.md

@@ -133,6 +133,10 @@ Setting `CS_DEFAULT_BRANCH_IMAGE` avoids duplicate vulnerability findings when a
 The value of `CS_DEFAULT_BRANCH_IMAGE` indicates the name of the scanned image as it appears on the default branch.
 For more details on how this deduplication is achieved, see [Setting the default branch image](#setting-the-default-branch-image).
 
+## Running jobs in merge request pipelines
+
+See [Use security scanning tools with merge request pipelines](../index.md#use-security-scanning-tools-with-merge-request-pipelines)
+
 ### Customizing the container scanning settings
 
 There may be cases where you want to customize how GitLab scans your containers. For example, you

doc/user/application_security/dependency_scanning/index.md

@@ -599,6 +599,10 @@ To enable dependency scanning:
 
 Pipelines now include a dependency scanning job.
 
+### Running jobs in merge request pipelines
+
+See [Use security scanning tools with merge request pipelines](../index.md#use-security-scanning-tools-with-merge-request-pipelines)
+
 ### Customizing analyzer behavior
 
 You can use CI/CD variables to customize dependency scanning behavior.

doc/user/application_security/index.md

@@ -177,6 +177,9 @@ By default, the application security jobs are configured to run for branch pipel
 To use them with [merge request pipelines](../../ci/pipelines/merge_request_pipelines.md),
 you must reference the [`latest` templates](../../development/cicd/templates.md).
 
+The latest version of the template may include breaking changes. Use the stable template unless you
+need a feature provided only in the latest template.
+
 All `latest` security templates support merge request pipelines.
 
 For example, to run both SAST and Dependency Scanning, the following template is used:
@@ -193,6 +196,9 @@ Mixing `latest` and `stable` security templates can cause both MR and branch pip
 NOTE:
 Latest templates can receive breaking changes in any release.
 
+For more information about template versioning, see the
+[CI/CD documentation](../../development/cicd/templates.md#latest-version).
+
 ## Default behavior of GitLab security scanning tools
 
 ### Secure jobs in your pipeline
@@ -264,6 +270,8 @@ In the Free tier, the reports above aren't parsed by GitLab. As a result, the wi
 
 A merge request contains a security widget which displays a summary of the _new_ results. New results are determined by comparing the findings of the merge request against the findings of the most recent completed pipeline (`success`, `failed`, `canceled` or `skipped`) for the commit when the feature branch was created from the target branch.
 
+If the `check_multiple_pipelines_for_security_reports` [feature flag is enabled](../../administration/feature_flags.md), GitLab checks the last 10 pipelines for the commit when the feature was created from the target branch to find one with security reports to use in comparison logic.
+
 If security scans have not run for the completed pipeline in the target branch when the feature branch was created, there is no base for comparison. The vulnerabilities from the merge request findings are listed as new in the merge request security widget. We recommend you run a scan of the `default` (target) branch before enabling feature branch scans for your developers.
 
 The merge request security widget displays only a subset of the vulnerabilities in the generated JSON artifact because it contains both new and existing findings.

doc/user/application_security/sast/index.md

@@ -273,6 +273,10 @@ When downloading, you always receive the most recent SAST artifact available.
 You can enable and configure SAST by using the UI, either with the default settings or with customizations.
 The method you can use depends on your GitLab license tier.
 
+### Running jobs in merge request pipelines
+
+See [Use security scanning tools with merge request pipelines](../index.md#use-security-scanning-tools-with-merge-request-pipelines)
+
 #### Configure SAST with customizations **(ULTIMATE ALL)**
 
 > [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/410013) individual SAST analyzers configuration options from the UI in GitLab 16.2.

doc/user/application_security/secret_detection/index.md

@@ -111,26 +111,13 @@ Secret Detection can detect if a secret was added in one commit and removed in a
 - Merge request
 
   In a merge request, Secret Detection scans every commit made on the source branch. To use this
-  feature, you must use the [`latest` Secret Detection template](#templates), as it supports
+  feature, you must use the [`latest` Secret Detection template](../index.md#use-security-scanning-tools-with-merge-request-pipelines), as it supports
   [merge request pipelines](../../../ci/pipelines/merge_request_pipelines.md). Secret Detection's
   results are only available after the pipeline is completed.
 
-## Templates
+## Running jobs in merge request pipelines
 
-Secret Detection default configuration is defined in CI/CD templates. Updates to the template are
-provided with GitLab upgrades, allowing you to benefit from any improvements and additions.
-
-Available templates:
-
-- [`Secret-Detection.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.gitlab-ci.yml): Stable, default version of the Secret Detection CI/CD template.
-- [`Secret-Detection.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Jobs/Secret-Detection.latest.gitlab-ci.yml): Latest version of the Secret Detection template.
-
-WARNING:
-The latest version of the template may include breaking changes. Use the stable template unless you
-need a feature provided only in the latest template.
-
-For more information about template versioning, see the
-[CI/CD documentation](../../../development/cicd/templates.md#latest-version).
+See [Use security scanning tools with merge request pipelines](../index.md#use-security-scanning-tools-with-merge-request-pipelines)
 
 ## Enable Secret Detection
 

doc/user/group/import/index.md

@@ -337,7 +337,7 @@ Project items that are migrated to the destination GitLab instance include:
 | Projects                                | [GitLab 14.4](https://gitlab.com/gitlab-org/gitlab/-/issues/267945)        |
 | Auto DevOps                             | [GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/339410)        |
 | Badges                                  | [GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75029) |
-| Branches (including protected branches) | [GitLab 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/339414)        |
+| Branches (including protected branches) <sup>1</sup> | [GitLab 14.7](https://gitlab.com/gitlab-org/gitlab/-/issues/339414) |
 | CI Pipelines                            | [GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/339407)        |
 | Commit comments                         | [GitLab 15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/391601)       |
 | Designs                                 | [GitLab 15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/339421)        |
@@ -361,6 +361,14 @@ Project items that are migrated to the destination GitLab instance include:
 | Uploads                                 | [GitLab 14.5](https://gitlab.com/gitlab-org/gitlab/-/issues/339401)        |
 | Wikis                                   | [GitLab 14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/345923)        |
 
+<html>
+<small>Footnotes:
+  <ol>
+    <li>Imported branches respect the [default branch protection settings](../../project/protected_branches.md) of the destination group, which can cause an unprotected branch to be imported as protected.</li>
+  </ol>
+</small>
+</html>
+
 #### Issue-related items
 
 Issue-related project items that are migrated to the destination GitLab instance include:

qa/qa/specs/features/api/1_manage/import/import_large_github_repo_spec.rb

@@ -253,7 +253,6 @@ module QA
             }
           },
           target: {
-            project_name: imported_project.path_with_namespace,
             data: {
               branches: gl_branches.length,
               commits: gl_commits.length,
@@ -333,7 +332,8 @@ module QA
           },
           target: {
             name: "GitLab",
-            address: gitlab_address
+            address: gitlab_address,
+            project_name: imported_project.full_path
           }
         }.deep_merge(additional_data)
       end