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-02-06 00:12:20 +00:00
parent 9947cb3657
commit f9e4f1b18a
56 changed files with 335 additions and 214 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
Gemfile
View File

@ -557,7 +557,7 @@ gem 'ssh_data', '~> 1.3' # rubocop:todo Gemfile/MissingFeatureCategory
gem 'spamcheck', '~> 1.3.0' # rubocop:todo Gemfile/MissingFeatureCategory
# Gitaly GRPC protocol definitions
gem 'gitaly', '~> 16.9.0-rc2', feature_category: :gitaly
gem 'gitaly', '~> 16.9.0-rc3', feature_category: :gitaly
# KAS GRPC protocol definitions
gem 'kas-grpc', '~> 0.3.0', feature_category: :deployment_management

2
Gemfile.checksum
View File

@ -207,7 +207,7 @@
{"name":"gettext","version":"3.4.9","platform":"ruby","checksum":"292864fe6a15c224cee4125a4a72fab426fdbb280e4cff3cfe44935f549b009a"},
{"name":"gettext_i18n_rails","version":"1.11.0","platform":"ruby","checksum":"e19c7e4a256c500f7f38396dca44a282b9838ae278f57c362993a54964b22bbe"},
{"name":"git","version":"1.18.0","platform":"ruby","checksum":"c9b80462e4565cd3d7a9ba8440c41d2c52244b17b0dad0bfddb46de70630c465"},
{"name":"gitaly","version":"16.9.0.pre.rc2","platform":"ruby","checksum":"6b2066f8df33ddeef9daeb02f0d749d64c6f2e970c8ba3fa14daf520799c9e32"},
{"name":"gitaly","version":"16.9.0.pre.rc3","platform":"ruby","checksum":"56a138e1e5b9a011ff71aec394e8ec11d69e01925b0eba45b0aeb54a6675091f"},
{"name":"gitlab","version":"4.19.0","platform":"ruby","checksum":"3f645e3e195dbc24f0834fbf83e8ccfb2056d8e9712b01a640aad418a6949679"},
{"name":"gitlab-chronic","version":"0.10.5","platform":"ruby","checksum":"f80f18dc699b708870a80685243331290bc10cfeedb6b99c92219722f729c875"},
{"name":"gitlab-dangerfiles","version":"4.6.0","platform":"ruby","checksum":"441b37b17d1dad36268517490a30aaf57e43dffb2e9ebc1da38d3bc9fa20741e"},

4
Gemfile.lock
View File

@ -685,7 +685,7 @@ GEM
git (1.18.0)
addressable (~> 2.8)
rchardet (~> 1.8)
gitaly (16.9.0.pre.rc2)
gitaly (16.9.0.pre.rc3)
grpc (~> 1.0)
gitlab (4.19.0)
httparty (~> 0.20)
@ -1909,7 +1909,7 @@ DEPENDENCIES
fuubar (~> 2.2.0)
gettext (~> 3.3)
gettext_i18n_rails (~> 1.11.0)
gitaly (~> 16.9.0.pre.rc2)
gitaly (~> 16.9.0.pre.rc3)
gitlab-backup-cli!
gitlab-chronic (~> 0.10.5)
gitlab-dangerfiles (~> 4.6.0)

16
app/assets/javascripts/commit/pipelines/legacy_pipelines_table_wrapper.vue
View File

@ -197,7 +197,8 @@ export default {
i18n: {
runPipelinePopoverTitle: s__('Pipeline|Run merge request pipeline'),
runPipelinePopoverDescription: s__(
'Pipeline|To run a merge request pipeline, the jobs in the CI/CD configuration file %{linkStart}must be configured%{linkEnd} to run in merge request pipelines.',
`Pipeline|To run a merge request pipeline, the jobs in the CI/CD configuration file %{ciDocsLinkStart}must be configured%{ciDocsLinkEnd} to run in merge request pipelines
and you must have %{permissionDocsLinkStart}sufficient permissions%{permissionDocsLinkEnd} in the source project.`,
),
runPipelineText: s__('Pipeline|Run pipeline'),
emptyStateTitle: s__('Pipelines|There are currently no pipelines.'),
@ -205,6 +206,9 @@ export default {
mrPipelinesDocsPath: helpPagePath('ci/pipelines/merge_request_pipelines.md', {
anchor: 'prerequisites',
}),
userPermissionsDocsPath: helpPagePath('user/permissions.md', {
anchor: 'gitlab-cicd-permissions',
}),
runPipelinesInTheParentProjectHelpPath: helpPagePath(
'/ci/pipelines/merge_request_pipelines.html',
{
@ -241,7 +245,7 @@ export default {
>
<template #description>
<gl-sprintf :message="$options.i18n.runPipelinePopoverDescription">
<template #link="{ content }">
<template #ciDocsLink="{ content }">
<gl-link
:href="$options.mrPipelinesDocsPath"
target="_blank"
@ -249,6 +253,14 @@ export default {
>{{ content }}</gl-link
>
</template>
<template #permissionDocsLink="{ content }">
<gl-link
:href="$options.userPermissionsDocsPath"
target="_blank"
data-testid="user-permissions-docs-link"
>{{ content }}</gl-link
>
</template>
</gl-sprintf>
</template>

14
app/assets/javascripts/projects/project_new.js
View File

@ -219,7 +219,7 @@ const bindEvents = () => {
const $projectImportUrlPassword = $('#project_import_url_password');
const $projectImportUrlError = $('.js-import-url-error');
const $projectImportForm = $('form.js-project-import');
const $useTemplateBtn = $('.template-button > input');
const $useTemplateBtn = $('.js-use-template-button');
const $changeTemplateBtn = $('.change-template');
const $projectImportUrl = document.querySelector('#project_import_url');
@ -256,9 +256,7 @@ const bindEvents = () => {
clearChildren($selectedIcon);
const $selectedTemplate = this;
$selectedTemplate.checked = true;
const { value } = $selectedTemplate;
const value = $($selectedTemplate).data('templateName');
const selectedTemplate = DEFAULT_PROJECT_TEMPLATES[value];
$selectedTemplateText.textContent = selectedTemplate.text;
const clone = document.querySelector(selectedTemplate.icon).cloneNode(true);
@ -273,11 +271,6 @@ const bindEvents = () => {
setProjectNamePathHandlers($activeTabProjectName, $activeTabProjectPath);
}
function toggleActiveClassOnLabel(event) {
const $label = $(event.target).parent();
$label.toggleClass('active');
}
function chooseTemplateOnEnter(event) {
if (event.code === ENTER_KEY) {
chooseTemplate.call(this);
@ -285,14 +278,11 @@ const bindEvents = () => {
}
$useTemplateBtn.on('click', chooseTemplate);
$useTemplateBtn.on('focus focusout', toggleActiveClassOnLabel);
$useTemplateBtn.on('keypress', chooseTemplateOnEnter);
$changeTemplateBtn.on('click', () => {
$projectTemplateButtons.forEach((ptb) => ptb.classList.remove('hidden'));
$projectFieldsForm.classList.remove('selected');
$useTemplateBtn.prop('checked', false);
});
$newProjectForm.on('submit', () => {

4
app/controllers/user_settings/profiles_controller.rb
View File

@ -76,3 +76,7 @@ module UserSettings
end
end
end
# Added for JiHu
# Used in https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/app/controllers/jh/user_settings/profiles_controller.rb
UserSettings::ProfilesController.prepend_mod

2
app/models/system_note_metadata.rb
View File

@ -4,7 +4,7 @@ class SystemNoteMetadata < ApplicationRecord
include Importable
include IgnorableColumns
ignore_column :id_convert_to_bigint, remove_with: '16.9', remove_after: '2024-01-13'
ignore_column :id_convert_to_bigint, remove_with: '16.11', remove_after: '2024-03-15'
# These notes's action text might contain a reference that is external.
# We should always force a deep validation upon references that are found

7
app/views/projects/project_templates/_template.html.haml
View File

@ -10,8 +10,5 @@
.controls.d-flex.gl-align-items-center
= render Pajamas::ButtonComponent.new(button_options: { class: 'gl-mr-3', data: { track_label: "template_preview", track_property: template.name, track_action: "click_button", track_value: "" }, rel: 'noopener noreferrer' }, href: template.preview, target: '_blank') do
= _("Preview")
%label.btn.gl-button.btn-confirm.template-button.choose-template.gl-mb-0{ for: template.name,
'data-testid': "use_template_#{template.name}" }
%input{ type: "radio", autocomplete: "off", name: "project[template_name]", id: template.name, value: template.name, data: { track_label: "template_use", track_property: template.name, track_action: "click_button", track_value: "" } }
%span{ data: { testid: 'use-template-button' } }
= _("Use template")
= render Pajamas::ButtonComponent.new(variant: :confirm, button_options: { class: 'js-use-template-button', data: { testid: "use-template-#{template.name}", track_label: 'template_use', track_property: template.name, track_action: 'click_button', track_value: '', template_name: template.name } }) do
= _("Use template")

2
config/metrics/counts_28d/20230620070723_k8s_api_proxy_requests_unique_agents_via_ci_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: MAU of the unique Agents using the CI/CD Tunnel via Ci Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_28d/20230620070723_k8s_api_proxy_requests_unique_agents_via_user_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: MAU of the unique Agents using the CI/CD Tunnel via User Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_28d/20230620070723_k8s_api_proxy_requests_unique_users_via_ci_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: MAU of the unique Users using the CI/CD Tunnel via Ci Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_28d/20230620070723_k8s_api_proxy_requests_unique_users_via_user_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: MAU of the unique Users using the CI/CD Tunnel via User Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_28d/20230630153556_flux_git_push_notified_unique_projects_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.flux_git_push_notified_unique_proj
description: MAU of the unique projects which were notified by agentk about new Git push events in order to reconcile their Flux workloads
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_28d/20230816085153_k8s_api_proxy_requests_unique_agents_via_pat_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: MAU of the unique Agents using the KAS Kubernetes API proxy via Personal Access Token Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.4"

2
config/metrics/counts_28d/20230816085153_k8s_api_proxy_requests_unique_users_via_pat_access_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: MAU of the unique Users using the KAS Kubernetes API proxy via Personal Access Token Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.4"

2
config/metrics/counts_28d/20240130072055_p_ci_templates_opentofu_base_latest_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.ci_templates.p_ci_templates_opentofu_base_latest_mo
description: Count of pipelines that include the OpenTofu job template from GitLab
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.9"

2
config/metrics/counts_28d/20240130072115_p_ci_templates_opentofu_latest_monthly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.ci_templates.p_ci_templates_opentofu_latest_monthly
description: Count of pipelines that include the OpenTofu pipeline template from GitLab
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.9"

2
config/metrics/counts_7d/20230620070722_k8s_api_proxy_requests_unique_agents_via_ci_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: WAU of the unique Agents using the CI/CD Tunnel via Ci Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_7d/20230620070722_k8s_api_proxy_requests_unique_users_via_ci_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: WAU of the unique Users using the CI/CD Tunnel via Ci Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_7d/20230620070723_k8s_api_proxy_requests_unique_agents_via_user_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: WAU of the unique Agents using the CI/CD Tunnel via User Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_7d/20230620070723_k8s_api_proxy_requests_unique_users_via_user_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: WAU of the unique Users using the CI/CD Tunnel via User Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_7d/20230630153554_flux_git_push_notified_unique_projects_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.flux_git_push_notified_unique_proj
description: WAU of the unique projects which were notified by agentk about new Git push events in order to reconcile their Flux workloads
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.2"

2
config/metrics/counts_7d/20230816085153_k8s_api_proxy_requests_unique_agents_via_pat_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_agen
description: WAU of the unique Agents using the KAS Kubernetes API proxy via Personal Access Token Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.4"

2
config/metrics/counts_7d/20230816085153_k8s_api_proxy_requests_unique_users_via_pat_access_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.kubernetes_agent.k8s_api_proxy_requests_unique_user
description: WAU of the unique Users using the KAS Kubernetes API proxy via Personal Access Token Access
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.4"

2
config/metrics/counts_7d/20240130072053_p_ci_templates_opentofu_base_latest_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.ci_templates.p_ci_templates_opentofu_base_latest_we
description: Count of pipelines that include the OpenTofu job template from GitLab
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.9"

2
config/metrics/counts_7d/20240130072114_p_ci_templates_opentofu_latest_weekly.yml
View File

@ -3,7 +3,7 @@ key_path: redis_hll_counters.ci_templates.p_ci_templates_opentofu_latest_weekly
description: Count of pipelines that include the OpenTofu pipeline template from GitLab
product_section: ops
product_stage: deploy
product_group: environment
product_group: environments
value_type: number
status: active
milestone: "16.9"

2
data/deprecations/15-9-insecure-ci-job-token.yml
View File

@ -11,7 +11,7 @@
body: | # (required) Do not modify this line, instead modify the lines below.
In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You can prevent job tokens **from your project's** pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines cannot access other projects. To use the job token to access other projects from your pipeline, you must list those projects explicitly in the **Limit CI_JOB_TOKEN access** setting's allowlist, and you must be a maintainer in all the projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
As a result, the **Limit** setting is deprecated in preference of the better **Allow access** setting. In GitLab 16.0 the **Limit** setting will be disabled by default for all new projects. In projects with this setting currently enabled, it will continue to function as expected, but you will not be able to add any more projects to the allowlist. If the setting is disabled in any project, it will not be possible to re-enable this setting in 16.0 or later.

2
data/deprecations/16-3-CI-job-token-scope-update.yml
View File

@ -9,7 +9,7 @@
stage: Verify # (required) String value of the stage that the feature was created in. e.g., Growth
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/420678 # (required) Link to the deprecation issue in GitLab
body: | # (required) Do not modify this line, instead modify the lines below.
Starting in 16.6, projects that are **public** or **internal** will no longer authorize job token requests from projects that are **not** on the project's allowlist when [**Limit access to this project**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token) is enabled.
Starting in 16.6, projects that are **public** or **internal** will no longer authorize job token requests from projects that are **not** on the project's allowlist when [**Limit access to this project**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist) is enabled.
If you have [public or internal](https://docs.gitlab.com/ee/user/public_access.html#change-project-visibility) projects with the **Limit access to this project** setting enabled, you must add any projects which make job token requests to your project's allowlist for continued authorization.
#

2
data/deprecations/16-5-ci-job-token-limit-setting.yml
View File

@ -11,7 +11,7 @@
body: | # (required) Do not modify this line, instead modify the lines below.
In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You can prevent job tokens **from your project's** pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines cannot access other projects. To use the job token to access other projects from your pipeline, you must list those projects explicitly in the **Limit CI_JOB_TOKEN access** setting's allowlist, and you must be a maintainer in all the projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The **Limit** setting was deprecated in 16.0 in preference of the better **Allow access** setting and **Limit** setting was disabled by default for all new projects. From this point forward, if the **Limit** setting is disabled in any project, it will not be possible to re-enable this setting in 16.0 or later.

2
data/deprecations/16-8-job-token-remove-scope-direction.yml
View File

@ -14,7 +14,7 @@
body: | # (required) Don't change this line.
The `direction` GraphQL argument for the `ciJobTokenScopeRemoveProject` mutation is deprecated. Following the [default CI/CD job token scope change](https://docs.gitlab.com/ee/update/deprecations.html#default-cicd-job-token-ci_job_token-scope-changed) announced in GitLab 15.9, the `direction` argument will default to `INBOUND` and `OUTBOUND` will no longer be valid in GitLab 17.0. We will remove the `direction` argument in GitLab 18.0.
If you are using `OUTBOUND` with the `direction` argument to control the direction of your project's token access, your pipeline that use job tokens risk failing authentication. To ensure pipelines continue to run as expected, you will need to explicitly [add the other projects to your project's allowlist](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-scope-allowlist).
If you are using `OUTBOUND` with the `direction` argument to control the direction of your project's token access, your pipeline that use job tokens risk failing authentication. To ensure pipelines continue to run as expected, you will need to explicitly [add the other projects to your project's allowlist](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist).
# ==============================
# OPTIONAL END-OF-SUPPORT FIELDS

9
db/docs/ci_resources.yml
View File

@ -8,3 +8,12 @@ description: TODO
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20950
milestone: '12.7'
gitlab_schema: gitlab_ci
desired_sharding_key:
project_id:
references: projects
backfill_via:
parent:
foreign_key: resource_group_id
table: ci_resource_groups
sharding_key: project_id
belongs_to: resource_group

10
doc/api/job_artifacts.md
View File

@ -12,7 +12,7 @@ DETAILS:
Use the job artifacts API to download or delete job artifacts.
Authentication with a [CI/CD job token](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline)
Authentication with a [CI/CD job token](../ci/jobs/job_artifacts.md#with-a-cicd-job-token)
available in the Premium and Ultimate tier.
## Get job artifacts
@ -32,7 +32,7 @@ GET /projects/:id/jobs/:job_id/artifacts
|-------------------------------|----------------|----------|-------------|
| `id` | integer/string | Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
| `job_id` | integer | Yes | ID of a job. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/job_artifacts.md#with-a-cicd-job-token) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
Example request using the `PRIVATE-TOKEN` header:
@ -102,7 +102,7 @@ Parameters
| `id` | integer/string | Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
| `job` | string | Yes | The name of the job. |
| `ref_name` | string | Yes | Branch or tag name in repository. HEAD or SHA references are not supported. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/job_artifacts.md#with-a-cicd-job-token) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
Example request using the `PRIVATE-TOKEN` header:
@ -165,7 +165,7 @@ Parameters
| `artifact_path` | string | Yes | Path to a file inside the artifacts archive. |
| `id` | integer/string | Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
| `job_id` | integer | Yes | The unique job identifier. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/job_artifacts.md#with-a-cicd-job-token) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
Example request:
@ -212,7 +212,7 @@ Parameters:
| `id` | integer/string | Yes | ID or [URL-encoded path of the project](rest/index.md#namespaced-path-encoding). |
| `job` | string | Yes | The name of the job. |
| `ref_name` | string | Yes | Branch or tag name in repository. `HEAD` or `SHA` references are not supported. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/ci_job_token.md#download-an-artifact-from-a-different-pipeline) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
| `job_token` | string | No | To be used with [triggers](../ci/jobs/job_artifacts.md#with-a-cicd-job-token) for multi-project pipelines. It should be invoked only in a CI/CD job defined in the `.gitlab-ci.yml` file. The value is always `$CI_JOB_TOKEN`. The job associated with the `$CI_JOB_TOKEN` must be running when this token is used. Premium and Ultimate only. |
Example request:

10
doc/api/project_job_token_scopes.md
View File

@ -18,7 +18,7 @@ The authenticated user must have at least the Maintainer role for the project.
## Get a project's CI/CD job token access settings
Fetch the [CI/CD job token access settings](../ci/jobs/ci_job_token.md#configure-cicd-job-token-access) (job token scope) of a project.
Fetch the [CI/CD job token access settings](../ci/jobs/ci_job_token.md#control-job-token-access-to-your-project) (job token scope) of a project.
```plaintext
GET /projects/:id/job_token_scope
@ -56,7 +56,7 @@ Example response:
> - **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
Patch the [**Limit access _to_ this project** setting](../ci/jobs/ci_job_token.md#disable-the-job-token-scope-allowlist) (job token scope) of a project.
Patch the [**Limit access _to_ this project** setting](../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) (job token scope) of a project.
```plaintext
PATCH /projects/:id/job_token_scope
@ -83,7 +83,7 @@ curl --request PATCH \
## Get a project's CI/CD job token inbound allowlist
Fetch the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) (job token scope) of a project.
Fetch the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) (job token scope) of a project.
```plaintext
GET /projects/:id/job_token_scope/allowlist
@ -150,7 +150,7 @@ Example response:
## Add a project to a CI/CD job token inbound allowlist
Add a project to the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) of a project.
Add a project to the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) of a project.
```plaintext
POST /projects/:id/job_token_scope/allowlist
@ -191,7 +191,7 @@ Example response:
## Remove a project from a CI/CD job token inbound allowlist
Remove a project from the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token) of a project.
Remove a project from the [CI/CD job token inbound allowlist](../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) of a project.
```plaintext
DELETE /projects/:id/job_token_scope/allowlist/:target_project_id

2
doc/architecture/blueprints/runway/index.md
View File

@ -195,7 +195,7 @@ The goal of Runway is to not rely on long lived secrets or tokens inside the run
#### Service projects to runway deployment projects
This is handled by GitLab downstream pipeline triggers. Because of this, all permissions are handled within GitLab itself (and API calls to GitLab use short lived `CI_JOB_TOKEN`). We leverage [CI_JOB_TOKEN allowlists](../../../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-scope-allowlist) to allow deployment projects and service projects to interact in API calls (e.g. updating environments in the service project).
This is handled by GitLab downstream pipeline triggers. Because of this, all permissions are handled within GitLab itself (and API calls to GitLab use short lived `CI_JOB_TOKEN`). We leverage [CI_JOB_TOKEN allowlists](../../../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) to allow deployment projects and service projects to interact in API calls (e.g. updating environments in the service project).
#### Deployment project to GCP Cloud

2
doc/ci/debugging.md
View File

@ -295,7 +295,7 @@ These errors can happen if the following are both true:
the private project's allowlist.
To resolve this issue, add any projects with CI/CD jobs that fetch images from the container
registry to the target project's [job token allowlist](jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token).
registry to the target project's [job token allowlist](jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist).
These errors might also happen when trying to use a [project access token](../user/project/settings/project_access_tokens.md)
to access images in another project. Project access tokens are scoped to one project,

2
doc/ci/git_submodules.md
View File

@ -119,7 +119,7 @@ To make submodules work correctly in CI/CD jobs:
If you use the [`CI_JOB_TOKEN`](jobs/ci_job_token.md) to clone a submodule in a
pipeline job, the user executing the job must be assigned to a role that has
[permission](../user/permissions.md#gitlab-cicd-permissions) to trigger a pipeline
in the upstream submodule project. Additionally, [CI/CD job token access](jobs/ci_job_token.md#configure-cicd-job-token-access) must be properly configured in the upstream submodule project.
in the upstream submodule project. Additionally, [CI/CD job token access](jobs/ci_job_token.md#control-job-token-access-to-your-project) must be properly configured in the upstream submodule project.
## Troubleshooting

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

@ -10,58 +10,55 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** SaaS, self-managed
When a pipeline job is about to run, GitLab generates a unique token and injects it as the
[`CI_JOB_TOKEN` predefined variable](../variables/predefined_variables.md).
When a CI/CD pipeline job is about to run, GitLab generates a unique token and makes it available
to the job as the [`CI_JOB_TOKEN` predefined variable](../variables/predefined_variables.md).
The token is valid only while the job is running. After the job finishes, the token access
is revoked and you cannot use the token anymore.
You can use a GitLab CI/CD job token to authenticate with specific API endpoints:
Use a CI/CD job token to authenticate with certain GitLab features from running jobs.
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)
to access the resources.
- Packages:
- [Package registry](../../user/packages/package_registry/index.md#to-build-packages).
- [Packages API](../../api/packages.md) (project-level).
- [Container registry](../../user/packages/container_registry/build_and_push_images.md#use-gitlab-cicd)
(the `$CI_REGISTRY_PASSWORD` is `$CI_JOB_TOKEN`).
- [Container registry API](../../api/container_registry.md)
(scoped to the job's project).
- [Get job artifacts](../../api/job_artifacts.md#get-job-artifacts).
- [Get job token's job](../../api/jobs.md#get-job-tokens-job).
- [Pipeline triggers](../../api/pipeline_triggers.md), using the `token=` parameter
to [trigger a multi-project pipeline](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api).
- [Update pipeline metadata](../../api/pipelines.md#update-pipeline-metadata)
- [Releases](../../api/releases/index.md) and [Release links](../../api/releases/links.md).
- [Terraform plan](../../user/infrastructure/index.md).
- [Deployments](../../api/deployments.md).
- [Environments](../../api/environments.md).
You can use a job token to authenticate with GitLab to access another project's resources (the target project).
By default, the job token's project must be [added to the target project's allowlist](#add-a-project-to-the-job-token-allowlist).
The token has the same permissions to access the API as the user that caused the
job to run. A user can cause a job to run by taking action like pushing a commit,
triggering a manual job, or being the owner of a scheduled pipeline. Therefore, this user must be assigned to
[a role that has the required privileges](../../user/permissions.md#gitlab-cicd-permissions).
If a project is public or internal, you can access some features without being on the allowlist.
For example, you can fetch artifacts from the project's public pipelines.
This access can also [be restricted](#limit-job-token-scope-for-public-or-internal-projects).
The token is valid only while the pipeline job runs. After the job finishes, you cannot
use the token anymore.
| Feature | Additional details |
|-------------------------------------------------------------------------------------------------------|--------------------|
| [Container registry API](../../api/container_registry.md) | The token is scoped to the container registry of the job's project only. |
| [Container registry](../../user/packages/container_registry/build_and_push_images.md#use-gitlab-cicd) | The `$CI_REGISTRY_PASSWORD` [predefined variable](../variables/predefined_variables.md) is the CI/CD job token. |
| [Deployments API](../../api/deployments.md) | `GET` requests are public by default. |
| [Environments API](../../api/environments.md) | `GET` requests are public by default. |
| [Job artifacts API](../../api/job_artifacts.md#get-job-artifacts) | `GET` requests are public by default. |
| [Jobs API](../../api/jobs.md#get-job-tokens-job) | To get the job token's job. |
| [Package registry](../../user/packages/package_registry/index.md#to-build-packages) | |
| [Packages API](../../api/packages.md) | `GET` requests are public by default. |
| [Pipeline triggers](../../api/pipeline_triggers.md) | Used with the `token=` parameter to [trigger a multi-project pipeline](../pipelines/downstream_pipelines.md#trigger-a-multi-project-pipeline-by-using-the-api). |
| [Pipelines API](../../api/pipelines.md#update-pipeline-metadata) | To update pipeline metadata. |
| [Release links API](../../api/releases/links.md) | |
| [Releases API](../../api/releases/index.md) | `GET` requests are public by default. |
| [Terraform plan](../../user/infrastructure/index.md) | |
A job token can access a project's resources without any configuration, but it might
give extra permissions that aren't necessary. There is [a proposal](https://gitlab.com/groups/gitlab-org/-/epics/3559)
to redesign the feature for more strategic control of the access permissions.
You can also use the job token to authenticate and clone a repository from a private project
in a CI/CD job:
```shell
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>
```
You can't use a job token to push to a repository, but [issue 389060](https://gitlab.com/gitlab-org/gitlab/-/issues/389060) proposes to change this behavior.
to redesign the feature for more granular control of access permissions.
## GitLab CI/CD job token security
To prevent the CI/CD job token from leaking, GitLab:
If a job token is leaked, it could potentially be used to access private data accessible
to the user that triggered the CI/CD job. To help prevent leaking or misuse of this token,
GitLab:
- Masks the job token in job logs.
- Grants permissions to the job token only when the job is running.
To prevent leaking the deploy token, you should also configure your [runners](../runners/index.md)
to be secure:
You should also configure your [runners](../runners/index.md) to be secure:
- Avoid using Docker `privileged` mode if the machines are re-used.
- Avoid using the [`shell` executor](https://docs.gitlab.com/runner/executors/shell.html) when jobs
@ -70,64 +67,75 @@ to be secure:
An insecure GitLab Runner configuration increases the risk that someone can steal tokens from other
jobs.
## Configure CI/CD job token access
## Control job token access to your project
You can control what projects a CI/CD job token can access to increase the
job token's security. A job token might give extra permissions that aren't necessary
to access specific private resources.
You can control which projects can use a job token to authenticate and access your project's resources.
When enabled, and the job token is being used to access a different project:
By default, job token access is restricted to only CI/CD jobs that run in pipelines in
your project. To allow another project to authenticate with a job token from the other
project's pipeline:
- The user that executes the job must be a member of the project that is being accessed.
- You must [add the project to the job token allowlist](#add-a-project-to-the-job-token-allowlist).
- The user that triggers the job must be a member of your project.
- The user must have the [permissions](../../user/permissions.md) to perform the action.
- The accessed project must have the project attempting to access it [added to the allowlist](#add-a-project-to-the-job-token-scope-allowlist).
If a job token is leaked, it could potentially be used to access private data
to the job token's user. By limiting the job token access scope, project data cannot
be accessed unless projects are explicitly authorized.
If your project is public or internal, some publicly accessible resources can be accessed
with a job token from any project. These resources can also be [limited to only projects on the allowlist](#limit-job-token-scope-for-public-or-internal-projects).
There is a proposal to add more strategic control of the access permissions,
see [epic 3559](https://gitlab.com/groups/gitlab-org/-/epics/3559).
NOTE:
Because `CI_REGISTRY_PASSWORD` uses `CI_JOB_TOKEN` to authenticate, the access configuration
also applies to `CI_REGISTRY_PASSWORD`.
### Allow access to your project with a job token
### Add a project to the job token allowlist
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/346298/) in GitLab 15.9. [Deployed behind the `:inbound_ci_scoped_job_token` feature flag](../../user/feature_flags.md), enabled by default.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/346298/) in GitLab 15.10.
> - **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
Create an allowlist of projects which can access your project through
their `CI_JOB_TOKEN`.
You can add projects to your job token allowlist to allow access your project's resources
with a job token for authentication. By default, the allowlist of any project only includes itself.
For example, project `A` can add project `B` to the allowlist. CI/CD jobs
in project `B` (the "allowed project") can now use their CI/CD job token to
authenticate API calls to access project `A`.
For example, project A can add project B to project A's allowlist. CI/CD jobs
in project B (the "allowed project") can now use CI/CD job tokens to
authenticate API calls to access project A.
By default, the allowlist of any project only includes itself.
Add projects to the allowlist only when cross-project access is needed.
It is a security risk to disable this feature, so project maintainers or owners should
keep this setting enabled at all times. Add projects to the allowlist only when cross-project
access is needed.
Prerequisites:
- You must have at least the Maintainer role in the current project. If the allowed project
is internal or private, you must have at least the Guest role in that project.
- You must not have more than 200 projects added to the allowlist.
To add a project to the allowlist:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Settings > CI/CD**.
1. Expand **Token Access**.
1. Ensure the **Limit access _to_ this project** toggle is enabled. Enabled by default in new projects.
It is a security risk to disable this feature, so project maintainers or owners should
keep this setting enabled at all times.
1. Select **Add project**.
1. Input the path to the project to add to the allowlist, and select **Add project**.
You can also add a project to the allowlist [with the API](../../api/graphql/reference/index.md#mutationcijobtokenscopeaddproject).
### Limit job token scope for public or internal projects
Projects can use a job token to authenticate with public or internal projects for
the following actions without being added to the allowlist:
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/405369) in GitLab 16.6.
- Fetch artifacts
- Access the container registry
- Access the package registry
- Access releases, deployments, and environments
Projects not in the allowlist can use a job token to authenticate with public or internal projects to:
To limit access to these actions to only the projects on the allowlist, set the visibility
of each feature to be only accessible to project members:
- Fetch artifacts.
- Access the container registry.
- Access the package registry.
- Access releases, deployments, and environments.
You can limit access to these actions to only the projects on the allowlist by setting
each feature to be only visible to project members.
Prerequisites:
- You must have the Maintainer role for the project.
To set a feature to be only visible to project members:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Settings > General**.
1. Expand **Visibility, project features, permissions**.
@ -135,19 +143,21 @@ Prerequisites:
- The ability to fetch artifacts is controlled by the CI/CD visibility setting.
1. Select **Save changes**.
Triggering pipelines and fetching Terraform plans is not affected by feature visibility.
### Disable the job token scope allowlist
### Allow any project to access your project
> - **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
WARNING:
It is a security risk to disable the allowlist. A malicious user could try to compromise
It is a security risk to disable the token access limit and allowlist. A malicious user could try to compromise
a pipeline created in an unauthorized project. If the pipeline was created by one of
your maintainers, the job token could be used in an attempt to access your project.
You can disable the job token scope allowlist for testing or a similar reason,
but you should enable it again as soon as possible.
If you disable the **Limit access _to_ this project** setting, the allowlist is ignored.
Jobs from any project could access your project with a job token if the user that
triggers the pipeline has permission to access your project.
You should only disable this setting for testing or a similar reason,
and you should enable it again as soon as possible.
Prerequisites:
@ -161,41 +171,31 @@ To disable the job token scope allowlist:
1. Toggle **Limit access _to_ this project** to disabled.
Enabled by default in new projects.
You can also disable the allowlist [with the API](../../api/graphql/reference/index.md#mutationprojectcicdsettingsupdate).
You can also enable and disable the setting [with the API](../../api/graphql/reference/index.md#mutationprojectcicdsettingsupdate).
### Add a project to the job token scope allowlist
## Use a job token to clone a private project's repository
> - **Allow access to this project with a CI_JOB_TOKEN** setting [renamed to **Limit access _to_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
You can use the job token to authenticate and clone a repository from a private project
in a CI/CD job. For example:
You can add projects to the allowlist for a project. Projects added to the allowlist
can make API calls from running pipelines by using the CI/CD job token.
```shell
git clone https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/<namespace>/<project>
```
Prerequisites:
You can't use a job token to push to a repository, but [issue 389060](https://gitlab.com/gitlab-org/gitlab/-/issues/389060)
proposes to change this behavior.
- You must have at least the Maintainer role in the current project. If the allowed project
is internal or private, you must have at least the Guest role in that project.
- You must not have more than 200 projects added to the allowlist.
To add a project:
1. On the left sidebar, select **Search or go to** and find your project.
1. Select **Settings > CI/CD**.
1. Expand **Token Access**.
1. Verify **Limit access _to_ this project** is enabled.
1. Under **Allow CI job tokens from the following projects to access this project**,
add projects to the allowlist.
You can also add a target project to the allowlist [with the API](../../api/graphql/reference/index.md#mutationcijobtokenscopeaddproject).
### Limit your project's job token access
## Limit your project's job token access (deprecated)
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/328553) in GitLab 14.1. [Deployed behind the `:ci_scoped_job_token` feature flag](../../user/feature_flags.md), disabled by default.
> - [Enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/332272) in GitLab 14.4.
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/332272) in GitLab 14.6.
NOTE:
This feature is disabled by default for all new projects and is [scheduled for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/383084)
in GitLab 17.0. Project maintainers or owners should enable the access control instead.
The [**Limit access _from_ this project**](#configure-the-job-token-scope-deprecated)
setting is disabled by default for all new projects and is [scheduled for removal](https://gitlab.com/gitlab-org/gitlab/-/issues/383084)
in GitLab 17.0. Project maintainers or owners should configure the [**Limit access _to_ this project**](#add-a-project-to-the-job-token-allowlist)
setting instead.
Control your project's job token scope by creating an allowlist of projects which
can be accessed by your project's job token.
@ -210,7 +210,7 @@ For example, when the setting is enabled, jobs in a pipeline in project `A` have
a `CI_JOB_TOKEN` scope limited to project `A`. If the job needs to use the token
to make an API request to project `B`, then `B` must be added to the allowlist for `A`.
### Configure the job token scope
### Configure the job token scope (deprecated)
> - **Limit CI_JOB_TOKEN access** setting [renamed to **Limit access _from_ this project**](https://gitlab.com/gitlab-org/gitlab/-/issues/411406) in GitLab 16.3.
@ -227,24 +227,6 @@ To configure the job token scope:
1. Optional. Add existing projects to the token's access scope. The user adding a
project must have the Maintainer role in both projects.
## Download an artifact from a different pipeline
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
You can use the CI/CD job token to authenticate with the [jobs artifacts API endpoint](../../api/job_artifacts.md)
and fetch artifacts from a different pipeline. You must specify which job to retrieve artifacts from:
```yaml
build_submodule:
stage: test
script:
- apt update && apt install -y unzip
- curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
- unzip artifacts.zip
```
## Troubleshooting
CI job token failures are usually shown as responses like `404 Not Found` or similar:

19
doc/ci/jobs/job_artifacts.md
View File

@ -256,6 +256,25 @@ Artifacts for [parent and child pipelines](../pipelines/downstream_pipelines.md#
are searched in hierarchical order from parent to child. For example, if both parent and
child pipelines have a job with the same name, the job artifacts from the parent pipeline are returned.
### With a CI/CD job token
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
You can use a [CI/CD job token](ci_job_token.md) to authenticate with the [jobs artifacts API endpoint](../../api/job_artifacts.md)
and fetch artifacts from a different pipeline. You must specify which job to retrieve artifacts from,
for example:
```yaml
build_submodule:
stage: test
script:
- apt update && apt install -y unzip
- curl --location --output artifacts.zip "https://gitlab.example.com/api/v4/projects/1/jobs/artifacts/main/download?job=test&job_token=$CI_JOB_TOKEN"
- unzip artifacts.zip
```
## Browse the contents of the artifacts archive
You can browse the contents of the artifacts from the UI without downloading the artifact locally,

6
doc/ci/pipelines/downstream_pipelines.md
View File

@ -446,7 +446,7 @@ upstream pipeline:
Use [`needs:project`](../yaml/index.md#needsproject) to fetch artifacts from an
upstream pipeline:
1. In GitLab 15.9 and later, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-scope-allowlist) of the upstream project.
1. In GitLab 15.9 and later, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) of the upstream project.
1. In the upstream pipeline, save the artifacts in a job with the [`artifacts`](../yaml/index.md#artifacts)
keyword, then trigger the downstream pipeline with a trigger job:
@ -499,7 +499,7 @@ because the downstream pipeline attempts to fetch artifacts from the latest bran
To fetch the artifacts from the upstream `merge request` pipeline instead of the `branch` pipeline,
pass `CI_MERGE_REQUEST_REF_PATH` to the downstream pipeline using [variable inheritance](#pass-yaml-defined-cicd-variables):
1. In GitLab 15.9 and later, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-scope-allowlist) of the upstream project.
1. In GitLab 15.9 and later, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist) of the upstream project.
1. In a job in the upstream pipeline, save the artifacts using the [`artifacts`](../yaml/index.md#artifacts) keyword.
1. In the job that triggers the downstream pipeline, pass the `$CI_MERGE_REQUEST_REF_PATH` variable:
@ -843,4 +843,4 @@ Only trigger multi-project pipelines with tag names that do not match branch nam
In GitLab 15.9 and later, CI/CD job tokens are scoped to the project that the pipeline executes under. Therefore, the job token in a downstream pipeline cannot be used to access an upstream project by default.
To resolve this, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-scope-allowlist).
To resolve this, [add the downstream project to the job token scope allowlist](../jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist).

8
doc/update/deprecations.md
View File

@ -233,7 +233,7 @@ From GitLab 18.0 and later, the runner registration methods implemented by the n
The `direction` GraphQL argument for the `ciJobTokenScopeRemoveProject` mutation is deprecated. Following the [default CI/CD job token scope change](https://docs.gitlab.com/ee/update/deprecations.html#default-cicd-job-token-ci_job_token-scope-changed) announced in GitLab 15.9, the `direction` argument will default to `INBOUND` and `OUTBOUND` will no longer be valid in GitLab 17.0. We will remove the `direction` argument in GitLab 18.0.
If you are using `OUTBOUND` with the `direction` argument to control the direction of your project's token access, your pipeline that use job tokens risk failing authentication. To ensure pipelines continue to run as expected, you will need to explicitly [add the other projects to your project's allowlist](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-scope-allowlist).
If you are using `OUTBOUND` with the `direction` argument to control the direction of your project's token access, your pipeline that use job tokens risk failing authentication. To ensure pipelines continue to run as expected, you will need to explicitly [add the other projects to your project's allowlist](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist).
</div>
@ -407,7 +407,7 @@ These three variables will be removed in GitLab 17.0.
In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You can prevent job tokens **from your project's** pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines cannot access other projects. To use the job token to access other projects from your pipeline, you must list those projects explicitly in the **Limit CI_JOB_TOKEN access** setting's allowlist, and you must be a maintainer in all the projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The **Limit** setting was deprecated in 16.0 in preference of the better **Allow access** setting and **Limit** setting was disabled by default for all new projects. From this point forward, if the **Limit** setting is disabled in any project, it will not be possible to re-enable this setting in 16.0 or later.
@ -1858,7 +1858,7 @@ Any API calls to change the rate limits for `user_email_lookup_limit` must use `
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/420678).
</div>
Starting in 16.6, projects that are **public** or **internal** will no longer authorize job token requests from projects that are **not** on the project's allowlist when [**Limit access to this project**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token) is enabled.
Starting in 16.6, projects that are **public** or **internal** will no longer authorize job token requests from projects that are **not** on the project's allowlist when [**Limit access to this project**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist) is enabled.
If you have [public or internal](https://docs.gitlab.com/ee/user/public_access.html#change-project-visibility) projects with the **Limit access to this project** setting enabled, you must add any projects which make job token requests to your project's allowlist for continued authorization.
@ -2308,7 +2308,7 @@ These three variables will be removed in GitLab 16.0.
In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You can prevent job tokens **from your project's** pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines cannot access other projects. To use the job token to access other projects from your pipeline, you must list those projects explicitly in the **Limit CI_JOB_TOKEN access** setting's allowlist, and you must be a maintainer in all the projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#add-a-project-to-the-job-token-allowlist). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
As a result, the **Limit** setting is deprecated in preference of the better **Allow access** setting. In GitLab 16.0 the **Limit** setting will be disabled by default for all new projects. In projects with this setting currently enabled, it will continue to function as expected, but you will not be able to add any more projects to the allowlist. If the setting is disabled in any project, it will not be possible to re-enable this setting in 16.0 or later.

5
doc/user/analytics/value_streams_dashboard.md
View File

@ -59,10 +59,11 @@ The contributor count metric is available only on GitLab.com at the group-level.
### DORA Performers score panel
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386843) in GitLab 16.2 [with a flag](../../administration/feature_flags.md) named `dora_performers_score_panel`. Disabled by default.
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386843) in GitLab 16.3 [with a flag](../../administration/feature_flags.md) named `dora_performers_score_panel`. Disabled by default.
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/439737) in GitLab 16.9.
FLAG:
By default this feature is not available. To make it available, an administrator can [enable the feature flag](../../administration/feature_flags.md) named `dora_performers_score_panel`.
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 `dora_performers_score_panel`.
The [DORA metrics](dora_metrics.md) Performers score panel is a bar chart that visualizes the status of the organization's DevOps performance levels across different projects.

1
doc/user/application_security/policies/scan-execution-policies.md
View File

@ -382,6 +382,7 @@ Note the following:
- For `custom` scans, you must specify one of `ci_configuration` or `ci_configuration_path`.
- `custom` scans are being executed for triggered rules only.
- Jobs variables from `custom` scans take precedence over the project's CI/CD configuration.
- Users triggering a pipeline must have at least read access to CI files specified in the `ci_configuration_path` or included in the CI/CD configuration.
#### Example security policies project

2
doc/user/packages/workflows/project_registry.md
View File

@ -45,7 +45,7 @@ Let's take a look at how you might create one project to host all of your packag
- A [personal access token](../../profile/personal_access_tokens.md).
- A [CI/CD job token](../../../ci/jobs/ci_job_token.md) (`CI_JOB_TOKEN`) in a CI/CD job.
Any projects publishing packages to this project's registry should be listed
in this project's [job token allowlist](../../../ci/jobs/ci_job_token.md#allow-access-to-your-project-with-a-job-token).
in this project's [job token allowlist](../../../ci/jobs/ci_job_token.md#add-a-project-to-the-job-token-allowlist).
If the project is private, downloading packages requires authentication as well.

5
gems/gitlab-housekeeper/lib/gitlab/housekeeper/change.rb
View File

@ -10,6 +10,11 @@ module Gitlab
:labels,
:reviewers
def initialize
@labels = []
@reviewers = []
end
def mr_description
<<~MARKDOWN
#{description}

9
gems/gitlab-housekeeper/spec/gitlab/housekeeper/change_spec.rb
View File

@ -10,6 +10,15 @@ RSpec.describe ::Gitlab::Housekeeper::Change do
change.description = 'The description'
end
describe '#initialize' do
it 'sets default values for optional fields' do
change = described_class.new
expect(change.labels).to eq([])
expect(change.reviewers).to eq([])
end
end
describe '#mr_description' do
it 'includes standard content' do
expect(change.mr_description).to eq(

21
lib/gitlab/gitaly_client/cleanup_service.rb
View File

@ -3,6 +3,7 @@
module Gitlab
module GitalyClient
class CleanupService
include Gitlab::EncodingHelper
include WithFeatureFlagActors
attr_reader :repository, :gitaly_repo, :storage
@ -27,6 +28,26 @@ module Gitlab
response.each(&blk)
end
def rewrite_history(blobs: [], redactions: [])
req_enum = Enumerator.new do |y|
first_request = Gitaly::RewriteHistoryRequest.new(repository: @gitaly_repo)
y.yield(first_request)
blobs.each_slice(100) do |b|
y.yield Gitaly::RewriteHistoryRequest.new(blobs: b)
end
redactions.map { |r| encode_binary(r) }.each_slice(100) do |r|
y.yield Gitaly::RewriteHistoryRequest.new(redactions: r)
end
end
gitaly_client_call(@repository.storage, :cleanup_service, :rewrite_history, req_enum,
timeout: GitalyClient.long_timeout)
rescue GRPC::InvalidArgument => e
raise ArgumentError, e.message
end
private
def build_object_map_enum(io)

2
locale/gitlab.pot
View File

@ -36694,7 +36694,7 @@ msgstr ""
msgid "Pipeline|This pipeline ran on the contents of the merge request's source branch, not the target branch."
msgstr ""
msgid "Pipeline|To run a merge request pipeline, the jobs in the CI/CD configuration file %{linkStart}must be configured%{linkEnd} to run in merge request pipelines."
msgid "Pipeline|To run a merge request pipeline, the jobs in the CI/CD configuration file %{ciDocsLinkStart}must be configured%{ciDocsLinkEnd} to run in merge request pipelines and you must have %{permissionDocsLinkStart}sufficient permissions%{permissionDocsLinkEnd} in the source project."
msgstr ""
msgid "Pipeline|To see the remaining jobs, go to the %{boldStart}Jobs%{boldEnd} tab."

2
qa/Gemfile
View File

@ -10,7 +10,7 @@ gem 'allure-rspec', '~> 2.23.0'
gem 'capybara', '~> 3.39.2'
gem 'capybara-screenshot', '~> 1.0.26'
gem 'rake', '~> 13', '>= 13.1.0'
gem 'rspec', '~> 3.12'
gem 'rspec', '~> 3.13'
gem 'selenium-webdriver', '= 4.17.0'
gem 'airborne', '~> 0.3.7', require: false # airborne is messing with rspec sandboxed mode so not requiring by default
gem 'rest-client', '~> 2.1.0'

24
qa/Gemfile.lock
View File

@ -264,18 +264,18 @@ GEM
retriable (3.1.2)
rexml (3.2.5)
rotp (6.3.0)
rspec (3.12.0)
rspec-core (~> 3.12.0)
rspec-expectations (~> 3.12.0)
rspec-mocks (~> 3.12.0)
rspec-core (3.12.0)
rspec-support (~> 3.12.0)
rspec-expectations (3.12.0)
rspec (3.13.0)
rspec-core (~> 3.13.0)
rspec-expectations (~> 3.13.0)
rspec-mocks (~> 3.13.0)
rspec-core (3.13.0)
rspec-support (~> 3.13.0)
rspec-expectations (3.13.0)
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (~> 3.12.0)
rspec-mocks (3.12.6)
rspec-support (~> 3.13.0)
rspec-mocks (3.13.0)
diff-lcs (>= 1.2.0, < 2.0)
rspec-support (~> 3.12.0)
rspec-support (~> 3.13.0)
rspec-parameterized (1.0.0)
rspec-parameterized-core (< 2)
rspec-parameterized-table_syntax (< 2)
@ -289,7 +289,7 @@ GEM
rspec-parameterized-core (< 2)
rspec-retry (0.6.2)
rspec-core (> 3.3)
rspec-support (3.12.0)
rspec-support (3.13.0)
rspec_junit_formatter (0.6.0)
rspec-core (>= 2, < 4, != 2.12.0)
ruby-debug-ide (0.7.3)
@ -371,7 +371,7 @@ DEPENDENCIES
rake (~> 13, >= 13.1.0)
rest-client (~> 2.1.0)
rotp (~> 6.3.0)
rspec (~> 3.12)
rspec (~> 3.13)
rspec-parameterized (~> 1.0.0)
rspec-retry (~> 0.6.2)
rspec_junit_formatter (~> 0.6.0)

1
qa/qa/page/project/new.rb
View File

@ -23,7 +23,6 @@ module QA
end
view 'app/views/projects/project_templates/_template.html.haml' do
element 'use-template-button'
element 'template-option-container'
end

2
qa/qa/tools/reliable_report.rb
View File

@ -606,7 +606,7 @@ module QA
r.merge_request == "false" and
r.quarantined == "false" and
r.smoke == "false" and
r.reliable == "#{reliable}"
(r.reliable == "#{reliable}" #{reliable ? 'or' : 'and'} r.blocking == "#{reliable}")
)
|> filter(fn: (r) => r["_field"] == "job_url" or
r["_field"] == "failure_exception" or

2
qa/spec/tools/reliable_report_spec.rb
View File

@ -148,7 +148,7 @@ describe QA::Tools::ReliableReport do
r.merge_request == "false" and
r.quarantined == "false" and
r.smoke == "false" and
r.reliable == "#{reliable}"
(r.reliable == "#{reliable}" #{reliable ? 'or' : 'and'} r.blocking == "#{reliable}")
)
|> filter(fn: (r) => r["_field"] == "job_url" or
r["_field"] == "failure_exception" or

4
spec/features/projects/new_project_spec.rb
View File

@ -63,7 +63,7 @@ RSpec.describe 'New project', :js, feature_category: :groups_and_projects do
click_link 'Create from template'
page.within('#create-from-template-pane') do
find("[data-testid='use_template_#{Gitlab::ProjectTemplate.localized_templates_table.first.name}']").click
find_by_testid("use-template-#{Gitlab::ProjectTemplate.localized_templates_table.first.name}").click
expect(page).to have_content(description_label)
end
@ -284,7 +284,7 @@ RSpec.describe 'New project', :js, feature_category: :groups_and_projects do
it 'does not show the initialize with Readme checkbox on "Create from template" tab' do
visit new_project_path
click_link 'Create from template'
first('.choose-template').click
click_link_or_button('Use template', match: :first)
page.within '.project-fields-form' do
expect(page).not_to have_css('input#project_initialize_with_readme')

4
spec/features/projects_spec.rb
View File

@ -18,14 +18,14 @@ RSpec.describe 'Project', feature_category: :source_code_management do
shared_examples 'creates from template' do |template, sub_template_tab = nil|
let(:selected_template) { page.find('.project-fields-form .selected-template') }
choose_template_selector = '.choose-template'
choose_template_selector = '.js-use-template-button'
template_option_selector = '.template-option'
template_name_selector = '.description strong'
it "is created from template", :js do
click_link 'Create from template'
find(".project-template #{sub_template_tab}").click if sub_template_tab
find("label[for=#{template.name}]").click
find("button[data-template-name=#{template.name}]").click
fill_in("project_name", with: template.name)
page.within '#content-body' do

7
spec/frontend/commit/pipelines/legacy_pipelines_table_wrapper_spec.js
View File

@ -39,6 +39,7 @@ describe('Pipelines table in Commits and Merge requests', () => {
const findTableRows = () => wrapper.findAllByTestId('pipeline-table-row');
const findModal = () => wrapper.findComponent(GlModal);
const findMrPipelinesDocsLink = () => wrapper.findByTestId('mr-pipelines-docs-link');
const findUserPermissionsDocsLink = () => wrapper.findByTestId('user-permissions-docs-link');
const findPipelinesTable = () => wrapper.findComponent(PipelinesTable);
const createComponent = ({ props = {}, mountFn = mountExtended } = {}) => {
@ -91,8 +92,12 @@ describe('Pipelines table in Commits and Merge requests', () => {
expect(findMrPipelinesDocsLink().attributes('href')).toBe(
'/help/ci/pipelines/merge_request_pipelines.md#prerequisites',
);
expect(findUserPermissionsDocsLink().attributes('href')).toBe(
'/help/user/permissions.md#gitlab-cicd-permissions',
);
expect(findEmptyState().text()).toContain(
'To run a merge request pipeline, the jobs in the CI/CD configuration file must be configured to run in merge request pipelines.',
'To run a merge request pipeline, the jobs in the CI/CD configuration file must be configured to run in merge request pipelines ' +
'and you must have sufficient permissions in the source project.',
);
});
});

69
spec/lib/gitlab/gitaly_client/cleanup_service_spec.rb
View File

@ -2,7 +2,7 @@
require 'spec_helper'
RSpec.describe Gitlab::GitalyClient::CleanupService do
RSpec.describe Gitlab::GitalyClient::CleanupService, feature_category: :gitaly do
let(:project) { create(:project) }
let(:storage_name) { project.repository_storage }
let(:relative_path) { project.disk_path + '.git' }
@ -23,4 +23,71 @@ RSpec.describe Gitlab::GitalyClient::CleanupService do
client.apply_bfg_object_map_stream(StringIO.new)
end
end
describe '#rewrite_history' do
let(:blobs) { ['53855584db773c3df5b5f61f72974cb298822fbb'] }
let(:redactions) { %w[hello world] }
before do
::Gitlab::GitalyClient.clear_stubs!
end
subject(:rewrite_history) { client.rewrite_history(blobs: blobs, redactions: redactions) }
it 'sends a rewrite_history message' do
expect_next_instance_of(Gitaly::CleanupService::Stub) do |instance|
expect(instance).to receive(:rewrite_history)
.with(array_including(
gitaly_request_with_params(blobs: blobs),
gitaly_request_with_params(redactions: redactions)
), kind_of(Hash))
.and_return(Gitaly::RewriteHistoryResponse.new)
end
rewrite_history
end
context 'with a generic BadStatus error' do
let(:generic_error) do
GRPC::BadStatus.new(
GRPC::Core::StatusCodes::FAILED_PRECONDITION,
"error message"
)
end
it 'raises the BadStatus error' do
expect_next_instance_of(Gitaly::CleanupService::Stub) do |instance|
expect(instance).to receive(:rewrite_history)
.with(array_including(
gitaly_request_with_params(blobs: blobs),
gitaly_request_with_params(redactions: redactions)
), kind_of(Hash))
.and_raise(generic_error)
end
expect { rewrite_history }.to raise_error(GRPC::BadStatus)
end
end
context 'with an empty request' do
let(:blobs) { [] }
let(:redactions) { [] }
let(:empty_error) do
GRPC::InvalidArgument.new('no object IDs or text replacements specified')
end
it 'raises an InvalidArgument error' do
expect_next_instance_of(Gitaly::CleanupService::Stub) do |instance|
expect(instance).to receive(:rewrite_history)
.with(array_including(
gitaly_request_with_params(blobs: blobs),
gitaly_request_with_params(redactions: redactions)
), kind_of(Hash))
.and_raise(empty_error)
end
expect { rewrite_history }.to raise_error(ArgumentError, '3:no object IDs or text replacements specified')
end
end
end
end