Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
b6611aed26
commit
b9b0853302
|
|
@ -66,7 +66,7 @@ export default {
|
|||
:aria-label="buttonTitle"
|
||||
:loading="isLoading"
|
||||
:disabled="isActionInProgress"
|
||||
:class="`gl-ml-3 ${containerClasses}`"
|
||||
:class="containerClasses"
|
||||
:icon="icon"
|
||||
@click="$emit('click')"
|
||||
>
|
||||
|
|
@ -81,7 +81,7 @@ export default {
|
|||
:aria-label="buttonTitle"
|
||||
:loading="isLoading"
|
||||
:disabled="isActionInProgress"
|
||||
:class="`gl-ml-3 ${containerClasses}`"
|
||||
:class="containerClasses"
|
||||
:icon="icon"
|
||||
@click="$emit('click')"
|
||||
>
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ export default {
|
|||
</script>
|
||||
|
||||
<template>
|
||||
<div class="gl-inline-flex">
|
||||
<div class="gl-inline-flex gl-gap-3">
|
||||
<deployment-action-button
|
||||
v-if="canBeManuallyDeployed"
|
||||
:action-in-progress="actionInProgress"
|
||||
|
|
|
|||
|
|
@ -460,9 +460,7 @@ li.note {
|
|||
|
||||
copy-code {
|
||||
position: absolute;
|
||||
@apply gl-transition-all;
|
||||
opacity: 0;
|
||||
|
||||
top: $gl-spacing-scale-3;
|
||||
right: $gl-spacing-scale-3;
|
||||
|
||||
|
|
|
|||
|
|
@ -322,25 +322,7 @@
|
|||
display: flex;
|
||||
align-items: center;
|
||||
flex-wrap: wrap;
|
||||
|
||||
@include media-breakpoint-up(xs) {
|
||||
flex-wrap: nowrap;
|
||||
white-space: nowrap;
|
||||
}
|
||||
|
||||
@container mr-widget-extension (max-width: 600px) {
|
||||
flex-direction: column;
|
||||
align-items: flex-start;
|
||||
|
||||
.deployment-info {
|
||||
margin-bottom: $gl-padding-8;
|
||||
}
|
||||
|
||||
// stylelint-disable-next-line gitlab/no-gl-class
|
||||
.gl-button {
|
||||
margin-left: 0;
|
||||
}
|
||||
}
|
||||
justify-content: space-between;
|
||||
|
||||
> *:not(:last-child) {
|
||||
margin-right: 0.3em;
|
||||
|
|
@ -351,19 +333,9 @@
|
|||
}
|
||||
|
||||
.deployment-info {
|
||||
flex: 1;
|
||||
white-space: nowrap;
|
||||
text-overflow: ellipsis;
|
||||
min-width: 100px;
|
||||
|
||||
display: grid;
|
||||
white-space: nowrap;display: grid;
|
||||
grid-template-columns: max-content minmax(0, max-content) max-content;
|
||||
grid-gap: $gl-spacing-scale-2;
|
||||
|
||||
@include media-breakpoint-up(xs) {
|
||||
min-width: 0;
|
||||
max-width: 100%;
|
||||
}
|
||||
}
|
||||
|
||||
.dropdown-menu {
|
||||
|
|
|
|||
|
|
@ -10,12 +10,5 @@ milestone: '16.5'
|
|||
gitlab_schema: gitlab_main_cell
|
||||
allow_cross_foreign_keys:
|
||||
- gitlab_main_clusterwide
|
||||
desired_sharding_key:
|
||||
namespace_id:
|
||||
references: namespaces
|
||||
backfill_via:
|
||||
parent:
|
||||
foreign_key: value_stream_id
|
||||
table: analytics_cycle_analytics_group_value_streams
|
||||
sharding_key: group_id
|
||||
belongs_to: value_stream
|
||||
sharding_key:
|
||||
namespace_id: namespaces
|
||||
|
|
|
|||
|
|
@ -0,0 +1,11 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddNamespaceIdToAnalyticsCycleAnalyticsValueStreamSettings < Gitlab::Database::Migration[2.2]
|
||||
milestone '17.6'
|
||||
|
||||
# rubocop:disable Rails/NotNullColumn -- NamespaceId can not have a default value
|
||||
def change
|
||||
add_column :analytics_cycle_analytics_value_stream_settings, :namespace_id, :bigint, null: false
|
||||
end
|
||||
# rubocop:enable Rails/NotNullColumn
|
||||
end
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class IndexAnalyticsCycleAnalyticsValueStreamSettingsOnNamespaceId < Gitlab::Database::Migration[2.2]
|
||||
milestone '17.6'
|
||||
disable_ddl_transaction!
|
||||
|
||||
INDEX_NAME = 'index_analytics_cycle_analytics_value_stream_settings_on_namesp'
|
||||
|
||||
def up
|
||||
add_concurrent_index :analytics_cycle_analytics_value_stream_settings, :namespace_id, name: INDEX_NAME
|
||||
end
|
||||
|
||||
def down
|
||||
remove_concurrent_index_by_name :analytics_cycle_analytics_value_stream_settings, INDEX_NAME
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddAnalyticsCycleAnalyticsValueStreamSettingsNamespaceIdFk < Gitlab::Database::Migration[2.2]
|
||||
milestone '17.6'
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
add_concurrent_foreign_key :analytics_cycle_analytics_value_stream_settings, :namespaces, column: :namespace_id,
|
||||
on_delete: :cascade
|
||||
end
|
||||
|
||||
def down
|
||||
with_lock_retries do
|
||||
remove_foreign_key :analytics_cycle_analytics_value_stream_settings, column: :namespace_id
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddAnalyticsCycleAnalyticsValueStreamSettingsNamespaceIdTrigger < Gitlab::Database::Migration[2.2]
|
||||
milestone '17.6'
|
||||
|
||||
def up
|
||||
install_sharding_key_assignment_trigger(
|
||||
table: :analytics_cycle_analytics_value_stream_settings,
|
||||
sharding_key: :namespace_id,
|
||||
parent_table: :analytics_cycle_analytics_group_value_streams,
|
||||
parent_sharding_key: :group_id,
|
||||
foreign_key: :value_stream_id
|
||||
)
|
||||
end
|
||||
|
||||
def down
|
||||
remove_sharding_key_assignment_trigger(
|
||||
table: :analytics_cycle_analytics_value_stream_settings,
|
||||
sharding_key: :namespace_id,
|
||||
parent_table: :analytics_cycle_analytics_group_value_streams,
|
||||
parent_sharding_key: :group_id,
|
||||
foreign_key: :value_stream_id
|
||||
)
|
||||
end
|
||||
end
|
||||
|
|
@ -0,0 +1 @@
|
|||
40db0d47902dbf54c6c2573fb0aa989e56ed2d4ee015f6733145f6d01d0772a5
|
||||
|
|
@ -0,0 +1 @@
|
|||
e11c91e8de86f13d78b3edd3ba013d037fcb2dd22f07da270e9ff536cb314e3c
|
||||
|
|
@ -0,0 +1 @@
|
|||
576e65acf4940f7194debb21912e5340feb679ebc153770d47ab92127328ec64
|
||||
|
|
@ -0,0 +1 @@
|
|||
a1548e36b359a8071b66e66c18e2331dadeabb0948b304ff21377bb9d8128a37
|
||||
|
|
@ -935,6 +935,22 @@ RETURN NEW;
|
|||
END
|
||||
$$;
|
||||
|
||||
CREATE FUNCTION trigger_0c326daf67cf() RETURNS trigger
|
||||
LANGUAGE plpgsql
|
||||
AS $$
|
||||
BEGIN
|
||||
IF NEW."namespace_id" IS NULL THEN
|
||||
SELECT "group_id"
|
||||
INTO NEW."namespace_id"
|
||||
FROM "analytics_cycle_analytics_group_value_streams"
|
||||
WHERE "analytics_cycle_analytics_group_value_streams"."id" = NEW."value_stream_id";
|
||||
END IF;
|
||||
|
||||
RETURN NEW;
|
||||
|
||||
END
|
||||
$$;
|
||||
|
||||
CREATE FUNCTION trigger_0da002390fdc() RETURNS trigger
|
||||
LANGUAGE plpgsql
|
||||
AS $$
|
||||
|
|
@ -6050,6 +6066,7 @@ ALTER SEQUENCE analytics_cycle_analytics_stage_event_hashes_id_seq OWNED BY anal
|
|||
CREATE TABLE analytics_cycle_analytics_value_stream_settings (
|
||||
value_stream_id bigint NOT NULL,
|
||||
project_ids_filter bigint[] DEFAULT '{}'::bigint[],
|
||||
namespace_id bigint NOT NULL,
|
||||
CONSTRAINT project_ids_filter_array_check CHECK (((cardinality(project_ids_filter) <= 100) AND (array_position(project_ids_filter, NULL::bigint) IS NULL)))
|
||||
);
|
||||
|
||||
|
|
@ -28161,6 +28178,8 @@ CREATE UNIQUE INDEX index_analytics_ca_group_value_streams_on_group_id_and_name
|
|||
|
||||
CREATE INDEX index_analytics_cycle_analytics_group_stages_custom_only ON analytics_cycle_analytics_group_stages USING btree (id) WHERE (custom = true);
|
||||
|
||||
CREATE INDEX index_analytics_cycle_analytics_value_stream_settings_on_namesp ON analytics_cycle_analytics_value_stream_settings USING btree (namespace_id);
|
||||
|
||||
CREATE UNIQUE INDEX index_analytics_dashboards_pointers_on_namespace_id ON analytics_dashboards_pointers USING btree (namespace_id);
|
||||
|
||||
CREATE INDEX index_analytics_dashboards_pointers_on_target_project_id ON analytics_dashboards_pointers USING btree (target_project_id);
|
||||
|
|
@ -34231,6 +34250,8 @@ CREATE TRIGGER trigger_0a1b0adcf686 BEFORE INSERT OR UPDATE ON packages_debian_p
|
|||
|
||||
CREATE TRIGGER trigger_0a29d4d42b62 BEFORE INSERT OR UPDATE ON approval_project_rules_protected_branches FOR EACH ROW EXECUTE FUNCTION trigger_0a29d4d42b62();
|
||||
|
||||
CREATE TRIGGER trigger_0c326daf67cf BEFORE INSERT OR UPDATE ON analytics_cycle_analytics_value_stream_settings FOR EACH ROW EXECUTE FUNCTION trigger_0c326daf67cf();
|
||||
|
||||
CREATE TRIGGER trigger_0da002390fdc BEFORE INSERT OR UPDATE ON operations_feature_flags_issues FOR EACH ROW EXECUTE FUNCTION trigger_0da002390fdc();
|
||||
|
||||
CREATE TRIGGER trigger_0e13f214e504 BEFORE INSERT OR UPDATE ON merge_request_assignment_events FOR EACH ROW EXECUTE FUNCTION trigger_0e13f214e504();
|
||||
|
|
@ -35962,6 +35983,9 @@ ALTER TABLE ONLY packages_composer_metadata
|
|||
ALTER TABLE ONLY approval_project_rules_protected_branches
|
||||
ADD CONSTRAINT fk_e6ee913fc2 FOREIGN KEY (project_id) REFERENCES projects(id) ON DELETE CASCADE;
|
||||
|
||||
ALTER TABLE ONLY analytics_cycle_analytics_value_stream_settings
|
||||
ADD CONSTRAINT fk_e6fcfdeb81 FOREIGN KEY (namespace_id) REFERENCES namespaces(id) ON DELETE CASCADE;
|
||||
|
||||
ALTER TABLE ONLY merge_requests
|
||||
ADD CONSTRAINT fk_e719a85f8a FOREIGN KEY (author_id) REFERENCES users(id) ON DELETE SET NULL;
|
||||
|
||||
|
|
|
|||
|
|
@ -317,7 +317,7 @@ secondary site is a read-only copy.
|
|||
1. Select **Geo > Sites**.
|
||||
1. Select **Add site**.
|
||||
|
||||
|
||||
|
||||
|
||||
1. In **Name**, enter the value for `gitlab_rails['geo_node_name']` in
|
||||
`/etc/gitlab/gitlab.rb`. The values must match exactly.
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Configure the GitLab Duo feature to send queries to the configured self-hosted m
|
|||
- Choose the self-hosted model you want to use, for example, `Mistral`.
|
||||
1. Select **Save Changes**.
|
||||
|
||||
### Configure the features to use GitLab AI Vendor models
|
||||
### Configure the features to use GitLab AI vendor models
|
||||
|
||||
You can choose a GitLab AI vendor to be the GitLab Duo feature's model provider. The
|
||||
feature then uses the GitLab-hosted model through the GitLab Cloud Connector:
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ can find the reason:
|
|||
|
||||
In each place, if you hover over the failed job you can see the reason it failed.
|
||||
|
||||
|
||||
|
||||
|
||||
You can also see the reason it failed on the Job detail page.
|
||||
|
||||
|
|
@ -148,11 +148,11 @@ to read.
|
|||
You can automatically group similar jobs together. If the job names are formatted in a certain way,
|
||||
they are collapsed into a single group in regular pipeline graphs (not the mini graphs).
|
||||
|
||||
You can recognize when a pipeline has grouped jobs if you don't see the retry or
|
||||
cancel button inside them. Hovering over them shows the number of grouped
|
||||
jobs. Select to expand them.
|
||||
You can recognize when a pipeline has grouped jobs if you see a number next to a job
|
||||
name instead of the retry or cancel buttons. The number indicates the amount of grouped
|
||||
jobs. Hovering over them shows you if all jobs have passed or any has failed. Select to expand them.
|
||||
|
||||
|
||||
|
||||
|
||||
To create a group of jobs, in the `.gitlab-ci.yml` file,
|
||||
separate each job name with a number and one of the following:
|
||||
|
|
@ -292,7 +292,7 @@ the [variable is overridden](../variables/index.md#override-a-defined-cicd-varia
|
|||
Any variables overridden by using this process are [expanded](../variables/index.md#prevent-cicd-variable-expansion)
|
||||
and not [masked](../variables/index.md#mask-a-cicd-variable).
|
||||
|
||||
|
||||
|
||||
|
||||
## Delay a job
|
||||
|
||||
|
|
@ -307,7 +307,7 @@ For example, if you start rolling out new code and:
|
|||
- Users experience trouble with the new code, you can stop the timed incremental rollout by canceling the pipeline
|
||||
and [rolling](../environments/index.md#retry-or-roll-back-a-deployment) back to the last stable version.
|
||||
|
||||
|
||||
|
||||
|
||||
## Deployment jobs
|
||||
|
||||
|
|
|
|||
|
|
@ -9,9 +9,10 @@ description: "Documentation for developers interested in contributing features o
|
|||
|
||||
## GitLab Observability development setup
|
||||
|
||||
There are two options for developing and debugging GitLab Observability:
|
||||
There are several options for developing and debugging GitLab Observability:
|
||||
|
||||
- [Run GDK locally and connect to the staging instance](#run-gdk-and-connect-to-the-staging-instance-of-gitlab-observability-backend) of [GitLab Observability Backend](https://gitlab.com/gitlab-org/opstrace/opstrace). This is the simplest and recommended approach for those looking to make changes, or verify changes to Rails, Sidekiq or Workhorse.
|
||||
- [Run GDK and GitLab Observability Backend locally all-in-one](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/gitlab_observability_backend.md): This is the simplest and recommended approach for those looking to make changes, or verify changes to Rails, Sidekiq or Workhorse.
|
||||
- [Run GDK locally and connect to the staging instance](#run-gdk-and-connect-to-the-staging-instance-of-gitlab-observability-backend) of [GitLab Observability Backend](https://gitlab.com/gitlab-org/opstrace/opstrace). This is an alternative approach for those looking to make changes, or verify changes to Rails, Sidekiq or Workhorse.
|
||||
- [Use the purpose built `devvm`](#use-the-purpose-built-devvm). This is more involved but includes a development deployment of the [GitLab Observability Backend](https://gitlab.com/gitlab-org/opstrace/opstrace). This is recommended for those who want to make changes to the GitLab Observability Backend component.
|
||||
- [Run GDK with mocked Observability data](#run-gdk-with-mocked-observability-data). This could be useful in case you just need to work on a frontend or Rails change and do not need the full stack, or when providing reproduction steps for an MR reviewer, who probably won't want to set up the full stack just for an MR.
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
|
|
@ -17,23 +17,25 @@ DETAILS:
|
|||
> - Enforcement of scan execution policies on projects with an existing GitLab CI/CD configuration [introduced](https://gitlab.com/groups/gitlab-org/-/epics/6880) in GitLab 16.2 [with a flag](../../../administration/feature_flags.md) named `scan_execution_policy_pipelines`. Feature flag `scan_execution_policy_pipelines` removed in GitLab 16.5.
|
||||
> - Overriding predefined variables in scan execution policies [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/440855) in GitLab 16.10 [with a flag](../../../administration/feature_flags.md) named `allow_restricted_variables_at_policy_level`. Enabled by default. Feature flag `allow_restricted_variables_at_policy_level` removed in GitLab 17.5.
|
||||
|
||||
Use scan execution policies to enforce security scans, either as part of the pipeline or on a
|
||||
specified schedule. The security scans run with multiple project pipelines if you define the policy
|
||||
at a group or subgroup level.
|
||||
Use scan execution policies to enforce GitLab security scans based on the default or latest [security CI templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs), either as part of the pipeline or on a
|
||||
specified schedule.
|
||||
|
||||
Scan execution policies are enforced for all applicable projects. For projects without a
|
||||
Scan execution policies are enforced across all projects that are linked to the security policy project and are within the scope of the policy. For projects without a
|
||||
`.gitlab-ci.yml` file, or where AutoDevOps is disabled, security policies create the
|
||||
`.gitlab-ci.yml` file implicitly. This ensures policies enabling execution of secret detection,
|
||||
static analysis, or other scanners that do not require a build in the project, are still able to
|
||||
run and be enforced.
|
||||
|
||||
This feature has some overlap with [compliance pipelines](../../group/compliance_pipelines.md),
|
||||
as we have not [unified the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312).
|
||||
For details on the similarities and differences between these features, see
|
||||
[Enforce scan execution](../index.md#enforce-scan-execution).
|
||||
Scan execution policies, compared to pipeline execution policies, provide a faster path to configure GitLab security scans across multiple projects to manage security and compliance.
|
||||
|
||||
If any of the following cases are true, use [pipeline execution policies](pipeline_execution_policies.md) instead:
|
||||
|
||||
- You require advanced configuration settings.
|
||||
- You want to enforce custom CI/CD jobs or scripts.
|
||||
- You want to enable third-party security scans through an enforced CI/CD job.
|
||||
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For a video walkthrough, see [How to set up Security Scan Policies in GitLab](https://youtu.be/ZBcqGmEwORA?si=aeT4EXtmHjosgjBY).
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> For an overview, see [Enforcing scan execution policies on projects with no GitLab CI/CD configuration](https://www.youtube.com/watch?v=sUfwQQ4-qHs).
|
||||
- <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Learn more about [enforcing scan execution policies on projects with no GitLab CI/CD configuration](https://www.youtube.com/watch?v=sUfwQQ4-qHs).
|
||||
|
||||
## Restrictions
|
||||
|
||||
|
|
@ -50,7 +52,7 @@ the beginning of the pipeline. DAST scans always run in the `dast` stage. If thi
|
|||
exist, then a `dast` stage is injected at the end of the pipeline.
|
||||
|
||||
To avoid job name conflicts, a hyphen and a number is appended to the job name. The number is unique
|
||||
per policy action.
|
||||
per policy action. For example `secret-detection` becomes `secret-detection-1`.
|
||||
|
||||
## Scan execution policy editor
|
||||
|
||||
|
|
@ -58,21 +60,21 @@ Use the scan execution policy editor to create or edit a scan execution policy.
|
|||
|
||||
Prerequisites:
|
||||
|
||||
- Only group, subgroup, or project Owners have the [permissions](../../permissions.md#project-members-permissions)
|
||||
to select Security Policy Project.
|
||||
- By default, only group, subgroup, or project Owners have the [permissions](../../permissions.md#application-security)
|
||||
required to create or assign a security policy project. Alternatively, you can create a custom role with the permission to [manage security policy links](../../custom_roles/abilities.md#security-policy-management).
|
||||
|
||||
Once your policy is complete, save it by selecting **Configure with a merge request**
|
||||
at the bottom of the editor. You are redirected to the merge request on the project's
|
||||
configured security policy project. If one does not link to your project, a security
|
||||
policy project is automatically created. Existing policies can also be
|
||||
removed from the editor interface by selecting **Delete policy**
|
||||
at the bottom of the editor.
|
||||
at the bottom of the editor to introduce a merge request to remove the policy from your `policy.yml` file.
|
||||
|
||||
Most policy changes take effect as soon as the merge request is merged. Any changes that
|
||||
do not go through a merge request and are committed directly to the default branch may require up to 10 minutes
|
||||
before the policy changes take effect.
|
||||
|
||||
|
||||
|
||||
|
||||
NOTE:
|
||||
Selection of site and scanner profiles using the rule mode editor for DAST execution policies differs based on
|
||||
|
|
@ -123,7 +125,7 @@ This rule enforces the defined actions whenever the pipeline runs for a selected
|
|||
| Field | Type | Required | Possible values | Description |
|
||||
|-------|------|----------|-----------------|-------------|
|
||||
| `type` | `string` | true | `pipeline` | The rule's type. |
|
||||
| `branches` <sup>1</sup> | `array` of `string` | true if `branch_type` field does not exist | `*` or the branch's name | The branch the given policy applies to (supports wildcard). |
|
||||
| `branches` <sup>1</sup> | `array` of `string` | true if `branch_type` field does not exist | `*` or the branch's name | The branch the given policy applies to (supports wildcard). For compatibility with merge request approval policies, you should target all branches to include the scans in the feature branch and default branch |
|
||||
| `branch_type` <sup>1</sup> | `string` | true if `branches` field does not exist | `default`, `protected` or `all` | The types of branches the given policy applies to. |
|
||||
| `branch_exceptions` | `array` of `string` | false | Names of branches | Branches to exclude from this rule. |
|
||||
|
||||
|
|
@ -154,7 +156,7 @@ A scheduled pipeline:
|
|||
| `branches` <sup>1</sup> | `array` of `string` | true if either `branch_type` or `agents` fields does not exist | `*` or the branch's name | The branch the given policy applies to (supports wildcard). |
|
||||
| `branch_type` <sup>1</sup> | `string` | true if either `branches` or `agents` fields does not exist | `default`, `protected` or `all` | The types of branches the given policy applies to. |
|
||||
| `branch_exceptions` | `array` of `string` | false | Names of branches | Branches to exclude from this rule. |
|
||||
| `cadence` | `string` | true | Cron expression (for example, `0 0 * * *`) | A whitespace-separated string containing five fields that represents the scheduled time. |
|
||||
| `cadence` | `string` | true | Cron expression with limited options. For example, `0 0 * * *` creates a schedule to run every day at midnight (12:00 AM). | A whitespace-separated string containing five fields that represents the scheduled time. |
|
||||
| `timezone` | `string` | false | Time zone identifier (for example, `America/New_York`) | Time zone to apply to the cadence. Value must be an IANA Time Zone Database identifier. |
|
||||
| `agents` <sup>1</sup> | `object` | true if either `branch_type` or `branches` fields do not exists | | The name of the [GitLab agents](../../clusters/agent/index.md) where [Operational Container Scanning](../../clusters/agent/vulnerabilities.md) runs. The object key is the name of the Kubernetes agent configured for your project in GitLab. |
|
||||
|
||||
|
|
@ -246,7 +248,7 @@ rule in the defined policy are met.
|
|||
| `scanner_profile` | `string` or `null` | Name of the selected [DAST scanner profile](../dast/on-demand_scan.md#scanner-profile). | The DAST scanner profile to execute the DAST scan. This field should only be set if `scan` type is `dast`.|
|
||||
| `variables` | `object` | | A set of CI variables, supplied as an array of `key: value` pairs, to apply and enforce for the selected scan. The `key` is the variable name, with its `value` provided as a string. This parameter supports any variable that the GitLab CI job supports for the specified scan. |
|
||||
| `tags` | `array` of `string` | | A list of runner tags for the policy. The policy jobs are run by runner with the specified tags. |
|
||||
| `template` | `string` | `default`, `latest` | CI/CD template edition to be enforced. The [`latest`](../../../development/cicd/templates.md#latest-version) edition may introduce breaking changes. |
|
||||
| `template` | `string` | `default`, `latest` | CI/CD template version to be enforced. The [`latest`](../../../development/cicd/templates.md#latest-version) version may introduce breaking changes. See the `stable` and `latest` [security templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Jobs). |
|
||||
| `scan_settings` | `object` | | A set of scan settings, supplied as an array of `key: value` pairs, to apply and enforce for the selected scan. The `key` is the setting name, with its `value` provided as a boolean or string. This parameter supports the settings defined in [scan settings](#scan-settings). |
|
||||
|
||||
NOTE:
|
||||
|
|
@ -315,6 +317,7 @@ SAST_EXCLUDED_PATHS: spec, test, tests, tmp
|
|||
SECRET_DETECTION_EXCLUDED_PATHS: ''
|
||||
SECRET_DETECTION_HISTORIC_SCAN: false
|
||||
SAST_EXCLUDED_ANALYZERS: ''
|
||||
DEFAULT_SAST_EXCLUDED_PATHS: spec, test, tests, tmp
|
||||
DS_EXCLUDED_ANALYZERS: ''
|
||||
```
|
||||
|
||||
|
|
@ -415,15 +418,16 @@ Scan execution policies can cause the same type of scanner to run more than once
|
|||
developer may want to try running a SAST scan with different variables than the one enforced by the security and compliance team. In
|
||||
this case, two SAST jobs run in the pipeline, one with the developer's variables and one with the security and compliance team's variables.
|
||||
|
||||
If you want to avoid running duplicate scans, you can either remove the scans from the project's `.gitlab-ci.yml` file or disable your
|
||||
local jobs by setting `SAST_DISABLED: "true"`. Disabling jobs this way does not prevent the security jobs defined by scan execution
|
||||
If you want to avoid running duplicate scans, you can either remove the scans from the project's `.gitlab-ci.yml` file or skip your
|
||||
local jobs with variables. Skipping jobs does not prevent any security jobs defined by scan execution
|
||||
policies from running.
|
||||
|
||||
## Experimental features
|
||||
To skip scan jobs with variables, you can use:
|
||||
|
||||
DETAILS:
|
||||
**Status:** Experiment has ended
|
||||
- `SAST_DISABLED: "true"` to skip SAST jobs.
|
||||
- `DAST_DISABLED: "true"` to skip DAST jobs.
|
||||
- `CONTAINER_SCANNING_DISABLED: "true"` to skip container scanning jobs.
|
||||
- `SECRET_DETECTION_DISABLED: "true"` to skip secret detection jobs.
|
||||
- `DEPENDENCY_SCANNING_DISABLED: "true"` to skip dependency scanning jobs.
|
||||
|
||||
This experiment has concluded and will not continue. After receiving feedback within this experiment, we will be focusing our efforts on a new policy type for enforcement of custom CI. The experiment will be removed in 17.3.
|
||||
|
||||
Learn more about the [pipeline execution policy](pipeline_execution_policies.md).
|
||||
For an overview of all variables that can skip jobs, see [CI/CD variables documentation](../../../topics/autodevops/cicd_variables.md#job-disabling-variables)
|
||||
|
|
|
|||
|
|
@ -33,20 +33,20 @@ With GitLab Ultimate, pipeline secret detection results are also processed so yo
|
|||
|
||||
## Detected secrets
|
||||
|
||||
GitLab maintains the detection rules used in pipeline secret detection. The default ruleset contains
|
||||
more than 100 patterns.
|
||||
Pipeline secret detection scans the repository's content for specific patterns. Each pattern matches
|
||||
a specific type of secret and is specified in a rule by using a TOML syntax. The default set of
|
||||
rules is maintained by GitLab. In the Ultimate tier, you can customize the default ruleset to suit
|
||||
your needs. For details, see [Customize analyzer rulesets](#customize-analyzer-rulesets). To confirm
|
||||
which secrets are detected by pipeline secret detection, see
|
||||
[Detected secrets](../detected_secrets.md). To provide reliable, high-confidence results, pipeline
|
||||
secret detection only looks for passwords or other unstructured secrets in specific contexts like
|
||||
URLs.
|
||||
|
||||
Most pipeline secret detection patterns search for specific types of secrets.
|
||||
Many services add prefixes or other structural details to their secrets so they can be identified if they're leaked.
|
||||
For example, GitLab [adds a `glpat-` prefix](../../../../administration/settings/account_and_limit_settings.md#personal-access-token-prefix) to project, group, and personal access tokens by default.
|
||||
|
||||
To provide more reliable, high-confidence results, pipeline secret detection only looks for passwords or other unstructured secrets in specific contexts like URLs.
|
||||
|
||||
A detected secret remains in the vulnerability report as "Still
|
||||
detected" even after the secret is removed from the scanned file. This
|
||||
is because the secret remains in the Git repository's history. To
|
||||
address a detected secret, remediate the leak, then triage the
|
||||
vulnerability.
|
||||
When a secret is detected a vulnerability is created for it. The vulnerability remains as "Still
|
||||
detected" even if the secret is removed from the scanned file and pipeline secret detection has been
|
||||
run again. This is because the secret remains in the Git repository's history. To understand how to
|
||||
remove a secret from the Git repository's history, see the tutorial
|
||||
[Remove a secret from your commits](../remove_secrets_tutorial.md).
|
||||
|
||||
## Coverage
|
||||
|
||||
|
|
|
|||
|
|
@ -54,11 +54,11 @@ If secret push protection does not detect any secrets in your commits, no messag
|
|||
|
||||
## Detected secrets
|
||||
|
||||
GitLab maintains a [set of rules](../detected_secrets.md) that are used for blocking secrets from being pushed to GitLab.
|
||||
|
||||
Scanning against low-confidence patterns can potentially lead to a timeout or the push check failing. Therefore, we chose to include only high-confidence patterns to ensure a performant experience when pushing your code, and to reduce the number of false alerts.
|
||||
|
||||
It is currently not possible to use custom rulesets with secret push protection.
|
||||
Secret push protection scans commits for specific patterns. Each pattern matches a specific type of
|
||||
secret. To confirm which secrets are detected by secret push protection, see
|
||||
[Detected secrets](../detected_secrets.md). Only high-confidence patterns were chosen for secret
|
||||
push protection, to minimize delay when pushing your code and minimize the number of false alerts.
|
||||
You cannot customize the ruleset used by secret push protection.
|
||||
|
||||
## Enable secret push protection
|
||||
|
||||
|
|
|
|||
|
|
@ -7588,9 +7588,6 @@ msgstr ""
|
|||
msgid "Ask a maintainer to check the import status for more details."
|
||||
msgstr ""
|
||||
|
||||
msgid "Ask again later"
|
||||
msgstr ""
|
||||
|
||||
msgid "Ask someone with write access to resolve it."
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -4,8 +4,13 @@ module QA
|
|||
module Service
|
||||
module DockerRun
|
||||
class ContainerRegistryUtils < Base
|
||||
def tag_image(current_tag, new_tag)
|
||||
run_docker_command("tag #{current_tag} #{new_tag}")
|
||||
def initialize(image:)
|
||||
@image = image
|
||||
super()
|
||||
end
|
||||
|
||||
def tag_image(new_tag)
|
||||
run_docker_command("tag #{@image} #{new_tag}")
|
||||
end
|
||||
|
||||
def push_image(tag)
|
||||
|
|
|
|||
Loading…
Reference in New Issue