root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2024-05-08 09:20:14 +00:00
parent bdd869172a
commit 647787a4d4
23 changed files with 240 additions and 229 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitlab/merge_request_templates/Deprecations.md
View File

@ -42,6 +42,7 @@ They are frequently updated, and everyone should make sure they are aware of the
- [ ] Add reviewers by the 10th.
- [ ] Add scoped `devops::` and `group::` labels as necessary.
- [ ] Add the appropriate milestone to this MR.
- [ ] If the changes modify log format(addition/deletion/modification) of product feature, tag `@gitlab-com/gl-security/engineering-and-research/security-logging` team over the GitLab issue/MR.
- [ ] When ready to be merged (and no later than the 15th) `@mention` the TW for final review and merge.
## Reviewers

2
app/views/groups/labels/new.html.haml
View File

@ -1,5 +1,5 @@
- add_to_breadcrumbs _("Labels"), group_labels_path(@group)
- breadcrumb_title _("New")
- breadcrumb_title _("New label")
- page_title _("New Label")
%h1.page-title.gl-font-size-h-display

2
app/views/groups/milestones/new.html.haml
View File

@ -1,5 +1,5 @@
- add_to_breadcrumbs _("Milestones"), group_milestones_path(@group)
- breadcrumb_title _("New")
- breadcrumb_title _("New milestone")
- page_title _("Milestones"), @milestone.name, _("Milestones")
%h1.page-title.gl-font-size-h-display

10
doc/administration/postgresql/multiple_databases.md
View File

@ -20,7 +20,7 @@ By default, GitLab uses a single application database, referred to as the `main`
To scale GitLab, you can configure GitLab to use multiple application databases.
Due to [known issues](#known-issues), configuring GitLab with multiple databases is an [Experiment](../../policy/experiment-beta-support.md#experiment).
Due to [known issues](#known-issues), configuring GitLab with multiple databases is in limited [Beta](../../policy/experiment-beta-support.md#beta).
After you have set up multiple databases, GitLab uses a second application database for
[CI/CD features](../../ci/index.md), referred to as the `ci` database. We do not exclude hosting both databases on a single PostgreSQL instance.
@ -40,17 +40,17 @@ databases. Some examples:
## Known issues
- Once data is migrated to the `ci` database, you cannot migrate it back.
- HA setups or PgBouncer setups are not yet supported by this procedure.
- Significant downtime is expected for larger installations (database sizes of more 100 GB).
## Migrate existing installations using a script
> - A script for migrating existing Linux package installations was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/368729) in GitLab 16.8.
NOTE:
If something unexpected happens during the migration, it is safe to start over.
### Existing Linux package installations
This migration requires downtime.
If something unexpected happens during the migration, it is safe to start over.
#### Preparation
1. Verify available disk space:

2
doc/architecture/blueprints/cells/goals.md
View File

@ -128,7 +128,7 @@ Currently on-premise has numerous advantages compared to our SaaS offering.
On-premise allows to control all aspects of a GitLab installation, including but not limited to: managing users, access controls, or instance-wide settings.
The difference between SaaS and on-premise is problematic for our customers,
and us as it results in a different user experience.
as it results in a different user experience.
### Minimize breaking changes

20
doc/architecture/blueprints/cells/impacted_features/ci-runners.md
View File

@ -3,7 +3,6 @@ stage: enablement
group: Tenant Scale
description: 'Cells: CI Runners'
---
<!-- vale gitlab.FutureTense = NO -->
This document is a work-in-progress and represents a very early state of the
@ -48,7 +47,7 @@ Currently three types of authentication tokens are used:
- Runner token representing a registered runner in a system with specific configuration (`tags`, `locked`, etc.)
- Build token representing an ephemeral token giving limited access to updating a specific job, uploading artifacts, downloading dependent artifacts, downloading and uploading container registry images
Each of those endpoints receive an authentication token via header (`JOB-TOKEN` for `/trace`) or body parameter (`token` all other endpoints).
Each of those endpoints receive an authentication token via header (`JOB-TOKEN` for `/trace`, `token` all other endpoints).
Since the CI pipeline would be created in the context of a specific Cell, it would be required that pick of a build would have to be processed by that particular Cell.
This requires that build picking depending on a solution would have to be either:
@ -65,7 +64,7 @@ Even though the paths for CI runners are not routable, they can be made routable
- The `https://gitlab.com/api/v4/jobs/request` uses a long polling mechanism with
a ticketing mechanism (based on `X-GitLab-Last-Update` header). When the runner first
starts, it sends a request to GitLab to which GitLab responds with either a build to pick
by runner. This value is completely controlled by GitLab. This allows GitLab
by runner, or a `204 No job` with a `last_update` token. This value is completely controlled by GitLab. This allows GitLab
to use JWT or any other means to encode a `cell` identifier that could be easily
decodable by Router.
- The majority of communication (in terms of volume) is using `build token`, making it
@ -76,9 +75,14 @@ Even though the paths for CI runners are not routable, they can be made routable
### 3.2. Request body
- The most used endpoints pass the authentication token in the request body. It might be desired
to use HTTP headers as an easier way to access this information by Router without
a need to proxy requests.
This statement is no longer true:
> _The most used endpoints pass the authentication token in the request body._
> _It might be desired to use HTTP headers as an easier way to access this information_
> _by Router without a need to proxy requests._
The runner now sends the token in the HTTP headers in all requests with the
[`Add runner token to header` MR merged](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/4643).
### 3.3. Instance-wide are Cell-local
@ -119,8 +123,8 @@ There were prior discussions about [CI/CD Daemon](https://gitlab.com/gitlab-org/
If the service is sharded:
- Depending on the model, if runners are cluster-wide or Cell-local, this service would have to fetch data from all Cells.
- If the sharded service is used we could adapt a model of sharing a database containing `ci_pending_builds/ci_running_builds` with the service.
- If the sharded service is used we could consider a push model where each Cell pushes to CI/CD Daemon builds that should be picked by runner.
- We could adapt a model of sharing a database containing `ci_pending_builds/ci_running_builds` with the service.
- We could consider a push model where each Cell pushes to CI/CD Daemon builds that should be picked by runner.
- The sharded service would be aware which Cell is responsible for processing the given build and could route processing requests to the designated Cell.
If the service is Cell-ed:

2
doc/ci/jobs/ci_job_token.md
View File

@ -19,7 +19,7 @@ Use a CI/CD job token to authenticate with certain GitLab features from running
The token receives the same access level as the user that triggered the pipeline,
but has access to fewer resources than a personal access token. A user can cause a job to run
with an action like pushing a commit, triggering a manual job, or being the owner of a scheduled pipeline.
This user must be have a [role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions)
This user must have a [role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions)
to access the resources.
You can use a job token to authenticate with GitLab to access another project's resources (the target project).

58
doc/ci/runners/hosted_runners/linux.md
View File

@ -10,46 +10,35 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab.com
When you run jobs on hosted runners on Linux, the runners are on auto-scaled ephemeral virtual machine (VM) instances.
The default region for the VMs is `us-east1`.
Hosted runners on Linux for GitLab.com run on Google Cloud Compute Engine. Each job gets a fully isolated, ephemeral virtual machine (VM). The default region is `us-east1`.
Each VM uses the Google Container-Optimized OS (COS) and the latest version of Docker Engine running the `docker+machine`
[executor](https://docs.gitlab.com/runner/executors/#docker-machine-executor).
The machine type and underlying processor type might change. Jobs optimized for a specific processor design might behave inconsistently.
[Untagged](../../yaml/index.md#tags) jobs will run on the `small` Linux x86-64 runner.
## Machine types available for Linux - x86-64
GitLab offers a range of machine types for hosted runners on Linux.
For Free, Premium, and Ultimate plan customers, jobs on these instances consume the compute quota allocated to your namespace.
GitLab offers the following machine types for hosted runners on Linux x86-64.
| Runner Tag | vCPUs | Memory | Storage |
|--------------------------------------------------------|-------|--------|---------|
| `saas-linux-small-amd64` | 2 | 8 GB | 25 GB |
| `saas-linux-small-amd64` (default) | 2 | 8 GB | 25 GB |
| `saas-linux-medium-amd64` | 4 | 16 GB | 50 GB |
| `saas-linux-large-amd64` (Premium and Ultimate only) | 8 | 32 GB | 100 GB |
| `saas-linux-xlarge-amd64` (Premium and Ultimate only) | 16 | 64 GB | 200 GB |
| `saas-linux-2xlarge-amd64` (Premium and Ultimate only) | 32 | 128 GB | 200 GB |
The `small` machine type is set as default. If no [tag](../../yaml/index.md#tags) keyword in your `.gitlab-ci.yml` file is specified,
the jobs will run on this default runner.
There are [different rates of compute minutes consumption](../../pipelines/cicd_minutes.md#gitlab-hosted-runner-costs), based on the type of machine that is used.
Hosted runners on Linux x86-64 currently run on the
[`n2d-standard`](https://cloud.google.com/compute/docs/general-purpose-machines#n2d_machines) general-purpose compute from Google Cloud.
The machine type and underlying processor type might change. Jobs optimized for a specific processor design might behave inconsistently.
## Machine types available for Linux - Arm64
GitLab offers the following machine type for hosted runners on Linux Arm.
GitLab offers the following machine type for hosted runners on Linux Arm64.
| Runner Tag | vCPUs | Memory | Storage |
|-------------------------------------------------------|-------|--------|---------|
| `saas-linux-medium-arm64` (Premium and Ultimate only) | 4 | 16 GB | 50 GB |
| `saas-linux-large-arm64` (Premium and Ultimate only) | 8 | 32 GB | 100 GB |
Hosted runners on Linux Arm run onthe [`t2a-standard`](https://cloud.google.com/compute/docs/general-purpose-machines#t2a_machine_types) general-purpose compute from Google Cloud.
The machine type and underlying processor type can change. Jobs optimized for a specific processor design could behave inconsistently.
## Container images
As runners on Linux are using the `docker+machine` [executor](https://docs.gitlab.com/runner/executors/#docker-machine-executor),
@ -64,15 +53,6 @@ The runners are configured to run in `privileged` mode to support
[Docker in Docker](../../../ci/docker/using_docker_build.md#use-docker-in-docker)
to build Docker images natively or run multiple containers within your isolated job.
## Caching on hosted runners
The hosted runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching)
stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically
removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive.
For more information about how caching works, see [Caching in GitLab CI/CD](../../caching/index.md).
## Example `.gitlab-ci.yml` file
To use a machine type other than `small`, add a `tags:` keyword to your job.
@ -81,33 +61,27 @@ For example:
```yaml
job_small:
script:
- echo "this job runs on the default (small) Linux instance"
- echo "This job is untagged and runs on the default small Linux x86-64 instance"
job_medium:
tags:
- saas-linux-medium-amd64
script:
- echo "this job runs on the medium Linux instance"
- echo "This job runs on the medium Linux x86-64 instance"
job_large:
tags:
- saas-linux-large-amd64
- saas-linux-large-arm64
script:
- echo "this job runs on the large Linux instance"
- echo "This job runs on the large Linux Arm64 instance"
```
## Hosted runners for GitLab community contributions
<!--- start_remove The following content will be removed on remove_date: '2024-08-17' -->
If you want to [contribute to GitLab](https://about.gitlab.com/community/contribute/), jobs will be picked up by the
`gitlab-shared-runners-manager-X.gitlab.com` fleet of runners, dedicated for GitLab projects and related community forks.
These runners are backed by the same machine type as our `small` runners.
Unlike the most commonly used hosted runners on Linux, each virtual machine is re-used up to 40 times.
As we want to encourage people to contribute, these runners are free of charge.
## Pre-clone script (deprecated)
## Pre-clone script (removed)
This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/391896) in GitLab 15.9
and [will be removed](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29405) in 17.0.
and [removed](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29405) in 17.0.
Use [`pre_get_sources_script`](../../../ci/yaml/index.md#hookspre_get_sources_script) instead.
<!--- end_remove -->

18
doc/ci/runners/hosted_runners/macos.md
View File

@ -11,22 +11,16 @@ DETAILS:
**Offering:** GitLab.com
**Status:** Beta
Hosted runners on macOS are in [Beta](../../../policy/experiment-beta-support.md#beta) for open source programs and customers in Premium and Ultimate plans.
Hosted runners on macOS provide an on-demand macOS environment, fully integrated with GitLab [CI/CD](../../../ci/index.md).
You can use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, watchOS, tvOS).
Our [Mobile DevOps section](../../../ci/mobile_devops.md#ios-build-environments) provides features, documentation, and guidance on building and deploying mobile applications for iOS.
Hosted runners on macOS provide an on-demand macOS build environment integrated with
GitLab.com [CI/CD](../../../ci/index.md).
Use these runners to build, test, and deploy apps for the Apple ecosystem (macOS, iOS, watchOS, tvOS). You can take advantage
of all the capabilities of the GitLab single DevOps platform and not have to manage or operate a
build environment. Our [Mobile DevOps solution](../../../ci/mobile_devops.md#ios-build-environments) provides features, documentation, and guidance on building and deploying mobile applications for iOS.
We want to keep iterating to get hosted runners on macOS
[generally available](../../../policy/experiment-beta-support.md#generally-available-ga).
You can follow our work towards this goal in the
[related epic](https://gitlab.com/groups/gitlab-org/-/epics/8267).
Hosted runners on macOS are in [Beta](../../../policy/experiment-beta-support.md#beta) and available for open source programs and customers in Premium and Ultimate plans.
[General availability](../../../policy/experiment-beta-support.md#generally-available-ga) of Hosted runners on macOS is proposed in [epic 8267](https://gitlab.com/groups/gitlab-org/-/epics/8267).
## Machine types available for macOS
GitLab offers the following machine type for hosted runners on macOS. To build for an x86-64 target, you can use Rosetta 2 to emulate an Intel x86-64 build environment.
GitLab offers the following machine type for hosted runners on macOS. To build for an x86-64 target, you can use Rosetta 2 to emulate an Intel x86-64 environment.
| Runner Tag | vCPUS | Memory | Storage |
| ---------------------- | ----- | ------ | ------- |

9
doc/ci/runners/hosted_runners/windows.md
View File

@ -15,8 +15,7 @@ Hosted runners on Windows autoscale by launching virtual machines on
the Google Cloud Platform. This solution uses an
[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/blob/main/docs/README.md)
developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
Hosted runners on Windows are in [Beta](../../../policy/experiment-beta-support.md#beta)
and aren't recommended for production workloads.
Hosted runners on Windows are in [Beta](../../../policy/experiment-beta-support.md#beta).
We want to keep iterating to get Windows runners in a stable state and
[generally available](../../../policy/experiment-beta-support.md#generally-available-ga).
@ -40,15 +39,11 @@ You can execute your job in one of the following Windows versions:
| Version | Status |
|--------------|---------------|
| Windows 2022 | `Beta` |
| Windows 2019 | `Deprecated` (Removal in 17.0) |
| Windows 2022 | `GA` |
You can find a full list of available pre-installed software in
the [pre-installed software documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/-/blob/main/cookbooks/preinstalled-software/attributes/default.rb).
NOTE:
We are only supporting a single version of Windows at this time.
## Supported shell
Hosted runners on Windows have PowerShell configured as the shell.

BIN
doc/ci/runners/img/gitlab-hosted_runners_architecture.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 50 KiB

161
doc/ci/runners/index.md
View File

@ -23,14 +23,88 @@ Your jobs can run on:
- [Hosted runners on Windows](hosted_runners/windows.md) ([Beta](../../policy/experiment-beta-support.md#beta))
- [Hosted runners on macOS](hosted_runners/macos.md) ([Beta](../../policy/experiment-beta-support.md#beta))
### How hosted runners for GitLab.com work
When you use hosted runners:
- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
- The virtual machine where your job runs has `sudo` access with no password.
- The storage is shared by the operating system, the image with pre-installed software, and a copy of your cloned repository.
This means that the available free disk space for your jobs to use is reduced.
- [Untagged](../yaml/index.md#tags) jobs run on the `small` Linux x86-64 runner.
NOTE:
Jobs handled by hosted runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project.
### Security of hosted runners for GitLab.com
The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner build environment.
Hosted runners for GitLab.com are configured as such:
- Firewall rules only allow outbound communication from the ephemeral VM to the public internet.
- Inbound communication from the public internet to the ephemeral VM is not allowed.
- Firewall rules do not permit communication between VMs.
- The only internal communication allowed to the ephemeral VMs is from the runner manager.
- VM isolation between job executions.
- Ephemeral runner VMs will only serve a single job and will be deleted right after the job execution.
#### Architecture diagram of hosted runners for GitLab.com
The following graphic shows the architecture diagram of hosted runners for GitLab.com
![Hosted runners for GitLab.com architecture](img/gitlab-hosted_runners_architecture.png)
For more information on how runners are authenticating and executing the job payload, see [Runner Execution Flow](https://docs.gitlab.com/runner#runner-execution-flow).
#### Job isolation of hosted runners for GitLab.com
In addition to isolating runners on the network, each ephemeral runner VM only serves a single job and is deleted straight after the job execution.
In the following example, three jobs are executed in a project's pipeline. Each of these jobs runs in a dedicated ephemeral VM.
![Job isolation](img/build_isolation.png)
The build job ran on `runner-ns46nmmj-project-43717858`, test job on `f131a6a2runner-new2m-od-project-43717858` and deploy job on `runner-tmand5m-project-43717858`.
GitLab sends the command to remove the ephemeral runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext)
takes over the task of securely deleting the virtual machine and associated data.
For more information about the security of hosted runners for GitLab.com, see
[Google Cloud Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf),
[GitLab Trust Center](https://about.gitlab.com/security/), or [GitLab Security Compliance Controls](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/sec-controls/).
### Caching on hosted runners for GitLab.com
The hosted runners share a [distributed cache](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching)
stored in a Google Cloud Storage (GCS) bucket. Cache contents not updated in the last 14 days are automatically
removed, based on the [object lifecycle management policy](https://cloud.google.com/storage/docs/lifecycle).
The maximum size of an uploaded cache artifact can be 5 GB after the cache becomes a compressed archive.
For more information about how caching works, see [Architecture diagram of hosted runners for GitLab.com](#architecture-diagram-of-hosted-runners-for-gitlabcom), and [Caching in GitLab CI/CD](../caching/index.md).
### Pricing of hosted runners for GitLab.com
Jobs that run on hosted runners for GitLab.com consume [compute minutes](../pipelines/cicd_minutes.md) allocated to your namespace.
The number of minutes you can use on these runners depends on the included compute minutes in your [subscription plan](https://about.gitlab.com/pricing/) or [additionally purchased compute minutes](../pipelines/cicd_minutes.md#purchase-additional-compute-minutes).
For more information about the cost factor applied to the machine type based on size, see [cost factor](../../ci/pipelines/cicd_minutes.md#gitlab-hosted-runner-costs).
The number of minutes you can use on these runners depends on the [maximum number of units of compute](../pipelines/cicd_minutes.md)
in your [subscription plan](https://about.gitlab.com/pricing/).
[Untagged](../../ci/runners/configure_runners.md#control-jobs-that-a-runner-can-run) jobs automatically run in containers
on the `small` Linux runners.
### SLO & Release cycle for hosted runners for GitLab.com
The objective is to make 90% of CI/CD jobs start executing in 120 seconds or less. The error rate should be less than 0.5%.
Our SLO objective is to make 90% of CI/CD jobs start executing in 120 seconds or less. The error rate should be less than 0.5%.
We aim to update to the latest version of [GitLab Runner](https://docs.gitlab.com/runner/#gitlab-runner-versions) within a week of its release.
You can find all GitLab Runner breaking changes under [Deprecations and removals](../../update/deprecations.md).
## Hosted runners for GitLab community contributions
If you want to [contribute to GitLab](https://about.gitlab.com/community/contribute/), jobs will be picked up by the
`gitlab-shared-runners-manager-X.gitlab.com` fleet of runners, dedicated for GitLab projects and related community forks.
These runners are backed by the same machine type as our `small` Linux x86-64 runners.
Unlike hosted runners for GitLab.com, hosted runners for GitLab community contributions are re-used up to 40 times.
As we want to encourage people to contribute, these runners are free of charge.
## Hosted runners for GitLab Dedicated
@ -39,84 +113,29 @@ Your jobs can run on:
- [Hosted runners on Linux](hosted_runners/linux.md) ([Beta](../../policy/experiment-beta-support.md#beta))
## How hosted runners for GitLab.com work
When you use hosted runners:
- Each of your jobs runs in a newly provisioned VM, which is dedicated to the specific job.
- The VM is active only for the duration of the job and immediately deleted. This means that any changes that your job makes to the virtual machine will not be available to a subsequent job.
- The virtual machine where your job runs has `sudo` access with no password.
- The storage is shared by the operating system, the image with pre-installed software, and a copy of your cloned repository.
This means that the available free disk space for your jobs to use is reduced.
NOTE:
Jobs handled by hosted runners on GitLab.com **time out after 3 hours**, regardless of the timeout configured in a project.
## Release cycle for GitLab-hosted runners
We aim to update to the latest version of [GitLab Runner](https://docs.gitlab.com/runner/#gitlab-runner-versions) within a week of its release.
You can find all GitLab Runner breaking changes under [Deprecations and removals](../../update/deprecations.md).
## Security for GitLab-hosted runners
Hosted runners on Linux and Windows for GitLab.com run on Google Cloud Compute Engine.
The [Google Infrastructure Security Design Overview whitepaper](https://cloud.google.com/docs/security/infrastructure/design/resources/google_infrastructure_whitepaper_fa.pdf)
provides an overview of how Google designs security into its technical infrastructure.
The GitLab [Trust Center](https://about.gitlab.com/security/) and
[GitLab Security Compliance Controls](https://handbook.gitlab.com/handbook/security/security-assurance/security-compliance/sec-controls/)
pages provide an overview of the security and compliance controls that govern the GitLab-hosted runners.
The following section provides an overview of the additional built-in layers that harden the security of the GitLab Runner build environment.
### Security of CI job execution
A dedicated temporary runner VM hosts and runs each CI job. On hosted runners for GitLab.com, two CI jobs never run on the same VM.
In this example, there are three jobs in the project's pipeline. Therefore, there are three temporary VMs used to run that pipeline, or one VM per job.
![Job isolation](img/build_isolation.png)
The build job ran on `runner-ns46nmmj-project-43717858`, test job on `f131a6a2runner-new2m-od-project-43717858` and deploy job on `runner-tmand5m-project-43717858`.
GitLab sends the command to remove the temporary runner VM to the Google Compute API immediately after the CI job completes. The [Google Compute Engine hypervisor](https://cloud.google.com/blog/products/gcp/7-ways-we-harden-our-kvm-hypervisor-at-google-cloud-security-in-plaintext)
takes over the task of securely deleting the virtual machine and associated data.
### Network security of CI job VMs
- Firewall rules only allow outbound communication from the temporary VM to the public internet.
- Inbound communication from the public internet to the temporary VM is not allowed.
- Firewall rules do not permit communication between VMs.
- The only internal communication allowed to the temporary VMs is from the runner manager.
## Supported image lifecycle
Hosted runners on macOS and Windows can only run jobs on supported images. You cannot bring your own image. Supported images have the following lifecycle:
- Beta
- Generally Available
- Deprecated
Hosted runners on macOS and Windows can only run jobs on supported images. You cannot bring your own image.
Supported images have the following lifecycle:
### Beta
To gather feedback on an image prior to making the image Generally Available (GA) and to address
any issues, new images are released as Beta. Any jobs running on Beta images are not
covered by the service-level agreement. If you use Beta images, you can provide feedback
by creating an issue.
New images are released as Beta. This allows us to gather feedback and address potential issues before General Availablility (GA).
Any jobs running on Beta images are not covered by the service-level agreement.
If you use Beta images, you can provide feedback by creating an issue.
### Generally Available
### General Availablility (GA)
A Generally Available (GA) image is released after the image completes a Beta phase
and is considered suitable for general use. To become GA, the
image must fulfill the following requirements:
A image becomes generally available after the image completes the Beta phase and is considered stable.
To become GA, the image must fulfill the following requirements:
- Successful completion of a Beta phase by resolving all reported significant bugs
- Compatibility of installed software with the underlying OS
Jobs running on GA images are covered by the defined service-level agreement. Over time, these images are deprecated.
Jobs that run on GA images are covered by the defined service-level agreement.
### Deprecated
A maximum of two Generally Available (GA) images are supported at a time. After a new GA image is released,
the oldest GA image becomes deprecated. A deprecated image is no longer
updated and is deleted after 3 months in accordance with the [deprecation guidelines](../../development/deprecation_guidelines/index.md).
the oldest GA image becomes deprecated. A deprecated image is no longer updated and is deleted after 3 months
in accordance with the [deprecation guidelines](../../development/deprecation_guidelines/index.md).

2
doc/development/bulk_imports/contributing.md
View File

@ -4,7 +4,7 @@ group: Import and Integrate
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.
---
# Adding a new relation to the direct transfer importer
# Add new relations to the direct transfer importer
At a high level, to add a new relation to the direct transfer importer, you must:

87
doc/development/documentation/topic_types/get_started.md
View File

@ -6,29 +6,20 @@ info: For assistance with this Style Guide page, see https://handbook.gitlab.com
# Get started page type
A **Get started** page is meant to introduce high-level concepts for a broad feature area.
A **Get started** page introduces high-level concepts for a broad feature area.
While a specific feature might be defined in the feature documentation,
a **Get started** page is meant to give an introduction to a set of concepts.
When you group the concepts together, you help the user see how they fit together.
A **Get started** page should familiarize the reader with terms and then quickly
point them to actions they can take to get started. Hopefully the actions are
task-based, but the next step can also be to learn more.
a **Get started** page gives an introduction to a set of concepts.
The content should help the user understand how multiple features fit together
as part of the larger GitLab workflow.
## When to use a Get started page
A **Get started** page should be used only for a larger concept,
like CI/CD or security. In general, we describe features in concept topics.
However, if you find you want to explain how multiple concepts fit together,
then a **Get started** page might be what you need.
For now, a **Get started** page should be used only at the highest level of the left navigation.
For example, you might have a **Get started** page under **Manage your organization** or **Extend GitLab**.
To determine if a **Get started** page makes sense, make a list
of the common terms you expect to include. If you have more than four or five,
then this page type might make sense.
A **Get started** page is different from a tutorial. It's conceptual, while
a tutorial helps the user achieve a task. A **Get started** page should point
to tutorials, however, because tutorials are a great way for a user to get started.
A **Get started** page is different from a tutorial. A **Get started** page focuses on high-level
concepts that are part of a workflow, while a tutorial helps the user achieve a task.
A **Get started** page should point to tutorials, however, because tutorials are a great way for a user to get started.
## Format
@ -37,56 +28,60 @@ Get started pages should be in this format:
```markdown
# Get started with abc
Abc is a thing you use to do xyz. You might use it when you need to blah,
and it can be helpful for etc.
These features work together in this way. You can use them to achieve these goals.
Include a paragraph that ties together the features without describing what
each individual feature does.
## Common terms
Then add this sentence and a diagram. Details about the diagram
file are below.
If you're new to abc, start by reviewing some of the most commonly used terms.
The process of <abc> is part of a larger workflow:
### First term
![Workflow](img/workflow diagram.png)
This thing is this. Describe what it is, not how to do it.
## Step 1: Do this thing
**Get started:**
Each step should group features by workflow. For example, step 1 might be:
`## Step 1: Determine your release cadence`
Then the content can explain milestones, iterations, labels, etc.
The terms can exist elsewhere in the docs, but the descriptions
on this page should be relatively brief.
Finally, add links, in this format:
For more information, see:
- [Create your first abc](LINK).
- [Learn more about abc](LINK).
### Second term
## Step 2: The next thing
This thing is this. Describe what it is, not how to do it.
Don't link in the body content. Save links for the `for more information` area.
**Get started:**
For more information, see:
- [Create your first abc](LINK).
- [Learn more about abc](LINK).
## Videos
- [Video 1](LINK).
- [Video 2](LINK).
## Related topics
- [Link 1](LINK).
- [Link 2](LINK).
```
- Follow [the video guidance](../styleguide/index.md#link-to-video)
for the links in the Video topic.
- Do not use links inline with content (as part of sentences).
Use them where links are specified only.
- The terms described on this page can exist elsewhere in the docs.
However, the term descriptions on this page should be relatively brief.
## Get started page titles
For the title, use `Get started with topic_name`.
For the left nav, use `Getting started`.
## Get started file location
All **Getting started** files should be in the folder `doc/user/get_started/`.
You do not need to create a subfolder for each file.
## Diagram files
The diagram files are [in this Google Slides doc](https://docs.google.com/presentation/d/19spBwRAb4QNoTdZofR37TkBBFBPcmh4196ae3lX1ngQ/edit?usp=sharing).
## Example
For an example of the Get started page type,
see [Get started with GitLab CI/CD](../../../ci/index.md).
see [Get started learning Git](../../../topics/git/get_started.md).

1
doc/development/feature_development.md
View File

@ -101,6 +101,7 @@ Consult these topics for information on contributing to specific GitLab features
### Import and Export
- [Add new relations to the direct transfer importer](bulk_imports/contributing.md)
- [Principles of importer design](import/principles_of_importer_design.md)
- [Working with the GitHub importer](github_importer.md)
- [Import/Export development documentation](import_export.md)

12
doc/development/secure_coding_guidelines.md
View File

@ -19,14 +19,14 @@ For each of the guidelines listed in this document, AppSec aims to have a SAST r
|---|---|---|
| [Regular Expressions](#regular-expressions-guidelines) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/issues/13) | ⏳ In progress |
| [ReDOS](#denial-of-service-redos--catastrophic-backtracking) | Pending | ❌ |
| [SSRF](#server-side-request-forgery-ssrf) | [1](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_insecure_url.yml), [2](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_insecure_http.yml?ref_type=heads) | ✅ |
| [SSRF](#server-side-request-forgery-ssrf) | [1](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_insecure_url.yml), [2](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_insecure_http.yml?ref_type=heads) | ✅ |
| [XSS](#xss-guidelines) | Pending | ❌ |
| [Path traversal](#path-traversal-guidelines) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_path_traversal.yml?ref_type=heads) | ✅ |
| [Path traversal](#path-traversal-guidelines) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_path_traversal.yml?ref_type=heads) | ✅ |
| [Path traversal](#path-traversal-guidelines) (Go) | Pending | ❌ |
| [OS command injection](#os-command-injection-guidelines) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_command_injection.yml?ref_type=heads) | ✅ |
| [OS command injection](#os-command-injection-guidelines) (Go) | Pending | ❌ |
| [Insecure TLS ciphers](#tls-minimum-recommended-version) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_insecure_ciphers.yml?ref_type=heads) | ✅ |
| [Archive operations](#working-with-archive-files) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby_insecure_archive_operations.yml?ref_type=heads) | ✅ |
| [OS command injection](#os-command-injection-guidelines) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_command_injection.yml?ref_type=heads) | ✅ |
| [OS command injection](#os-command-injection-guidelines) (Go) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/go/go_dangerous_exec_command.yml?ref_type=heads) | ✅ |
| [Insecure TLS ciphers](#tls-minimum-recommended-version) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_insecure_ciphers.yml?ref_type=heads) | ✅ |
| [Archive operations](#working-with-archive-files) (Ruby) | [Link](https://gitlab.com/gitlab-com/gl-security/product-security/appsec/sast-custom-rules/-/blob/main/secure-coding-guidelines/ruby/ruby_insecure_archive_operations.yml?ref_type=heads) | ✅ |
| [Archive operations](#working-with-archive-files) (Go) | Pending | ❌ |
| [URL spoofing](#url-spoofing) | Pending | ❌ |
| [GitLab internal authorization](#gitlab-internal-authorization) | N/A | N/A |

15
doc/user/gitlab_com/index.md
View File

@ -322,20 +322,19 @@ The limit varies depending on your plan and the number of seats in your subscrip
### Other limits
| Setting | Default for GitLab.com |
| ------------------------------------------ | -------------------------------------------------------------------------------------------------- |
| Number of webhooks | `100` per project, `50` per group (subgroup webhooks are not counted towards parent group limits ) |
| Maximum payload size | 25 MB |
| Timeout | 10 seconds |
| [Pages multiple deployments](../project/pages/index.md#limits) on Premium tier | 100 extra deployments |
| [Pages multiple deployments](../project/pages/index.md#limits) on Ultimate tier | 100 extra deployments |
| Setting | Default for GitLab.com |
|:---------------------------------------------------------------|:-----------------------|
| Number of webhooks | 100 per project, 50 per group (subgroup webhooks are not counted towards parent group limits ) |
| Maximum payload size | 25 MB |
| Timeout | 10 seconds |
| [Multiple Pages deployments](../project/pages/index.md#limits) | 100 extra deployments (Premium tier), 500 extra deployments (Ultimate tier) |
For self-managed instance limits, see:
- [Webhook rate limit](../../administration/instance_limits.md#webhook-rate-limit).
- [Number of webhooks](../../administration/instance_limits.md#number-of-webhooks).
- [Webhook timeout](../../administration/instance_limits.md#webhook-timeout).
- [Pages multiple deployments](../../administration/instance_limits.md#number-of-extra-pages-deployments-when-using-multiple-deployments).
- [Multiple Pages deployments](../../administration/instance_limits.md#number-of-extra-pages-deployments-when-using-multiple-deployments).
## Runner SaaS

4
doc/user/profile/preferences.md
View File

@ -376,12 +376,12 @@ You must be the administrator of the GitLab instance to configure GitLab with So
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/459028) in GitLab 17.0.
FLAG:
The availability of this feature is controlled by a feature flag.
The availability of this feature is controlled by feature flags.
For more information, see the history.
You can use the [extension marketplace](../project/web_ide/index.md#extension-marketplace)
to search and manage extensions for the Web IDE.
For third-party extensions, you must enable the marketplace in your user preferences.
For third-party extensions, you must enable the marketplace in user preferences.
To enable the extension marketplace for the Web IDE:

9
doc/user/project/pages/index.md
View File

@ -218,12 +218,11 @@ To enable multiple GitLab Pages deployments:
### Limits
The number of extra deployments are limited by root level namespace.
The number of extra deployments is limited by the root-level namespace. For specific limits for:
- On GitLab.com:
- Premium tier is limited to 100 extra deployments.
- Ultimate tier is limited to 500 extra deployments.
- Self-managed GitLab instances are limited to 1000 extra deployments.
- GitLab.com, see [Other limits](../../gitlab_com/index.md#other-limits).
- Self-managed GitLab instances, see
[Number of extra Pages deployments when using multiple deployments](../../../administration/instance_limits.md#number-of-extra-pages-deployments-when-using-multiple-deployments).
### Path clash

13
doc/user/project/web_ide/index.md
View File

@ -16,7 +16,8 @@ DETAILS:
> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115741) in GitLab 15.11.
FLAG:
On self-managed GitLab, by default this feature is available. To hide the feature, an administrator can [disable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com and GitLab Dedicated, this feature is available.
The availability of this feature is controlled by a feature flag.
For more information, see the history.
The Web IDE is an advanced editor with commit staging.
You can use the Web IDE to make changes to multiple files directly from the GitLab UI.
@ -208,9 +209,6 @@ To view any notification you might have missed:
DETAILS:
**Status**: Beta
WARNING:
This feature is in [Beta](../../../policy/experiment-beta-support.md#beta) and subject to change without notice.
When you set up a remote development server in the Web IDE, you can use interactive web terminals to:
- Access a remote shell on the server.
@ -226,19 +224,16 @@ For more information, see [Remote development](../remote_development/index.md).
DETAILS:
**Status**: Beta
WARNING:
This feature is in [Beta](../../../policy/experiment-beta-support.md#beta) and subject to change without notice.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/151352) in GitLab 17.0 [with flags](../../../administration/feature_flags.md) named `web_ide_oauth` and `web_ide_extensions_marketplace`. Disabled by default.
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/459028) in GitLab 17.0.
FLAG:
The availability of this feature is controlled by a feature flag.
The availability of this feature is controlled by feature flags.
For more information, see the history.
Prerequisites:
- You must enable the extension marketplace in your [user preferences](../../profile/preferences.md#integrate-with-the-extension-marketplace).
- You must [enable the extension marketplace](../../profile/preferences.md#integrate-with-the-extension-marketplace) in user preferences.
You can use the extension marketplace to download and run VS Code extensions in the Web IDE.

10
spec/features/groups/labels/create_spec.rb
View File

@ -13,6 +13,16 @@ RSpec.describe 'Create a group label', feature_category: :team_planning do
visit new_group_label_path(group)
end
it 'renders the breadcrumbs', :aggregate_failures do
within_testid('breadcrumb-links') do
expect(page).to have_content("#{group.name} Labels New label")
expect(page).to have_link(group.name, href: group_path(group))
expect(page).to have_link('Labels', href: group_labels_path(group))
expect(page).to have_link('New label', href: new_group_label_path(group))
end
end
it 'creates a new label' do
fill_in 'Title', with: 'test-label'
click_button 'Create label'

25
spec/features/groups/milestones/milestone_creating_spec.rb Normal file
View File

@ -0,0 +1,25 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe 'Create a group milestone', feature_category: :team_planning do
let(:user) { create(:user) }
let(:group) { create(:group) }
before do
group.add_owner(user)
sign_in(user)
visit new_group_milestone_path(group)
end
it 'renders the breadcrumbs', :aggregate_failures do
within_testid('breadcrumb-links') do
expect(page).to have_content("#{group.name} Milestones New milestone")
expect(page).to have_link(group.name, href: group_path(group))
expect(page).to have_link('Milestones', href: group_milestones_path(group))
expect(page).to have_link('New milestone', href: new_group_milestone_path(group))
end
end
end

6
spec/models/user_spec.rb
View File

@ -5681,18 +5681,18 @@ RSpec.describe User, feature_category: :user_profile do
end
describe '#owns_organization?' do
let_it_be(:user) { create(:user) }
let_it_be(:organization) { create(:organization) }
let(:user) { create(:user) }
subject { user.owns_organization?(organization_param) }
context 'when passed organization object', quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/460622' do
context 'when passed organization object' do
let(:organization_param) { organization }
it_behaves_like 'organization owner'
end
context 'when passed organization id', quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/460623' do
context 'when passed organization id' do
let(:organization_param) { organization.id }
it_behaves_like 'organization owner'