Add latest changes from gitlab-org/gitlab@master

doc/ci/variables/_index.md

@@ -52,6 +52,49 @@ job1:
 
 The script in this example outputs `The job's stage is 'test'`.
 
+## CI/CD configuration variables
+
+GitLab CI/CD also makes configuration CI/CD variables available for use in pipeline configuration and job scripts.
+You can use GitLab CI/CD configuration variables in pipeline configuration and job scripts to configure runner
+and the job execution environment.
+
+You cannot directly define configuration variables in a `.gitlab-ci.yml` file.
+Runner administrators can define these variables indirectly as settings in a
+[`.config.toml`](https://docs.gitlab.com/runner/configuration/advanced-configuration/) file.
+
+For example, when you configure TLS certificate settings for HTTPS communication:
+
+```toml
+[[runners]]
+  name = "gl-docker-runner"
+  url = "https://gitlab.com/example/url"
+  token = "user-token"
+  executor = "docker"
+
+  tls-ca-file = "/example/gl-runner/certs/ca.crt"
+  tls-cert-file = "/example/gl-runner/certs/cert.crt"
+  tls-key-file = "/example/gl-runner/certs/key.key"
+```
+
+The primary purpose of the `tls-ca-file` setting is to specify the certificate authority file for HTTPS verification.
+As a byproduct of this configuration, GitLab Runner automatically creates the `CI_SERVER_TLS_CA_FILE` configuration variable,
+which becomes available to your CI/CD jobs.
+
+Configuration variables are only available under certain conditions.
+For example, the configuration variable `CI_SERVER_TLS_CA_FILE` (which configures the custom
+Certificate Authority file) is only available when:
+
+- You configure it in the `config.toml` file by using the `tls-ca-file` setting.
+- The job instance uses HTTPS, which prompts the runner to automatically build a CA verification chain.
+
+To summarize, the following are the differences between predefined and configuration variables:
+
+|                | Predefined variables     | Configuration variables                            |
+|----------------|--------------------------|----------------------------------------------------|
+| Purpose        | Supports script logic    | Configure runner and the job execution environment |
+| Availability   | Always available         | Available only under specific conditions           |
+| Defined by     | Users in`.gitlab-ci.yml` | Administrators in `config.toml`                    |
+
 ## Define a CI/CD variable in the `.gitlab-ci.yml` file
 
 To create a CI/CD variable in the `.gitlab-ci.yml` file, define the variable and

doc/install/openshift_and_gitlab/_index.md

@@ -39,6 +39,3 @@ For Auto DevOps, the following features are not supported yet:
 - Auto Browser Performance Testing
 - Auto Build
 - [Operational Container Scanning](../../user/clusters/agent/vulnerabilities.md) (Note: Pipeline [Container Scanning](../../user/application_security/container_scanning/_index.md) is supported)
-
-For Auto Build, there's a [possible workaround using `kaniko`](../../ci/docker/using_kaniko.md).
-You can check the progress of the implementation in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/332560).

doc/tutorials/container_scanning/_index.md

@@ -58,8 +58,7 @@ Now you're ready to create pipeline configuration. The pipeline configuration:
 
 1. Builds a Docker image from the `Dockerfile` file, and pushes the Docker image to the container registry. The
    `build-image` job uses [Docker-in-Docker](../../ci/docker/using_docker_build.md) as a
-   [CI/CD service](../../ci/services/_index.md) to build the Docker image. You can also
-   [use kaniko](../../ci/docker/using_kaniko.md) to build Docker images in a pipeline.
+   [CI/CD service](../../ci/services/_index.md) to build the Docker image.
 1. Includes the `Container-Scanning.gitlab-ci.yml` template, to scan the Docker image stored in the container registry.
 
 To create the pipeline configuration:

doc/user/packages/container_registry/troubleshoot_container_registry.md

@@ -113,15 +113,6 @@ You might receive a [`Failed to pull image'](../../../ci/debugging.md#failed-to-
 error message when a CI/CD job is unable to pull a container image from a project with a limited
 [CI/CD job token scope](../../../ci/jobs/ci_job_token.md#limit-job-token-scope-for-public-or-internal-projects).
 
-## Slow uploads when using `kaniko` to push large images
-
-When you push large images with `kaniko`, you might experience uncharacteristically long delays.
-
-This is typically a result of [a performance issue with `kaniko` and HTTP/2](https://github.com/GoogleContainerTools/kaniko/issues/2751).
-The current workaround is to use HTTP/1.1 when pushing with `kaniko`.
-
-To use HTTP/1.1, set the `GODEBUG` environment variable to `"http2client=0"`.
-
 ## `OCI manifest found, but accept header does not support OCI manifests` error
 
 If you are unable to pull an image, the registry logs could have an error similar to:

doc/user/project/integrations/harbor.md

@@ -63,29 +63,7 @@ Malicious code pushed to your `.gitlab-ci.yml` file could compromise your variab
 `$HARBOR_PASSWORD`, and send them to a third-party server. For more details, see
 [CI/CD variable security](../../../ci/variables/_index.md#cicd-variable-security).
 
-## Examples of Harbor variables in CI/CD
-
-### Push a Docker image with kaniko
-
-For more information, see [Use kaniko to build Docker images](../../../ci/docker/using_kaniko.md).
-
-```yaml
-docker:
-  stage: docker
-  image:
-    name: gcr.io/kaniko-project/executor:debug
-    entrypoint: ['']
-  script:
-    - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"${HARBOR_HOST}\":{\"auth\":\"$(echo -n ${HARBOR_USERNAME}:${HARBOR_PASSWORD} | base64 -w 0)\"}}}" > /kaniko/.docker/config.json
-    - >-
-      /kaniko/executor
-      --context "${CI_PROJECT_DIR}"
-      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
-      --destination "${HARBOR_HOST}/${HARBOR_PROJECT}/${CI_PROJECT_NAME}:${CI_COMMIT_TAG}"
-  rules:
-  - if: $CI_COMMIT_TAG
-```
+## Use Harbor variables
 
 ### Push a Helm chart with an OCI registry