Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
4c9e62ad5f
commit
3104fdfb6b
|
|
@ -1701,6 +1701,9 @@
|
|||
# Run tests automatically for MRs that touch QA files
|
||||
- <<: *if-merge-request
|
||||
changes: *qa-patterns
|
||||
# Run tests automatically for MRS that touch GITALY_SERVER_VERSION
|
||||
- <<: *if-merge-request
|
||||
changes: *gitaly-patterns
|
||||
# Otherwise, only run tests after the MR is approved
|
||||
- <<: *if-merge-request-not-approved
|
||||
when: never
|
||||
|
|
|
|||
|
|
@ -15,6 +15,8 @@ import {
|
|||
GlModal,
|
||||
GlModalDirective,
|
||||
GlSprintf,
|
||||
GlFormRadio,
|
||||
GlFormRadioGroup,
|
||||
} from '@gitlab/ui';
|
||||
import { __, s__, sprintf } from '~/locale';
|
||||
import { DRAWER_Z_INDEX } from '~/lib/utils/constants';
|
||||
|
|
@ -55,16 +57,19 @@ export const i18n = {
|
|||
expandedField: s__('CiVariables|Expand variable reference'),
|
||||
expandedDescription: EXPANDED_VARIABLES_NOTE,
|
||||
flags: __('Flags'),
|
||||
visibility: __('Visibility'),
|
||||
flagsLinkTitle: FLAG_LINK_TITLE,
|
||||
key: __('Key'),
|
||||
keyFeedback: s__("CiVariables|A variable key can only contain letters, numbers, and '_'."),
|
||||
keyHelpText: s__(
|
||||
'CiVariables|You can use CI/CD variables with the same name in different places, but the variables might overwrite each other. %{linkStart}What is the order of precedence for variables?%{linkEnd}',
|
||||
),
|
||||
maskedField: s__('CiVariables|Mask variable'),
|
||||
maskedField: s__('CiVariables|Masked'),
|
||||
visibleField: s__('CiVariables|Visible'),
|
||||
maskedDescription: s__(
|
||||
'CiVariables|Variable will be masked in job logs. Requires values to meet regular expression requirements.',
|
||||
'CiVariables|Masked in job logs but value can be revealed in CI/CD settings. Requires values to meet regular expressions requirements.',
|
||||
),
|
||||
visibleDescription: s__('CiVariables|Can be seen in job logs.'),
|
||||
maskedValueMinLengthValidationText: s__(
|
||||
'CiVariables|The value must have at least %{charsAmount} characters.',
|
||||
),
|
||||
|
|
@ -112,6 +117,8 @@ export default {
|
|||
GlLink,
|
||||
GlModal,
|
||||
GlSprintf,
|
||||
GlFormRadio,
|
||||
GlFormRadioGroup,
|
||||
},
|
||||
directives: {
|
||||
GlModalDirective,
|
||||
|
|
@ -464,6 +471,23 @@ export default {
|
|||
readonly
|
||||
/>
|
||||
</gl-form-group>
|
||||
<gl-form-group class="gl-border-none -gl-mb-3">
|
||||
<template #label>
|
||||
<div class="gl-mb-n3">
|
||||
{{ $options.i18n.visibility }}
|
||||
</div>
|
||||
</template>
|
||||
<gl-form-radio-group v-model="variable.masked" data-testid="ci-variable-masked">
|
||||
<gl-form-radio :value="false" data-testid="ci-variable-visible-radio">
|
||||
{{ $options.i18n.visibleField }}
|
||||
<template #help> {{ $options.i18n.visibleDescription }} </template>
|
||||
</gl-form-radio>
|
||||
<gl-form-radio :value="true" data-testid="ci-variable-masked-radio">
|
||||
{{ $options.i18n.maskedField }}
|
||||
<template #help> {{ $options.i18n.maskedDescription }} </template>
|
||||
</gl-form-radio>
|
||||
</gl-form-radio-group>
|
||||
</gl-form-group>
|
||||
<gl-form-group class="gl-border-none -gl-mb-8">
|
||||
<template #label>
|
||||
<div class="gl-display-flex gl-align-items-center -gl-mb-3">
|
||||
|
|
@ -487,10 +511,6 @@ export default {
|
|||
{{ $options.i18n.protectedDescription }}
|
||||
</p>
|
||||
</gl-form-checkbox>
|
||||
<gl-form-checkbox v-model="variable.masked" data-testid="ci-variable-masked-checkbox">
|
||||
{{ $options.i18n.maskedField }}
|
||||
<p class="gl-text-secondary">{{ $options.i18n.maskedDescription }}</p>
|
||||
</gl-form-checkbox>
|
||||
<gl-form-checkbox
|
||||
data-testid="ci-variable-expanded-checkbox"
|
||||
:checked="isExpanded"
|
||||
|
|
|
|||
|
|
@ -101,11 +101,12 @@ module DesignManagement
|
|||
|
||||
CREATION_TTL = 5.seconds
|
||||
RETRY_DELAY = ->(num) { 0.2.seconds * (num**2) }
|
||||
LOCK_RETRY_COUNT = 5
|
||||
|
||||
def self.with_lock(project_id, repository, &block)
|
||||
key = "with_lock:#{name}:{#{project_id}}"
|
||||
|
||||
in_lock(key, ttl: CREATION_TTL, retries: 5, sleep_sec: RETRY_DELAY) do |_retried|
|
||||
in_lock(key, ttl: CREATION_TTL, retries: LOCK_RETRY_COUNT, sleep_sec: RETRY_DELAY) do |_retried|
|
||||
repository.create_if_not_exists
|
||||
yield
|
||||
end
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ class ProjectSetting < ApplicationRecord
|
|||
validates :issue_branch_template, length: { maximum: Issue::MAX_BRANCH_TEMPLATE }
|
||||
validates :target_platforms, inclusion: { in: ALLOWED_TARGET_PLATFORMS }
|
||||
validates :suggested_reviewers_enabled, inclusion: { in: [true, false] }
|
||||
ignore_column :code_suggestions, remove_with: '16.11', remove_after: '2024-03-21'
|
||||
ignore_column :code_suggestions, remove_with: '17.0', remove_after: '2024-03-21'
|
||||
|
||||
validates :pages_unique_domain,
|
||||
uniqueness: { if: -> { pages_unique_domain.present? } },
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ name: ci_canceling_status
|
|||
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/399215
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140522
|
||||
rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17520
|
||||
milestone: '16.10'
|
||||
milestone: '17.0'
|
||||
group: group::pipeline execution
|
||||
type: wip
|
||||
default_enabled: false
|
||||
type: beta
|
||||
default_enabled: true
|
||||
|
|
@ -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#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 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-group-or-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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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#add-a-project-to-the-job-token-allowlist) 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-group-or-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,7 +2,7 @@
|
|||
# REQUIRED FIELDS
|
||||
#
|
||||
- title: "The `ci_job_token_scope_enabled` projects API attribute is deprecated" # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
|
||||
removal_milestone: "17.0" # (required) The milestone when this feature is planned to be removed
|
||||
removal_milestone: "18.0" # (required) The milestone when this feature is planned to be removed
|
||||
announcement_milestone: "16.4" # (required) The milestone when this feature was first announced as deprecated.
|
||||
breaking_change: true # (required) Change to false if this is not a breaking change.
|
||||
reporter: jocelynjane # (required) GitLab username of the person reporting the change
|
||||
|
|
|
|||
|
|
@ -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#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 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-group-or-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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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-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-group-or-project-to-the-job-token-allowlist).
|
||||
|
||||
# ==============================
|
||||
# OPTIONAL END-OF-SUPPORT FIELDS
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class RemoveCodeSuggestionsEnabledProjectSetting < Gitlab::Database::Migration[2.2]
|
||||
milestone '16.10'
|
||||
|
||||
def up
|
||||
remove_column :project_settings, :code_suggestions
|
||||
end
|
||||
|
||||
def down
|
||||
add_column :project_settings, :code_suggestions, :boolean, default: true, null: false
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
a69f6167deebdfeb807eabb662ec917b3154905c9caa487d030ac07152885321
|
||||
|
|
@ -14643,7 +14643,6 @@ CREATE TABLE project_settings (
|
|||
encrypted_product_analytics_configurator_connection_string_iv bytea,
|
||||
pages_multiple_versions_enabled boolean DEFAULT false NOT NULL,
|
||||
allow_merge_without_pipeline boolean DEFAULT false NOT NULL,
|
||||
code_suggestions boolean DEFAULT true NOT NULL,
|
||||
duo_features_enabled boolean DEFAULT true NOT NULL,
|
||||
require_reauthentication_to_approve boolean,
|
||||
CONSTRAINT check_1a30456322 CHECK ((char_length(pages_unique_domain) <= 63)),
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ job2:
|
|||
DETAILS:
|
||||
**Offering:** GitLab.com, Self-managed
|
||||
|
||||
> - [Introduced on self-managed](https://gitlab.com/groups/gitlab-org/-/epics/10158) in GitLab 17.0 [with a flag](../../administration/feature_flags.md) named `ci_canceling_status`. Disabled by default.
|
||||
> - [Introduced on self-managed](https://gitlab.com/groups/gitlab-org/-/epics/10158) in GitLab 17.0 [with a flag](../../administration/feature_flags.md) named `ci_canceling_status`. Enabled by default.
|
||||
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17520) in GitLab 17.0.
|
||||
|
||||
FLAG:
|
||||
|
|
@ -122,7 +122,7 @@ The job status displayed in the UI will be `canceling` while the `after_script`
|
|||
|
||||
- GitLab Runner 16.11.1 and above are recommended to support this feature:
|
||||
- In the GitLab Runner 16.11.1 patch release, [`canceled` is supported for `$CI_JOB_STATUS`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/37485). Before the patch release, the status will be `failed` while `canceling`.
|
||||
- In the GitLab Runner 16.11.1 patch release, a bug fix caused the `after_script` work to close pre-maturely.
|
||||
- Prior to the GitLab Runner 16.11.1 patch release, a bug caused the `after_script` work to close pre-maturely.
|
||||
- For shared runners on GitLab.com, the `ci_canceling_status` flag will be turned on during the last breaking change window on May 8th while runner is on patch version 16.11.1 or above.
|
||||
- For self-managed, the `ci_canceling_status` flag will be enabled by default in 17.0 and can be disabled in case administrators need to revert to the old behavior. This flag could be removed in the next milestone and should not be relied on for long-term use.
|
||||
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ The change will be introduced in GitLab 16.6 behind a feature flag. If you are i
|
|||
|
||||
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#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 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-group-or-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.
|
||||
|
||||
|
|
@ -549,6 +549,20 @@ The `Project.services` GraphQL field is deprecated. A `Project.integrations` fie
|
|||
|
||||
<div class="deprecation breaking-change" data-milestone="18.0">
|
||||
|
||||
### The `ci_job_token_scope_enabled` projects API attribute is deprecated
|
||||
|
||||
<div class="deprecation-notes">
|
||||
- Announced in GitLab <span class="milestone">16.4</span>
|
||||
- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423091).
|
||||
</div>
|
||||
|
||||
GitLab 16.1 introduced [API endpoints for the job token scope](https://gitlab.com/gitlab-org/gitlab/-/issues/351740). In the [projects API](https://docs.gitlab.com/ee/api/projects.html), the `ci_job_token_scope_enabled` attribute is deprecated, and will be removed in 17.0. You should use the [job token scope APIs](https://docs.gitlab.com/ee/api/project_job_token_scopes.html) instead.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change" data-milestone="18.0">
|
||||
|
||||
### The `direction` GraphQL argument for `ciJobTokenScopeRemoveProject` is deprecated
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
|
@ -559,7 +573,7 @@ The `Project.services` GraphQL field is deprecated. A `Project.integrations` fie
|
|||
|
||||
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-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-group-or-project-to-the-job-token-allowlist).
|
||||
|
||||
</div>
|
||||
|
||||
|
|
@ -2064,20 +2078,6 @@ Due to limited customer usage and capabilities, the Visual Reviews feature for R
|
|||
|
||||
<div class="deprecation breaking-change" data-milestone="17.0">
|
||||
|
||||
### The `ci_job_token_scope_enabled` projects API attribute is deprecated
|
||||
|
||||
<div class="deprecation-notes">
|
||||
- Announced in GitLab <span class="milestone">16.4</span>
|
||||
- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423091).
|
||||
</div>
|
||||
|
||||
GitLab 16.1 introduced [API endpoints for the job token scope](https://gitlab.com/gitlab-org/gitlab/-/issues/351740). In the [projects API](https://docs.gitlab.com/ee/api/projects.html), the `ci_job_token_scope_enabled` attribute is deprecated, and will be removed in 17.0. You should use the [job token scope APIs](https://docs.gitlab.com/ee/api/project_job_token_scopes.html) instead.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change" data-milestone="17.0">
|
||||
|
||||
### The `gitlab-runner exec` command is deprecated
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
|
@ -2442,7 +2442,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#add-a-project-to-the-job-token-allowlist) 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-group-or-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.
|
||||
|
||||
|
|
@ -2892,7 +2892,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#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 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-group-or-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.
|
||||
|
||||
|
|
|
|||
|
|
@ -319,7 +319,7 @@ services:
|
|||
|
||||
### Issues when authenticating to the Dependency Proxy from CI/CD jobs
|
||||
|
||||
GitLab Runner authenticates automatically to the Dependency Proxy. However, the underlying Docker engine is still subject to its [authorization resolving process](https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/docs/configuration/advanced-configuration.md#precedence-of-docker-authorization-resolving).
|
||||
GitLab Runner authenticates automatically to the Dependency Proxy. However, the underlying Docker engine is still subject to its [authorization resolving process](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#precedence-of-docker-authorization-resolving).
|
||||
|
||||
Misconfigurations in the authentication mechanism may cause `HTTP Basic: Access denied` and `403: Access forbidden` errors.
|
||||
|
||||
|
|
|
|||
|
|
@ -11098,6 +11098,9 @@ msgstr ""
|
|||
msgid "CiVariables|CI/CD Variables"
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Can be seen in job logs."
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Cancel"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -11137,10 +11140,10 @@ msgstr ""
|
|||
msgid "CiVariables|Key"
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Mask variable"
|
||||
msgid "CiVariables|Masked"
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Masked"
|
||||
msgid "CiVariables|Masked in job logs but value can be revealed in CI/CD settings. Requires values to meet regular expressions requirements."
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Maximum number of Inherited Group CI variables loaded (2000)"
|
||||
|
|
@ -11218,9 +11221,6 @@ msgstr ""
|
|||
msgid "CiVariables|Variable value will be evaluated as raw string."
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Variable will be masked in job logs. Requires values to meet regular expression requirements."
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Variables"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -11239,6 +11239,9 @@ msgstr ""
|
|||
msgid "CiVariables|Variables store information that you can use in job scripts. Each %{entity} can define a maximum of %{limit} variables."
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|Visible"
|
||||
msgstr ""
|
||||
|
||||
msgid "CiVariables|You can use CI/CD variables with the same name in different places, but the variables might overwrite each other. %{linkStart}What is the order of precedence for variables?%{linkEnd}"
|
||||
msgstr ""
|
||||
|
||||
|
|
@ -57109,6 +57112,9 @@ msgstr ""
|
|||
msgid "Violation"
|
||||
msgstr ""
|
||||
|
||||
msgid "Visibility"
|
||||
msgstr ""
|
||||
|
||||
msgid "Visibility and access controls"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,8 @@ import {
|
|||
GlLink,
|
||||
GlModal,
|
||||
GlSprintf,
|
||||
GlFormRadio,
|
||||
GlFormRadioGroup,
|
||||
} from '@gitlab/ui';
|
||||
import { mountExtended, shallowMountExtended } from 'helpers/vue_test_utils_helper';
|
||||
import { helpPagePath } from '~/helpers/help_page_helper';
|
||||
|
|
@ -89,7 +91,8 @@ describe('CI Variable Drawer', () => {
|
|||
const findExpandedCheckbox = () => wrapper.findByTestId('ci-variable-expanded-checkbox');
|
||||
const findFlagsDocsLink = () => wrapper.findByTestId('ci-variable-flags-docs-link');
|
||||
const findKeyField = () => wrapper.findComponent(GlFormCombobox);
|
||||
const findMaskedCheckbox = () => wrapper.findByTestId('ci-variable-masked-checkbox');
|
||||
const findMaskedRadioButtons = () => wrapper.findAllComponents(GlFormRadio);
|
||||
const findMaskedRadioGroup = () => wrapper.findByTestId('ci-variable-masked');
|
||||
const findProtectedCheckbox = () => wrapper.findByTestId('ci-variable-protected-checkbox');
|
||||
const findValueField = () => wrapper.findByTestId('ci-variable-value');
|
||||
const findValueLabel = () => wrapper.findByTestId('ci-variable-value-label');
|
||||
|
|
@ -190,6 +193,35 @@ describe('CI Variable Drawer', () => {
|
|||
});
|
||||
});
|
||||
|
||||
describe('visibility section', () => {
|
||||
it('renders radio buttons for Variable masking', () => {
|
||||
createComponent({ stubs: { GlFormRadioGroup, GlFormRadio } });
|
||||
|
||||
expect(findMaskedRadioButtons()).toHaveLength(2);
|
||||
});
|
||||
|
||||
describe('masked radio', () => {
|
||||
beforeEach(() => {
|
||||
createComponent();
|
||||
});
|
||||
|
||||
it('is false by default', () => {
|
||||
expect(findMaskedRadioGroup().attributes('checked')).toBeUndefined();
|
||||
});
|
||||
|
||||
it('inherits value of selected variable when editing', () => {
|
||||
createComponent({
|
||||
props: {
|
||||
selectedVariable: mockProjectVariableFileType,
|
||||
mode: EDIT_VARIABLE_ACTION,
|
||||
},
|
||||
});
|
||||
|
||||
expect(findMaskedRadioGroup().attributes('checked')).toBe('true');
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
describe('protected flag', () => {
|
||||
beforeEach(() => {
|
||||
createComponent();
|
||||
|
|
@ -217,27 +249,6 @@ describe('CI Variable Drawer', () => {
|
|||
});
|
||||
});
|
||||
|
||||
describe('masked flag', () => {
|
||||
beforeEach(() => {
|
||||
createComponent();
|
||||
});
|
||||
|
||||
it('is false by default', () => {
|
||||
expect(findMaskedCheckbox().attributes('checked')).toBeUndefined();
|
||||
});
|
||||
|
||||
it('inherits value of selected variable when editing', () => {
|
||||
createComponent({
|
||||
props: {
|
||||
selectedVariable: mockProjectVariableFileType,
|
||||
mode: EDIT_VARIABLE_ACTION,
|
||||
},
|
||||
});
|
||||
|
||||
expect(findMaskedCheckbox().attributes('checked')).toBeDefined();
|
||||
});
|
||||
});
|
||||
|
||||
describe('expanded flag', () => {
|
||||
beforeEach(() => {
|
||||
createComponent();
|
||||
|
|
@ -388,7 +399,7 @@ describe('CI Variable Drawer', () => {
|
|||
trackingSpy = mockTracking(undefined, wrapper.element, jest.spyOn);
|
||||
findKeyField().vm.$emit('input', 'NEW_VARIABLE');
|
||||
findValueField().vm.$emit('input', value);
|
||||
findMaskedCheckbox().vm.$emit('input', true);
|
||||
findMaskedRadioGroup().vm.$emit('input', true);
|
||||
});
|
||||
|
||||
itif(canSubmit)(`can submit when value is ${value}`, () => {
|
||||
|
|
@ -436,7 +447,7 @@ describe('CI Variable Drawer', () => {
|
|||
it('only sends the tracking event once', async () => {
|
||||
trackingSpy = mockTracking(undefined, wrapper.element, jest.spyOn);
|
||||
await findKeyField().vm.$emit('input', 'NEW_VARIABLE');
|
||||
await findMaskedCheckbox().vm.$emit('input', true);
|
||||
await findMaskedRadioGroup().vm.$emit('input', true);
|
||||
|
||||
expect(trackingSpy).toHaveBeenCalledTimes(0);
|
||||
|
||||
|
|
@ -488,7 +499,7 @@ describe('CI Variable Drawer', () => {
|
|||
await findKeyField().vm.$emit('input', 'NEW_VARIABLE');
|
||||
await findProtectedCheckbox().vm.$emit('input', false);
|
||||
await findExpandedCheckbox().vm.$emit('input', true);
|
||||
await findMaskedCheckbox().vm.$emit('input', true);
|
||||
await findMaskedRadioGroup().vm.$emit('input', true);
|
||||
await findValueField().vm.$emit('input', 'NEW_VALUE');
|
||||
|
||||
findConfirmBtn().vm.$emit('click');
|
||||
|
|
|
|||
|
|
@ -15,7 +15,9 @@ RSpec.describe Mutations::DesignManagement::Upload do
|
|||
|
||||
def run_mutation(files_to_upload = files, project_path = project.full_path, iid = issue.iid)
|
||||
mutation = described_class.new(object: nil, context: { current_user: user }, field: nil)
|
||||
mutation.resolve(project_path: project_path, iid: iid, files: files_to_upload)
|
||||
Gitlab::ExclusiveLease.skipping_transaction_check do
|
||||
mutation.resolve(project_path: project_path, iid: iid, files: files_to_upload)
|
||||
end
|
||||
end
|
||||
|
||||
describe "#resolve" do
|
||||
|
|
@ -65,9 +67,19 @@ RSpec.describe Mutations::DesignManagement::Upload do
|
|||
end
|
||||
|
||||
describe 'running requests in parallel' do
|
||||
it 'does not cause errors', quarantine: 'https://gitlab.com/gitlab-org/gitlab/-/issues/442468' do
|
||||
it 'does not cause errors' do
|
||||
# max_concurrency is set to be less than the LOCK_RETRY_COUNT to avoid
|
||||
# Gitlab::ExclusiveLeaseHelpers::FailedToObtainLockError.
|
||||
#
|
||||
# When the number of processes attempting to obtain the lock exceeds the number of retries
|
||||
# permitted, at least 1 process will reach the retry limit and raise the error.
|
||||
creates_designs do
|
||||
run_parallel(files.map { |f| -> { run_mutation([f]) } })
|
||||
run_parallel(
|
||||
files.map { |f| -> { run_mutation([f]) } },
|
||||
# We reduce by 2 for more allowance as the delay between the initial few retries are very small.
|
||||
# The retry delays are 0.2, 0.4, 0.8, 1.6, 3.2 seconds.
|
||||
max_concurrency: DesignManagement::Version::LOCK_RETRY_COUNT - 2
|
||||
)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ RSpec.shared_examples 'variable list drawer' do
|
|||
|
||||
fill_variable('EDITED_KEY', 'EDITED_VALUE', 'EDITED_DESCRIPTION')
|
||||
toggle_protected
|
||||
toggle_masked
|
||||
set_visible
|
||||
toggle_expanded
|
||||
find_by_testid('ci-variable-confirm-button').click
|
||||
|
||||
|
|
@ -127,7 +127,8 @@ RSpec.shared_examples 'variable list drawer' do
|
|||
|
||||
# form is NOT reset (unlike when adding a variable)
|
||||
expect(find('[data-testid="ci-variable-protected-checkbox"]')).to be_checked
|
||||
expect(find('[data-testid="ci-variable-masked-checkbox"]')).not_to be_checked
|
||||
expect(find('[data-testid="ci-variable-visible-radio"]')).to be_checked
|
||||
expect(find('[data-testid="ci-variable-masked-radio"]')).not_to be_checked
|
||||
expect(find('[data-testid="ci-variable-expanded-checkbox"]')).not_to be_checked
|
||||
expect(page).to have_field(s_('CiVariables|Key'), with: 'EDITED_KEY')
|
||||
expect(page).to have_field(s_('CiVariables|Description'), with: 'EDITED_DESCRIPTION')
|
||||
|
|
@ -194,7 +195,7 @@ RSpec.shared_examples 'variable list drawer' do
|
|||
it 'shows validation error for unmaskable values' do
|
||||
open_drawer
|
||||
|
||||
toggle_masked
|
||||
set_masked
|
||||
fill_variable('EMPTY_MASK_KEY', '???')
|
||||
|
||||
expect(page).to have_content('This value cannot be masked because it contains the following characters: ?.')
|
||||
|
|
@ -290,15 +291,21 @@ RSpec.shared_examples 'variable list drawer' do
|
|||
end
|
||||
end
|
||||
|
||||
def toggle_masked
|
||||
page.within('[data-testid="ci-variable-drawer"]') do
|
||||
find('[data-testid="ci-variable-masked-checkbox"]').click
|
||||
end
|
||||
end
|
||||
|
||||
def toggle_expanded
|
||||
page.within('[data-testid="ci-variable-drawer"]') do
|
||||
find('[data-testid="ci-variable-expanded-checkbox"]').click
|
||||
end
|
||||
end
|
||||
|
||||
def set_masked
|
||||
page.within('[data-testid="ci-variable-drawer"]') do
|
||||
find('[data-testid="ci-variable-masked-radio"]').click
|
||||
end
|
||||
end
|
||||
|
||||
def set_visible
|
||||
page.within('[data-testid="ci-variable-drawer"]') do
|
||||
find('[data-testid="ci-variable-visible-radio"]').click
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in New Issue