Add latest changes from gitlab-org/gitlab@master

Author: GitLab Bot

app/controllers/jwt_controller.rb

@@ -65,8 +65,8 @@ def log_authentication_failed(login, result)
 
   def render_access_denied
     help_page = help_page_url(
-      'user/profile/account/two_factor_authentication.md',
-      anchor: 'troubleshooting'
+      'user/profile/account/two_factor_authentication_troubleshooting.md',
+      anchor: 'error-http-basic-access-denied-if-a-password-was-provided-for-git-authentication-'
     )
 
     render(

doc/development/integrations/secure.md

@@ -99,16 +99,16 @@ it's declared under the `reports:sast` key in the job definition, not because of
 
 ### Policies
 
-Certain GitLab workflows, such as [AutoDevOps](../../topics/autodevops/cicd_variables.md#job-disabling-variables),
-define CI/CD variables to indicate that given scans should be disabled. You can check for this by looking
+Certain GitLab workflows, such as [AutoDevOps](../../topics/autodevops/cicd_variables.md#job-skipping-variables),
+define CI/CD variables to indicate that given scans should be skipped. You can check for this by looking
 for variables such as:
 
 - `DEPENDENCY_SCANNING_DISABLED`
 - `CONTAINER_SCANNING_DISABLED`
 - `SAST_DISABLED`
 - `DAST_DISABLED`
 
-If appropriate based on the scanner type, you should then disable running the custom scanner.
+If appropriate based on the scanner type, you should then skip running the custom scanner.
 
 GitLab also defines a `CI_PROJECT_REPOSITORY_LANGUAGES` variable, which provides the list of
 languages in the repository. Depending on this value, your scanner may or may not do something different.

doc/development/windows.md

@@ -1,140 +1,13 @@
 ---
-stage: none
-group: unassigned
-info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
+redirect_to: 'index.md'
+remove_date: '2025-01-31'
 ---
 
-# Windows Development
+<!-- markdownlint-disable -->
 
-There are times in development where a Windows development machine is needed.
-This is a guide for how to get a Windows development virtual machine on Google Cloud Platform
-(GCP) with the same preinstalled tools as the GitLab shared Windows runners.
+This document was moved to [another location](index.md).
 
-## Why Windows in Google Cloud?
-
-Use of Microsoft Windows operating systems on company laptops is banned under the GitLab [Approved Operating Systems policy](https://internal.gitlab.com/handbook/it/it-self-service/operating-systems/).
-
-This can make it difficult to develop features for the Windows platforms. Using GCP allows us to have a temporary Windows machine that can be removed once we're done with it.
-
-## Shared Windows runners
-
-You can use the shared Windows runners in the case that you don't need a full Windows development machine.
-The [GitLab 12.7 Release Post](https://about.gitlab.com/releases/2020/01/22/gitlab-12-7-released/#windows-shared-runners-on-gitlabcom-beta)
-and [Windows shared runner beta blog post](https://about.gitlab.com/blog/2020/01/21/windows-shared-runner-beta/#getting-started) both
-outline quite a bit of useful information.
-
-To use the shared Windows runners add the following `tags` to relevant jobs in your `.gitlab-ci.yml` file:
-
-```yaml
-tags:
-  - shared-windows
-  - windows
-  - windows-1809
-```
-
-A list of software preinstalled on the Windows images is available at: [Preinstalled software](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/main/cookbooks/preinstalled-software/README.md).
-
-## GCP Windows image for development
-
-The [shared Windows GitLab runners](https://about.gitlab.com/releases/2020/01/22/gitlab-12-7-released/#windows-shared-runners-on-gitlabcom-beta)
-are built with [Packer](https://www.packer.io/).
-
-The Infrastructure as Code repository for building the Google Cloud images is available at:
-[GitLab Google Cloud Platform Shared Runner Images](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers).
-
-### Build image
-
-There is a chance that your Google Cloud group may already have an image
-built. Search the available images before you do the work to build your
-own.
-
-Build a Google Cloud image with the above shared runners repository by doing the following:
-
-1. Install [Packer](https://www.packer.io/) (tested to work with version 1.5.1).
-1. Install Packer Windows Update Provisioner.
-   1. Clone the repository <https://github.com/rgl/packer-provisioner-windows-update> and `cd` into the cloned directory.
-   1. Run the command `go build -o packer-provisioner-windows-update` (requires `go` to be installed).
-   1. Verify `packer-provisioner-windows-update` is in the `PATH` environment variable.
-1. Add all [required environment variables](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/-/blob/main/packer.json#L2-10)
-   in the `packer.json` file to your environment (perhaps use [`direnv`](https://direnv.net/)).
-1. Build the image by running the command: `packer build packer.json`.
-
-## How to use a Windows image in GCP
-
-1. In a web browser, go to the [Google Cloud Platform console](https://console.cloud.google.com/compute/images).
-1. Filter images by the name you used when creating image, `windows` is likely all you need to filter by.
-1. Select the image's name.
-1. Select **CREATE INSTANCE**.
-1. Important: Change name to what you'd like as you can't change it later.
-1. Optional: Change Region to be closest to you as well as any other option you'd like.
-1. Select **Create** at the bottom of the page.
-1. Select the name of your newly created VM Instance (optionally you can filter to find it).
-1. Select **Set Windows password**.
-1. Optional: Set a username or use default.
-1. Select **Next**.
-1. Copy and save the password as it is not shown again.
-1. Select **RDP** down arrow.
-1. Select **Download the RDP file**.
-1. Open the downloaded RDP file with the Windows remote desktop app (<https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-clients>).
-1. Select **Continue** to accept the certificate.
-1. Enter the password and select **Next**.
-
-You should now be connected into a Windows machine with a command prompt.
-
-### Optional: Use GCP VM Instance as a runner
-
-- Register the runner with a project: `gitlab-runner.exe register`.
-- Install the runner:`gitlab-runner.exe install`.
-- Start the runner: `gitlab-runner.exe start`.
-
-For more information, see [Install GitLab Runner on Windows](https://docs.gitlab.com/runner/install/windows.html)
-and [Registering runners](https://docs.gitlab.com/runner/register/index.html).
-
-## Developer tips
-
-Here are a few tips on GCP and Windows.
-
-### GCP cost savings
-
-To minimize the cost of your GCP VM instance, stop it when you're not using it.
-If you do, you must download the RDP file again from the console as the IP
-address changes every time you stop and start it.
-
-### chocolatey
-
-Chocolatey is a package manager for Windows. You can search for packages on <https://chocolatey.org/>.
-
-- `choco install vim`
-
-### Visual Studio (install / usage for full GUI)
-
-You can install Visual Studio and run it within the Windows Remote Desktop app.
-
-Install it by running: `choco install visualstudio2019community`
-
-Start it by running: `"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe" .`
-
-### .NET 3 support
-
-You can install .NET version 3 support with the following `DISM` command:
-
-`DISM /Online /Enable-Feature /FeatureName:NetFx3 /All`
-
-### nix -> Windows `cmd` tips
-
-The first tip for using the Windows command shell is to open PowerShell and use that instead.
-
-Start PowerShell: `start powershell`.
-
-PowerShell has aliases for all of the following commands so you don't have to learn the native commands:
-
-- `ls` ---> `dir`
-- `rm` ---> `del`
-- `rm -rf nonemptydir` ---> `rmdir /S nonemptydir`
-- `/` ---> <code>&#92;</code> (path separator)
-- `cat` ---> `type`
-- `mv` ---> `move`
-- Redirection works the same (for example, `>` and `2>&1`)
-- `.\some.exe` to call a local executable
-- curl is available
-- `..` and `.` are available
+<!-- This redirect file can be deleted after <2025-01-31>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->

doc/topics/autodevops/cicd_variables.md

@@ -87,9 +87,9 @@ Use these variables to integrate CI/CD with PostgreSQL databases.
 | `POSTGRES_CHART_REPOSITORY`             | Helm Chart repository used to search for PostgreSQL chart. Defaults to `https://raw.githubusercontent.com/bitnami/charts/eb5f9a9513d987b519f0ecd732e7031241c50328/bitnami`. |
 | `POSTGRES_CHART_VERSION`                | Helm Chart version used for PostgreSQL chart. Defaults to `8.2.1`. |
 
-## Job-disabling variables
+## Job-skipping variables
 
-Use these variables to disable CI/CD jobs.
+ Use these variables to skip specific types of CI/CD jobs. When skipped, the CI/CD jobs don't get created or run.
 
 | **Job name**                           | **CI/CD variable**              | **GitLab version**    | **Description** |
 |----------------------------------------|---------------------------------|-----------------------|-----------------|

doc/topics/autodevops/customize.md

@@ -113,7 +113,7 @@ You can override this behavior by defining specific variables:
 
 These variables also affect Auto Build and Auto Container Scanning. If you don't want to build and push an image to
 `$CI_APPLICATION_REPOSITORY:$CI_APPLICATION_TAG`, include only `Jobs/Deploy.gitlab-ci.yml`, or
-[disable the `build` jobs](cicd_variables.md#job-disabling-variables).
+[skip the `build` jobs](cicd_variables.md#job-skipping-variables).
 
 If you use Auto Container Scanning and set a value for `$CI_APPLICATION_REPOSITORY`, then you should
 also update `$CS_DEFAULT_BRANCH_IMAGE`. For more information, see

doc/topics/autodevops/stages.md

@@ -291,15 +291,15 @@ to set `DAST_WEBSITE` to any staging or production environment. DAST Full Scan
 actively attacks the target, which can take down your application and lead to
 data loss or corruption.
 
-### Disabling Auto DAST
+### Skipping Auto DAST
 
-You can disable DAST:
+You can skip DAST jobs:
 
 - On all branches by setting the `DAST_DISABLED` CI/CD variable to `"true"`.
 - Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH`
   variable to `"true"`.
 - Only on feature branches by setting `REVIEW_DISABLED` variable to
-  `"true"`. This also disables the Review App.
+  `"true"`. This also skips the Review App.
 
 ## Auto Browser Performance Testing
 
@@ -525,4 +525,4 @@ for updates.
 
 This stage is enabled by default. You can disable it by adding the
 `CODE_INTELLIGENCE_DISABLED` CI/CD variable. Read more about
-[disabling Auto DevOps jobs](../../topics/autodevops/cicd_variables.md#job-disabling-variables).
+[disabling Auto DevOps jobs](../../topics/autodevops/cicd_variables.md#job-skipping-variables).

doc/user/application_security/policies/scan_execution_policies.md

@@ -26,7 +26,7 @@ Scan execution policies are enforced across all projects that are linked to the
 static analysis, or other scanners that do not require a build in the project, are still able to
 run and be enforced.
 
-Scan execution policies, compared to pipeline execution policies, provide a faster path to configure GitLab security scans across multiple projects to manage security and compliance. 
+Scan execution policies, compared to pipeline execution policies, provide a faster path to configure GitLab security scans across multiple projects to manage security and compliance.
 
 If any of the following cases are true, use [pipeline execution policies](pipeline_execution_policies.md) instead:
 
@@ -430,4 +430,4 @@ To skip scan jobs with variables, you can use:
 - `SECRET_DETECTION_DISABLED: "true"` to skip secret detection jobs.
 - `DEPENDENCY_SCANNING_DISABLED: "true"` to skip dependency scanning jobs.
 
-For an overview of all variables that can skip jobs, see [CI/CD variables documentation](../../../topics/autodevops/cicd_variables.md#job-disabling-variables)
+For an overview of all variables that can skip jobs, see [CI/CD variables documentation](../../../topics/autodevops/cicd_variables.md#job-skipping-variables)

doc/user/duo_workflow/index.md

@@ -54,16 +54,16 @@ Before you can use GitLab Duo Workflow:
 
 ### Install Docker and set the socket file path
 
-GitLab Duo Workflow needs an execution platform where it can execute arbitrary code,
+GitLab Duo Workflow needs an execution platform like Docker where it can execute arbitrary code,
 read and write files, and make API calls to GitLab.
 
 #### Automated setup
 
-Installs Docker, Colima, and sets Docker socket path in VS Code settings.
+The setup script installs Docker and Colima, pulls the Docker base image, and sets Docker socket path in VS Code settings.
 You can run the script with the `--dry-run` flag to check the dependencies
 that get installed with the script.
 
-1. Download the [script](https://gitlab.com/-/snippets/3745948).
+1. Download the [setup script](https://gitlab.com/-/snippets/3745948).
 1. Run the script.
 
    ```shell
@@ -73,27 +73,34 @@ that get installed with the script.
 
 #### Manual setup
 
-Sets socket path if you have
-[Docker or Docker alternatives](https://handbook.gitlab.com/handbook/tools-and-tips/mac/#docker-desktop)
-installed already.
+If you have [Docker Desktop](https://handbook.gitlab.com/handbook/tools-and-tips/mac/#docker-desktop)
+or a container manager other than Colima installed already:
 
-1. Open VS Code, then open its settings:
-   - On Mac: <kbd>Cmd</kbd> + <kbd>,</kbd>
-   - On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
-1. In the upper-right corner, select the **Open Settings (JSON)** icon.
-1. Ensure the Docker socket settings are configured. If not, add this line to your settings file and save it:
+1. Pull the base Docker image:
+   
+   ```shell
+   docker pull registry.gitlab.com/gitlab-org/duo-workflow/default-docker-image/workflow-generic-image:v0.0.4
+   ```
+
+1. Set the Docker socket path in VS Code:
+   1. Open VS Code, then open its settings:
+      - On Mac: <kbd>Cmd</kbd> + <kbd>,</kbd>
+      - On Windows and Linux: <kbd>Ctrl</kbd> + <kbd>,</kbd>
+   1. In the upper-right corner, select the **Open Settings (JSON)** icon.
+   1. Add the Docker socket path setting `gitlab.duoWorkflow.dockerSocket`, according to your container manager, and save your settings file.
+   Some examples for common container managers on macOS, where you would replace `<your_user>` with your user's home folder:
 
-   - For Rancher Desktop
+      - Rancher Desktop:
 
-     ```json
-     "gitlab.duoWorkflow.dockerSocket": "${userHome}/.rd/docker.sock",
-     ```
+         ```json
+         "gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.rd/docker.sock",
+         ```
 
-   - For Colima
+      - Colima:
 
-     ```json
-     "gitlab.duoWorkflow.dockerSocket": "${userHome}/.colima/default/docker.sock",
-     ```
+         ```json
+         "gitlab.duoWorkflow.dockerSocket": "/Users/<your_user>/.colima/default/docker.sock",
+         ```
 
 ## Use GitLab Duo Workflow in VS Code
 
@@ -135,8 +142,8 @@ If you encounter issues:
 1. Check that your open folder in VS Code corresponds to the GitLab project you want to interact with.
 1. Ensure that you've checked out the branch as well.
 1. Check your Docker and Docker socket configuration:
-   1. Try [manual](#manual-setup) Docker socket configuration.
-   1. If using Colima and encountering issues, try restarting it:
+   1. [Install Docker and set the socket file path](#install-docker-and-set-the-socket-file-path).
+   1. Restart your container manager. For example, if using Colima:
 
       ```shell
       colima stop

spec/requests/jwt_controller_spec.rb

@@ -46,7 +46,7 @@
         {
           "errors" => [{
             "code" => "UNAUTHORIZED",
-            "message" => "HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See http://www.example.com/help/user/profile/account/two_factor_authentication.md#troubleshooting"
+            "message" => "HTTP Basic: Access denied. If a password was provided for Git authentication, the password was incorrect or you're required to use a token instead of a password. If a token was provided, it was either incorrect, expired, or improperly scoped. See http://www.example.com/help/user/profile/account/two_factor_authentication_troubleshooting.md#error-http-basic-access-denied-if-a-password-was-provided-for-git-authentication-"
           }]
         }
       )