| yarn |
- v1, v24, v34 |
+ versions 1, 2, 3, 44 |
1.x,
2.x,
@@ -453,10 +453,10 @@ The following package managers use lockfiles that GitLab analyzers are capable o
- Support for Yarn v2 and v3 was introduced in GitLab 15.11. However, this feature is also available to versions of GitLab 15.0 and later.
+ Support for Yarn version 4 was introduced in GitLab 16.11.
- The following features are not supported for Yarn v2 or v3:
+ The following features are not supported for Yarn Berry:
-
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index 394fe8a2310..4296a8cd414 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -258,6 +258,74 @@ Note the following:
- If the CI/CD variables suffixed `_DISABLED_ANALYZERS` were declared in a policy, their values were
ignored, regardless of where they were defined: policy, group, or project.
+## Security policy scopes
+
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135398) in GitLab 16.7 [with a flag](../../../administration/feature_flags.md) named `security_policies_policy_scope`. Enabled by default.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/443594) in GitLab 16.11. Feature flag `security_policies_policy_scope` removed.
+
+Security policy enforcement depends first on establishing a link between the group, subgroup, or
+project on which you want to enforce policies, and the security policy project that contains the
+policies. For example, if you are linking policies to a group, a group owner must create the link to
+the security policy project. Then, all policies in the security policy project are inherited by all
+projects in the group.
+
+You can refine a security policy's scope to:
+
+- _Include_ only projects containing a compliance framework label.
+- _Include_ or _exclude_ selected projects from enforcement.
+
+### Policy scope schema
+
+| Field | Type | Required | Possible values | Description |
+|-------|------|----------|-----------------|-------------|
+| `policy_scope` | `object` | false | `compliance_frameworks`, `projects` | Scopes the policy based on compliance framework labels or projects you define. |
+
+#### `policy_scope` scope type
+
+| Field | Type | Possible values | Description |
+|-------|------|-----------------|-------------|
+| `compliance_frameworks` | `array` | | List of IDs of the compliance frameworks in scope of enforcement, in an array of objects with key `id`. |
+| `projects` | `object` | `including`, `excluding` | Use `excluding:` or `including:` then list the IDs of the projects you wish to include or exclude, in an array of objects with key `id`. |
+
+#### Example `policy.yml` with security policy scopes
+
+```yaml
+---
+scan_execution_policy:
+- name: Enforce DAST in every release pipeline
+ description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
+ enabled: true
+ rules:
+ - type: pipeline
+ branches:
+ - release/*
+ actions:
+ - scan: dast
+ scanner_profile: Scanner Profile A
+ site_profile: Site Profile B
+ policy_scope:
+ compliance_frameworks:
+ - id: 2
+ - id: 11
+- name: Enforce Secret Detection and Container Scanning in every default branch pipeline
+ description: This policy enforces pipeline configuration to have a job with Secret Detection and Container Scanning scans for the default branch
+ enabled: true
+ rules:
+ - type: pipeline
+ branches:
+ - main
+ actions:
+ - scan: secret_detection
+ - scan: sast
+ variables:
+ SAST_EXCLUDED_ANALYZERS: brakeman
+ policy_scope:
+ projects:
+ excluding:
+ - id: 24
+ - id: 27
+```
+
## Example security policies project
You can use this example in a `.gitlab/security-policies/policy.yml` file stored in a
@@ -438,81 +506,3 @@ scan_execution_policy:
```
In this example a `test job` is injected into the `test` stage of the pipeline, printing `Hello World`.
-
-### Security policy scopes
-
-Prerequisites:
-
-- To enable the pipeline execution policy action feature, a group owner or administrator must enable
- the experimental feature:
-
- 1. On the left sidebar, select **Search or go to** and find your group.
- 1. Select **Settings > General**.
- 1. Expand **Permissions and group features**.
- 1. Select the **Security Policy Scopes** checkbox.
- 1. Optional. Select **Enforce for all subgroups**.
-
- If the setting is not enforced for all subgroups, subgroup owners can manage the setting per subgroup.
-
-Security policy enforcement depends first on establishing a link between the group, subgroup, or
-project on which you want to enforce policies, and the security policy project that contains the
-policies. For example, if you are linking policies to a group, a group owner must create the link to
-the security policy project. Then, all policies in the security policy project are inherited by all
-projects in the group.
-
-You can refine a security policy's scope to:
-
-- _Include_ only projects containing a compliance framework label.
-- _Include_ or _exclude_ selected projects from enforcement.
-
-#### Policy scope schema
-
-| Field | Type | Required | Possible values | Description |
-|-------|------|----------|-----------------|-------------|
-| `policy_scope` | `object` | false | `compliance_frameworks`, `projects` | Scopes the policy based on compliance framework labels or projects you define. |
-
-#### `policy_scope` scope type
-
-| Field | Type | Possible values | Description |
-|-------|------|-----------------|-------------|
-| `compliance_frameworks` | `array` | | List of IDs of the compliance frameworks in scope of enforcement, in an array of objects with key `id`. |
-| `projects` | `object` | `including`, `excluding` | Use `excluding:` or `including:` then list the IDs of the projects you wish to include or exclude, in an array of objects with key `id`. |
-
-#### Example `policy.yml` with security policy scopes
-
-```yaml
----
-scan_execution_policy:
-- name: Enforce DAST in every release pipeline
- description: This policy enforces pipeline configuration to have a job with DAST scan for release branches
- enabled: true
- rules:
- - type: pipeline
- branches:
- - release/*
- actions:
- - scan: dast
- scanner_profile: Scanner Profile A
- site_profile: Site Profile B
- policy_scope:
- compliance_frameworks:
- - id: 2
- - id: 11
-- name: Enforce Secret Detection and Container Scanning in every default branch pipeline
- description: This policy enforces pipeline configuration to have a job with Secret Detection and Container Scanning scans for the default branch
- enabled: true
- rules:
- - type: pipeline
- branches:
- - main
- actions:
- - scan: secret_detection
- - scan: sast
- variables:
- SAST_EXCLUDED_ANALYZERS: brakeman
- policy_scope:
- projects:
- excluding:
- - id: 24
- - id: 27
-```
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index d265eb69d60..86018a041b7 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -384,6 +384,7 @@ The following table describes the rate limits for GitLab.com:
| **Alert integration endpoint** requests (for a given **project**) | **3600** requests per hour |
| **[Pull mirroring](../project/repository/mirror/pull.md)** intervals | **5** minutes |
| **API Requests** (from a given **user**) to `/api/v4/users/:id` | **300** requests per **10 minutes** |
+| GitLab package cloud requests for a given IP address ([introduced](https://gitlab.com/gitlab-com/gl-infra/production-engineering/-/issues/24083) in GitLab 16.11) | 3,000 requests per minute |
More details are available on the rate limits for
[protected paths](#protected-paths-throttle) and
diff --git a/doc/user/project/integrations/telegram.md b/doc/user/project/integrations/telegram.md
index 141e15f7842..099ee09aeb3 100644
--- a/doc/user/project/integrations/telegram.md
+++ b/doc/user/project/integrations/telegram.md
@@ -40,6 +40,8 @@ To configure the bot in Telegram:
## Set up the Telegram integration in GitLab
+> - **Message thread ID** [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/441097) in GitLab 16.11.
+
After you invite the bot to a Telegram channel, you can configure GitLab to send notifications:
1. To enable the integration:
diff --git a/lib/gitlab/content_security_policy/config_loader.rb b/lib/gitlab/content_security_policy/config_loader.rb
index f7c9d95c53c..6bd266ecb8f 100644
--- a/lib/gitlab/content_security_policy/config_loader.rb
+++ b/lib/gitlab/content_security_policy/config_loader.rb
@@ -48,7 +48,7 @@ module Gitlab
'media_src' => "'self' data: blob: http: https:",
'script_src' => ContentSecurityPolicy::Directives.script_src,
'style_src' => ContentSecurityPolicy::Directives.style_src,
- 'worker_src' => "#{Gitlab::Utils.append_path(Gitlab.config.gitlab.url, 'assets/')} blob: data:",
+ 'worker_src' => ContentSecurityPolicy::Directives.worker_src,
'object_src' => "'none'",
'report_uri' => nil
}
diff --git a/lib/gitlab/content_security_policy/directives.rb b/lib/gitlab/content_security_policy/directives.rb
index 09500ec623d..bd2799eda24 100644
--- a/lib/gitlab/content_security_policy/directives.rb
+++ b/lib/gitlab/content_security_policy/directives.rb
@@ -22,6 +22,10 @@ module Gitlab
def self.style_src
"'self' 'unsafe-inline'"
end
+
+ def self.worker_src
+ "'self' #{Gitlab::Utils.append_path(Gitlab.config.gitlab.url, 'assets/')} blob: data:"
+ end
end
end
end
diff --git a/spec/lib/gitlab/content_security_policy/config_loader_spec.rb b/spec/lib/gitlab/content_security_policy/config_loader_spec.rb
index 9e2f3bda14c..30f10e3b34d 100644
--- a/spec/lib/gitlab/content_security_policy/config_loader_spec.rb
+++ b/spec/lib/gitlab/content_security_policy/config_loader_spec.rb
@@ -108,6 +108,12 @@ RSpec.describe Gitlab::ContentSecurityPolicy::ConfigLoader, feature_category: :s
end
end
+ describe 'the worker-src directive' do
+ it 'can be loaded from local origins' do
+ expect(worker_src).to eq("'self' http://localhost/assets/ blob: data:")
+ end
+ end
+
describe 'Webpack dev server websocket connections' do
let(:webpack_dev_server_host) { 'webpack-dev-server.com' }
let(:webpack_dev_server_port) { '9999' }
@@ -319,7 +325,7 @@ RSpec.describe Gitlab::ContentSecurityPolicy::ConfigLoader, feature_category: :s
expect(script_src).to eq(::Gitlab::ContentSecurityPolicy::Directives.script_src)
expect(style_src).to eq(::Gitlab::ContentSecurityPolicy::Directives.style_src)
expect(font_src).to eq("'self'")
- expect(worker_src).to eq("http://localhost/assets/ blob: data:")
+ expect(worker_src).to eq(::Gitlab::ContentSecurityPolicy::Directives.worker_src)
expect(frame_src).to eq(::Gitlab::ContentSecurityPolicy::Directives.frame_src)
end
end
diff --git a/spec/migrations/migrate_custom_permissions_spec.rb b/spec/migrations/migrate_custom_permissions_spec.rb
new file mode 100644
index 00000000000..442ff053830
--- /dev/null
+++ b/spec/migrations/migrate_custom_permissions_spec.rb
@@ -0,0 +1,26 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+require_migration!
+
+RSpec.describe MigrateCustomPermissions, feature_category: :permissions do
+ let(:member_roles) { table(:member_roles) }
+ let!(:member_role_a) { member_roles.create!(name: 'a', base_access_level: 10, read_code: true) }
+ let!(:member_role_b) { member_roles.create!(name: 'b', base_access_level: 10, archive_project: true) }
+ let(:boolean_permissions_where) { { read_code: true } }
+ let(:jsonb_permissions_where) { "member_roles.permissions @> ('{\"read_code\":true}')::jsonb" }
+
+ it 'correctly migrates up and down' do
+ disable_migrations_output do
+ reversible_migration do |migration|
+ migration.before -> {
+ expect(member_roles.where(boolean_permissions_where).pluck(:id)).to contain_exactly(member_role_a.id)
+ }
+
+ migration.after -> {
+ expect(member_roles.where(jsonb_permissions_where).pluck(:id)).to contain_exactly(member_role_a.id)
+ }
+ end
+ end
+ end
+end
diff --git a/spec/models/project_export_job_spec.rb b/spec/models/project_export_job_spec.rb
index 565a2e88ee7..79fe4af2288 100644
--- a/spec/models/project_export_job_spec.rb
+++ b/spec/models/project_export_job_spec.rb
@@ -54,4 +54,55 @@ RSpec.describe ProjectExportJob, feature_category: :importers, type: :model do
end
end
end
+
+ describe 'status transitions' do
+ let(:queued) { ProjectExportJob::STATUS[:queued] }
+ let(:started) { ProjectExportJob::STATUS[:started] }
+ let(:failed) { ProjectExportJob::STATUS[:failed] }
+ let(:finished) { ProjectExportJob::STATUS[:finished] }
+
+ context 'when a new ProjectExportJob is created' do
+ let(:project_export_job) { create(:project_export_job) }
+
+ it 'is initialized in the queued state' do
+ expect(project_export_job).to be_queued
+ end
+ end
+
+ context 'when the ProjectExportJob is in queued state' do
+ let(:project_export_job) { create(:project_export_job) }
+
+ it 'can transition to started state' do
+ expect { project_export_job.start }.to change { project_export_job.status }.from(queued).to(started)
+ end
+
+ it 'can transition to failed state' do
+ expect { project_export_job.fail_op }.to change { project_export_job.status }.from(queued).to(failed)
+ end
+
+ it 'cannnot transition to finished state' do
+ expect { project_export_job.finish }.not_to change { project_export_job.status }
+ end
+ end
+
+ context 'when the ProjectExportJob is in started state' do
+ let(:project_export_job) { create(:project_export_job, status: started) }
+
+ it 'can transition to finished state' do
+ expect { project_export_job.finish }.to change { project_export_job.status }.from(started).to(finished)
+ end
+
+ it 'can transition to failed state' do
+ expect { project_export_job.fail_op }.to change { project_export_job.status }.from(started).to(failed)
+ end
+ end
+
+ context 'when the ProjectExportJob is in finished state' do
+ let(:project_export_job) { create(:project_export_job, status: finished) }
+
+ it 'does not transition further' do
+ expect { project_export_job.fail_op }.not_to change { project_export_job.status }
+ end
+ end
+ end
end
|