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-19 21:08:43 +00:00
parent 555b877303
commit 132aeb2a72
25 changed files with 844 additions and 84 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
.gitlab/ci/global.gitlab-ci.yml
View File

@ -332,6 +332,15 @@
PG_VERSION: "15"
REDIS_VERSION: "7.0"
.use-pg16:
extends:
- .pg-base-variables
services:
- !reference [.db-services-with-auto-explain, services]
variables:
PG_VERSION: "16"
REDIS_VERSION: "7.0"
.es7-services:
services:
- !reference [.zoekt-services, services]
@ -362,6 +371,14 @@
- !reference [.db-services-with-auto-explain, services]
- !reference [.es7-services, services]
.use-pg16-es7-ee:
extends:
- .use-pg16
- .zoekt-variables
services:
- !reference [.db-services-with-auto-explain, services]
- !reference [.es7-services, services]
.es8-services:
services:
- !reference [.zoekt-services, services]
@ -400,6 +417,15 @@
- !reference [.db-services-with-auto-explain, services]
- !reference [.es8-services, services]
.use-pg16-es8-ee:
extends:
- .use-pg16
- .zoekt-variables
- .es8-variables
services:
- !reference [.db-services-with-auto-explain, services]
- !reference [.es8-services, services]
.os1-services:
services:
- !reference [.zoekt-services, services]
@ -431,6 +457,14 @@
- !reference [.db-services-with-auto-explain, services]
- !reference [.os1-services, services]
.use-pg16-opensearch1-ee:
extends:
- .use-pg16
- .zoekt-variables
services:
- !reference [.db-services-with-auto-explain, services]
- !reference [.os1-services, services]
.os2-services:
services:
- !reference [.zoekt-services, services]
@ -462,6 +496,14 @@
- !reference [.db-services-with-auto-explain, services]
- !reference [.os2-services, services]
.use-pg16-opensearch2-ee:
extends:
- .use-pg16
- .zoekt-variables
services:
- !reference [.db-services-with-auto-explain, services]
- !reference [.os2-services, services]
.use-pg14-clickhouse23:
extends: .use-pg14
services:

117
.gitlab/ci/rails.gitlab-ci.yml
View File

@ -952,6 +952,39 @@ rspec system pg15:
- .rspec-base-pg15
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-system-parallel
# PG16
rspec migration pg16:
extends:
- .rspec-base-pg16
- .rspec-base-migration
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-migration-parallel
rspec background_migration pg16:
extends:
- .rspec-base-pg16
- .rspec-base-migration
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-background-migration-parallel
rspec unit pg16:
extends:
- .rspec-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-unit-parallel
rspec integration pg16:
extends:
- .rspec-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-integration-parallel
rspec system pg16:
extends:
- .rspec-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage
- .rspec-system-parallel
# EE/FOSS: default branch nightly scheduled jobs #
##########################################
@ -1109,6 +1142,90 @@ rspec-ee system pg15 es8:
extends:
- .rspec-ee-base-pg15-es8
- .rspec-ee-system-parallel
# PG16
rspec-ee unit pg16 opensearch1:
extends:
- .rspec-ee-base-pg16-opensearch1
- .rspec-ee-unit-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee unit pg16 opensearch2:
extends:
- .rspec-ee-base-pg16-opensearch2
- .rspec-ee-unit-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee integration pg16 opensearch1:
extends:
- .rspec-ee-base-pg16-opensearch1
- .rspec-ee-integration-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee integration pg16 opensearch2:
extends:
- .rspec-ee-base-pg16-opensearch2
- .rspec-ee-integration-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee system pg16 opensearch1:
extends:
- .rspec-ee-base-pg16-opensearch1
- .rspec-ee-system-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee system pg16 opensearch2:
extends:
- .rspec-ee-base-pg16-opensearch2
- .rspec-ee-system-parallel
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
rspec-ee migration pg16:
extends:
- .rspec-ee-base-pg16
- .rspec-base-migration
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
- .rspec-ee-migration-parallel
rspec-ee background_migration pg16:
extends:
- .rspec-ee-base-pg16
- .rspec-base-migration
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
- .rspec-ee-background-migration-parallel
rspec-ee unit pg16:
extends:
- .rspec-ee-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
- .rspec-ee-unit-parallel
rspec-ee unit pg16 es8:
extends:
- .rspec-ee-base-pg16-es8
- .rspec-ee-unit-parallel
rspec-ee integration pg16:
extends:
- .rspec-ee-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
- .rspec-ee-integration-parallel
rspec-ee integration pg16 es8:
extends:
- .rspec-ee-base-pg16-es8
- .rspec-ee-integration-parallel
rspec-ee system pg16:
extends:
- .rspec-ee-base-pg16
- .rails:rules:default-branch-schedule-nightly--code-backstage-ee-only
- .rspec-ee-system-parallel
rspec-ee system pg16 es8:
extends:
- .rspec-ee-base-pg16-es8
- .rspec-ee-system-parallel
# EE: default branch nightly scheduled jobs #
#####################################

28
.gitlab/ci/rails/shared.gitlab-ci.yml
View File

@ -187,6 +187,11 @@ include:
- .rspec-base
- .use-pg15
.rspec-base-pg16:
extends:
- .rspec-base
- .use-pg16
.rspec-ee-base-pg13:
extends:
- .rspec-base
@ -256,6 +261,29 @@ include:
- .use-pg15-opensearch2-ee
- .rails:rules:run-search-tests
.rspec-ee-base-pg16:
extends:
- .rspec-base
- .use-pg16-es7-ee
.rspec-ee-base-pg16-es8:
extends:
- .rspec-base
- .use-pg16-es8-ee
- .rails:rules:run-search-tests
.rspec-ee-base-pg16-opensearch1:
extends:
- .rspec-base
- .use-pg16-opensearch1-ee
- .rails:rules:run-search-tests
.rspec-ee-base-pg16-opensearch2:
extends:
- .rspec-base
- .use-pg16-opensearch2-ee
- .rails:rules:run-search-tests
.db-job-base:
extends:
- .rails-job-base

2
.gitlab/ci/static-analysis.gitlab-ci.yml
View File

@ -219,7 +219,7 @@ templates-shellcheck:
- .default-before_script
- .default-retry
- .ruby-cache
- .use-pg15
- .use-pg16
stage: lint
needs:
- setup-test-env

2
Gemfile
View File

@ -522,7 +522,7 @@ group :test do
# Moved in `test` because https://gitlab.com/gitlab-org/gitlab/-/issues/217527
gem 'derailed_benchmarks', require: false # rubocop:todo Gemfile/MissingFeatureCategory
gem 'gitlab_quality-test_tooling', '~> 1.14.2', require: false, feature_category: :tooling
gem 'gitlab_quality-test_tooling', '~> 1.15.0', require: false, feature_category: :tooling
end
gem 'octokit', '~> 8.0', feature_category: :importers

2
Gemfile.checksum
View File

@ -227,7 +227,7 @@
{"name":"gitlab-styles","version":"11.0.0","platform":"ruby","checksum":"0dd8ec066ce9955ac51d3616c6bfded30f75bb526f39ff392ece6f43d5b9406b"},
{"name":"gitlab_chronic_duration","version":"0.12.0","platform":"ruby","checksum":"0d766944d415b5c831f176871ee8625783fc0c5bfbef2d79a3a616f207ffc16d"},
{"name":"gitlab_omniauth-ldap","version":"2.2.0","platform":"ruby","checksum":"bb4d20acb3b123ed654a8f6a47d3fac673ece7ed0b6992edb92dca14bad2838c"},
{"name":"gitlab_quality-test_tooling","version":"1.14.2","platform":"ruby","checksum":"9ee343328d5e755b54d97729adc5a743abd83b05e9b28d9bbbe74f393b6cf658"},
{"name":"gitlab_quality-test_tooling","version":"1.15.0","platform":"ruby","checksum":"33416dce2d6a686ea95643eb650a249e94f696731e7f7c5bc552b369b2ba0bb5"},
{"name":"globalid","version":"1.1.0","platform":"ruby","checksum":"b337e1746f0c8cb0a6c918234b03a1ddeb4966206ce288fbb57779f59b2d154f"},
{"name":"gon","version":"6.4.0","platform":"ruby","checksum":"e3a618d659392890f1aa7db420f17c75fd7d35aeb5f8fe003697d02c4b88d2f0"},
{"name":"google-apis-androidpublisher_v3","version":"0.34.0","platform":"ruby","checksum":"d7e1d7dd92f79c498fe2082222a1740d788e022e660c135564b3fd299cab5425"},

4
Gemfile.lock
View File

@ -742,7 +742,7 @@ GEM
omniauth (>= 1.3, < 3)
pyu-ruby-sasl (>= 0.0.3.3, < 0.1)
rubyntlm (~> 0.5)
gitlab_quality-test_tooling (1.14.2)
gitlab_quality-test_tooling (1.15.0)
activesupport (>= 6.1, < 7.1)
amatch (~> 0.4.1)
gitlab (~> 4.19)
@ -1935,7 +1935,7 @@ DEPENDENCIES
gitlab-utils!
gitlab_chronic_duration (~> 0.12)
gitlab_omniauth-ldap (~> 2.2.0)
gitlab_quality-test_tooling (~> 1.14.2)
gitlab_quality-test_tooling (~> 1.15.0)
gon (~> 6.4.0)
google-apis-androidpublisher_v3 (~> 0.34.0)
google-apis-cloudbilling_v1 (~> 0.21.0)

14
doc/api/graphql/reference/index.md
View File

@ -1418,6 +1418,7 @@ Input type: `AiActionInput`
| <a id="mutationaiactiongeneratedescription"></a>`generateDescription` | [`AiGenerateDescriptionInput`](#aigeneratedescriptioninput) | Input for generate_description AI action. |
| <a id="mutationaiactionresolvevulnerability"></a>`resolveVulnerability` | [`AiResolveVulnerabilityInput`](#airesolvevulnerabilityinput) | Input for resolve_vulnerability AI action. |
| <a id="mutationaiactionsummarizecomments"></a>`summarizeComments` | [`AiSummarizeCommentsInput`](#aisummarizecommentsinput) | Input for summarize_comments AI action. |
| <a id="mutationaiactionsummarizenewmergerequest"></a>`summarizeNewMergeRequest` | [`AiSummarizeNewMergeRequestInput`](#aisummarizenewmergerequestinput) | Input for summarize_new_merge_request AI action. |
| <a id="mutationaiactionsummarizereview"></a>`summarizeReview` | [`AiSummarizeReviewInput`](#aisummarizereviewinput) | Input for summarize_review AI action. |
#### Fields
@ -34985,6 +34986,19 @@ see the associated mutation type above.
| ---- | ---- | ----------- |
| <a id="aisummarizecommentsinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
### `AiSummarizeNewMergeRequestInput`
Summarize a new merge request based on two branches. Returns `null` if the `add_ai_summary_for_new_mr` feature flag is disabled.
#### Arguments
| Name | Type | Description |
| ---- | ---- | ----------- |
| <a id="aisummarizenewmergerequestinputresourceid"></a>`resourceId` | [`AiModelID!`](#aimodelid) | Global ID of the resource to mutate. |
| <a id="aisummarizenewmergerequestinputsourcebranch"></a>`sourceBranch` | [`String!`](#string) | Source branch of the changes. |
| <a id="aisummarizenewmergerequestinputsourceprojectid"></a>`sourceProjectId` | [`ID`](#id) | ID of the project where the changes are from. |
| <a id="aisummarizenewmergerequestinputtargetbranch"></a>`targetBranch` | [`String!`](#string) | Target branch of where the changes will be merged into. |
### `AiSummarizeReviewInput`
#### Arguments

2
doc/architecture/blueprints/cells/infrastructure/deployments.md
View File

@ -8,7 +8,7 @@ coach:
approvers: []
---
Disclaimer: This blueprint requires more cross-functional alignment - [Confidence Level] --> Low
Disclaimer: This blueprint requires more cross-functional alignment - **Confidence Level:** Low
# Application Deployment with a Cellular Architecture

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

@ -123,7 +123,7 @@ However, Service-Integration will establish certain necessary and optional requi
| ID | Required | Detail | Epic/Issue | Done? |
|---|---|---|---|---|
| `R100` | Required | The platform should be easy to use: imagine Heroku with [GitLab Production Readiness-approved](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/readiness/) defaults. | [Runway to [BETA] : Increased Adoption and Self Service](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1115) | **{dotted-circle}** No |
| `R110` | Required | With the exception of an Infrastructure-led onboarding process, services are owned, deployed and managed by stage-group teams. In other words,services follow a “You Build It, You Run It” model of ownership.| [[Paused] Discussion: Tiered Support Model for Runway](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/issues/97) | **{dotted-circle}** No |
| `R110` | Required | With the exception of an Infrastructure-led onboarding process, services are owned, deployed and managed by stage-group teams. In other words,services follow a "You Build It, You Run It" model of ownership.| [[Paused] Discussion: Tiered Support Model for Runway](https://gitlab.com/gitlab-com/gl-infra/platform/runway/team/-/issues/97) | **{dotted-circle}** No |
| `R120` | Required | Programming-language agnostic: no requirements for services. Services should be packaged as container images.| [Runway to [BETA] : Increased Adoption and Self Service](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/1115) | **{dotted-circle}** No |
| `R130` | Recommended | Each service should be evaluated against the GitLab.com [Service Maturity Model](https://handbook.gitlab.com/handbook/engineering/infrastructure/service-maturity-model/).| [Discussion: Introduce an 'Infrastructure Well-Architected Service Framework'](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/2537) | **{dotted-circle}** No |
| `R140` | Recommended | Services using the platform have expedited production-readiness processes. {::nomarkdown}<ol><li>Production-readiness requirements graded by service maturity: low-traffic, low-maturity experimental services will have lower requirement thresholds than more mature services. </li><li> By default, the platform should provide services with defaults that would pass production-readiness review for the lowest service maturity-level. </li><li> At introduction, lowest maturity services can be deployed without production readiness, provided the meet certain automatically validated requirements. This removes Infrastructure gate-keeping from being a blocker to experimental service delivery.</li></ol>{:/} | | |

100
doc/development/fe_guide/frontend_goals.md
View File

@ -17,7 +17,7 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
**Current Status**
- **As of December 2023**: GitLab is currently using Vue 2.x.
- **Progress**: [Brief description of progress]
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -26,11 +26,11 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
@ -38,12 +38,12 @@ Keeping up with the latest version of Vue ensures that the GitLab frontend lever
### State Management
When global state management is needed, it should happen in Apollo instead of Vuex or other state management libraries. See [https://docs.gitlab.com/ee/development/fe_guide/migrating_from_vuex.html](migrating_from_vuex.md) for more details regarding why and how we plan on migrating.
When global state management is needed, it should happen in Apollo instead of Vuex or other state management libraries. See [Migrating from Vuex](migrating_from_vuex.md) for more details regarding why and how we plan on migrating.
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -52,24 +52,24 @@ When global state management is needed, it should happen in Apollo instead of Vu
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### HAML by default
We'll continue using HAML over Vue when appropriate. See [https://docs.gitlab.com/ee/development/fe_guide/vue.html#when-to-add-vue-application](vue.md#when-to-add-vue-application) on how to decide when Vue should be chosen.
We'll continue using HAML over Vue when appropriate. See [when to add Vue application](vue.md#when-to-add-vue-application) on how to decide when Vue should be chosen.
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -78,15 +78,15 @@ We'll continue using HAML over Vue when appropriate. See [https://docs.gitlab.co
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### Complete removal of jQuery
@ -94,8 +94,8 @@ In 2019 we committed to no longer use jQuery, however we have not prioritized fu
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -104,15 +104,15 @@ In 2019 we committed to no longer use jQuery, however we have not prioritized fu
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### Dependencies management
@ -120,8 +120,8 @@ Similar to keeping on the latest major version of Vue, we should try to keep as
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -130,15 +130,15 @@ Similar to keeping on the latest major version of Vue, we should try to keep as
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
## Best Practices
@ -168,8 +168,8 @@ For navigation between clusters, we can still rely on Rails routing. These cases
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -178,15 +178,15 @@ For navigation between clusters, we can still rely on Rails routing. These cases
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### Reusable components
@ -203,8 +203,8 @@ This is currently under development. Follow the [GitLab Modular Monolith for FE]
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -213,15 +213,15 @@ This is currently under development. Follow the [GitLab Modular Monolith for FE]
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### Migrate to PostCSS
@ -229,8 +229,8 @@ SASS compilation takes almost half of the total frontend compilation time. This
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -239,15 +239,15 @@ SASS compilation takes almost half of the total frontend compilation time. This
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
## Collaboration and Tooling
@ -257,8 +257,8 @@ We're early in the process of adding visual testing, but we should have a framew
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -267,15 +267,15 @@ We're early in the process of adding visual testing, but we should have a framew
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)
### Accessibility testing
@ -283,8 +283,8 @@ In 2023 we determined the tooling for accessibility testing. We opted for axe-co
**Current Status**
- **As of December 2023**: [Status]
- **Progress**: [Brief description of progress]
- **As of December 2023**: (Status)
- **Progress**: (Brief description of progress)
**Responsible Team**
@ -293,12 +293,12 @@ In 2023 we determined the tooling for accessibility testing. We opted for axe-co
**Milestones and Timelines**
- [Key milestones, expected completions]
- (Key milestones, expected completions)
**Challenges and Dependencies**
- [Any major challenges]
- (Any major challenges)
**Success Metrics**
- [Potential metrics]
- (Potential metrics)

4
doc/development/pipelines/index.md
View File

@ -681,7 +681,7 @@ This should let us:
Our test suite runs against PostgreSQL 14 as GitLab.com runs on PostgreSQL 14 and
[Omnibus defaults to PG14 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
We do run our test suite against PostgreSQL 14 on nightly scheduled pipelines.
We run our test suite against PostgreSQL 13, 14, 15 and 16 on nightly scheduled pipelines.
We also run our test suite against PostgreSQL 13 upon specific database library changes in merge requests and `main` pipelines (with the `rspec db-library-code pg13` job).
@ -694,7 +694,7 @@ We also run our test suite against PostgreSQL 13 upon specific database library
| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour at XX:05) | 14 (default version), 13 for DB library changes | 3.1 (default version) |
| `maintenance` scheduled pipelines for the `ruby3_0` branch (every odd-numbered hour at XX:40) | 14 (default version), 13 for DB library changes | 3.0 |
| `maintenance` scheduled pipelines for the `ruby3_2` branch (every odd-numbered hour at XX:10) | 14 (default version), 13 for DB library changes | 3.2 |
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 13, 15 | 3.1 (default version) |
| `nightly` scheduled pipelines for the `master` branch | 14 (default version), 13, 15, 16 | 3.1 (default version) |
For each current Ruby versions we're testing against with, we run
maintenance scheduled pipelines every 2 hours on their respective `ruby\d_\d`

2
doc/development/pipelines/internals.md
View File

@ -181,6 +181,8 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
| `.use-pg14-ee` | Same as `.use-pg14` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
| `.use-pg15` | Allows a job to use the `postgres` 15, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
| `.use-pg15-ee` | Same as `.use-pg15` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
| `.use-pg16` | Allows a job to use the `postgres` 16, `redis`, and `rediscluster` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
| `.use-pg16-ee` | Same as `.use-pg16` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
| `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
| `.use-docker-in-docker` | Allows a job to use Docker in Docker. For more details, see the [handbook about CI/CD configuration](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration). |

2
doc/solutions/cloud/aws/gitlab_aws_integration.md
View File

@ -54,7 +54,7 @@ Documentation and References:
#### AWS CodePipeline Integrations
[AWS CodePipeline Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab.html) - by using GitLab as CodeStar Connections source for CodePipeline, additional AWS service integrations are available. [[12/28/2023](https://aws.amazon.com/about-aws/whats-new/2023/12/codepipeline-gitlab-self-managed/)] `[AWS Built]`
[AWS CodePipeline Integration](https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-gitlab.html) - by using GitLab as CodeStar Connections source for CodePipeline, additional AWS service integrations are available. ([12/28/2023](https://aws.amazon.com/about-aws/whats-new/2023/12/codepipeline-gitlab-self-managed/)) `[AWS Built]`
AWS Services that are supported by an AWS CodePipeline integration:

4
doc/tutorials/boards_for_teams/index.md
View File

@ -135,7 +135,7 @@ To create the **UX workflow** issue board:
1. Clear the **Show the Open list** and **Show the Closed list** checkboxes.
1. Select **Create board**. You should see an empty board.
1. Create a list for the `Workflow::Ready for design` label:
1. In the upper-left corner of the issue board page, select **Create list**.
1. In the upper-right corner of the issue board page, select **Create list**.
1. In the column that appears, from the **Value** dropdown list, select the `Workflow::Ready for design` label.
1. Select **Add to board**.
1. Repeat the previous step for labels `Workflow::Design` and `Workflow::Ready for development`.
@ -152,7 +152,7 @@ To create the **Frontend workflow** board:
1. Next to **Labels**, select **Edit** and select the `Frontend` label.
1. Select **Create board**.
1. Create a list for the `Workflow::Ready for development` label:
1. In the upper-left corner of the issue board page, select **Create list**.
1. In the upper-right corner of the issue board page, select **Create list**.
1. In the column that appeared, from the **Value** dropdown list, select the `Workflow::Ready for development` label.
1. Select **Add to board**.
1. Repeat the previous step for labels `Workflow::In development` and `Workflow::Complete`.

4
doc/tutorials/issue_triage/index.md
View File

@ -165,11 +165,11 @@ To set up your issue board:
1. Select **Plan > Issue boards**.
1. In the upper-left corner of the issue board page, select the dropdown list with the current board name.
1. Select **Create new board**.
1. In the **Title field**, enter `Issue triage (by severity)`.
1. In the **Title** field, enter `Issue triage (by severity)`.
1. Keep the **Show the Open list** checkbox selected and clear the **Show the Closed list** one.
1. Select **Create board**. You should see an empty board.
1. Create a list for the `severity::1` label:
1. In the upper-left corner of the issue board page, select **Create list**.
1. In the upper-right corner of the issue board page, select **Create list**.
1. In the column that appears, from the **Value** dropdown list, select the `severity::1` label.
1. Select **Add to board**.
1. Repeat the previous step for labels `severity::2`, `severity::3`, and `severity::4`.

BIN
doc/tutorials/scrum_events/img/epic_board_demo_v16_9.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

BIN
doc/tutorials/scrum_events/img/issue_board_demo_v16_10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 34 KiB

BIN
doc/tutorials/scrum_events/img/story_threads_v16_10.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 39 KiB

556
doc/tutorials/scrum_events/index.md Normal file
View File

@ -0,0 +1,556 @@
---
stage: Plan
group: Project Management
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
---
# Tutorial: Use GitLab to facilitate Scrum
DETAILS:
**Tier:** Premium, Ultimate
**Offering:** SaaS, self-managed
<!-- vale gitlab.FutureTense = NO -->
This tutorial provides step-by-step guidance on using agile planning and tracking features in GitLab
to facilitate core Scrum ceremonies and workflows.
By setting up groups, projects, boards, and other features in a deliberate way, teams can realize
enhanced transparency, collaboration, and delivery cadences.
According to Martin Fowler's [Agile Fluency Model](https://martinfowler.com/articles/agileFluency.html), teams practicing [Scrum](https://scrumguides.org/scrum-guide.html):
> ...think and plan in terms of the benefits their sponsors, customers, and users will see from their software.
They achieve this by demonstrating their progress monthly; regularly reflecting on improving their
processes and work habits to provide more business and customer value.
This tutorial covers the following topics:
- Setting up GitLab
- Understand inheritance model in GitLab
- Create your group
- Create your projects
- Create labels
- Create an iteration cadence
- Managing your feature backlog
- How to structure your work
- Setup a release planning board
- Write your first feature
- Managing your story backlog
- Break down features into stories
- Refine your story backlog
- Tracking sprint progress
- Manage the workflow of stories in your sprint
- View burndown/up charts for your sprint
- Facilitating other Scrum ceremonies in GitLab
- Synchronous and asynchronous stand-up
- Synchronous and asynchronous retrospective
- Advanced tips and tricks
- Leverage issue templates
- Decide on a story point scale
- Measure velocity and lower your team's volatility
## Setting up your groups and projects
To facilitate Scrum practices in GitLab, you first need to set up the foundational structure of groups
and projects.
You'll use groups to create boards and labels that can be inherited by projects nested under that group.
Projects will contain the issues and tasks that make up the actual work items for each sprint.
### Understanding the inheritance model in GitLab
GitLab has a hierarchical structure where groups contain projects.
Settings and configurations applied at the group level cascade down to child projects, so you can
standardize labels, boards, and iterations across multiple projects:
```mermaid
flowchart TD
Group -->|Contains| Project
Group -->|Contains| Epics
Group -->|Contains| Labels
Group -->|Contains| Boards
Group -->|Contains| Iterations
Project -->|Contains| Issues
Labels .->|Cascades To| Project
Issues .->|Rolls Up To| Group
Iterations .->|Cascades To| Project
Issues .->|Assigned To| Epics
Issues .->|Visible In| Boards
Issues .->|Assigned To| Iterations
```
- Groups contain one or more projects, epics, boards, labels, and iterations.
User membership in groups cascades down to a group's projects.
- You can create boards and labels in a group or project.
For this tutorial, you should create them in a group to facilitate standardized planning workflows
and reporting across many projects in a single group.
- Any object that cascades down to a project can be associated with that project's issues,
for example: you can apply labels from a group to issues.
### Create your group
Create a dedicated group for your Scrum activities.
This will be the parent container for projects and configurations like boards and labels that you want
to be standardized across projects.
This group will be the primary location for the different activities during a typical Scrum cadence.
It will contain your boards, features (epics), story (issue) roll up, and labels.
To create a group:
1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New group**.
1. Select **Create group**.
1. In the **Group name** text box, enter the name of the group. For a list of words that cannot be used as group names, see
[reserved names](../../user/reserved_names.md).
1. In the **Group URL** text box, enter the path for the group used for the [namespace](../../user/namespace/index.md).
1. Select the [**Visibility level**](../../user/public_access.md) of the group.
1. Optional. To personalize your GitLab experience:
- From the **Role** dropdown list, select your role.
- For **Who will be using this group?**, select an option.
- From the **What will you use this group for?** dropdown list, select an option.
1. Optional. To invite members to the group, in the **Email 1** text box, enter the email address of the user you want to invite. To invite more users, select **Invite another member** and enter the user's email address.
1. Select **Create group**.
### Create your projects
In the group you created, create one or more projects.
Your project will contain the stories that roll up to your parent group.
To create a blank project:
1. On the left sidebar, at the top, select **Create new** (**{plus}**) and **New project/repository**.
1. Select **Create blank project**.
1. Enter the project details:
- In the **Project name** field, enter the name of your project. See the
[limitations on project names](../../user/reserved_names.md).
- In the **Project slug** field, enter the path to your project. The GitLab instance uses the
slug as the URL path to the project. To change the slug, first enter the project name,
then change the slug.
- To modify the project's [viewing and access rights](../../user/public_access.md) for
users, change the **Visibility Level**.
- To create README file so that the Git repository is initialized, has a default branch, and
can be cloned, select **Initialize repository with a README**.
1. Select **Create project**.
### Create scoped labels to support different phases of the Scrum lifecycle
Next, in the group you've created, you'll create labels to add to issues to categorize them.
The best tool for this is [scoped labels](../../user/project/labels.md#scoped-labels), which you
can use to set mutually exclusive attributes.
The double colon (`::`) in the name of a scoped label prevents two labels of the same scope being
used together.
For example, if you add the `status::in progress` label to an issue that already has `status::ready`,
the previous one is removed.
To create each label:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Manage > Labels**.
1. Select **New label**.
1. In the **Title** field, enter the name of the label. Start with `priority::now`.
1. Optional. Select a color by selecting from the available colors, or enter a hex color value for
a specific color in the **Background color** field.
1. Select **Create label**.
Repeat these steps to create all the labels you'll need:
- **Priority:** You will use these on an epic board to facilitate feature-level release prioritization.
- `priority::now`
- `priority::next`
- `priority::later`
- **Status:** You will use these labels on an issue board to understand a story's current step in the
overall development lifecycle.
- `status::triage`
- `status::refine`
- `status::ready`
- `status::in progress`
- `status::in review`
- `status::acceptance`
- `status::done`
- **Type:** You will use these labels to represent the different types of work typically pulled into a single iteration:
- `type::story`
- `type::bug`
- `type::mantainence`
### Create an iteration cadence
In GitLab, sprints are called iterations.
Iteration cadences contain the individual, sequential iteration timeboxes for planning and reporting
on your issues.
Similar to labels, iterations cascade down your group, subgroup, and project hierarchy.
That's why you'll create the iteration cadence in the group you've created.
Prerequisites:
- You must have at least the Reporter role for a group.
To create an iteration cadence:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Iterations**.
1. Select **New iteration cadence**.
1. Enter the title and description of the iteration cadence.
1. Make sure the **Enable automatic scheduling** checkbox is selected.
1. Complete the required fields to use automatic scheduling.
- Select the automation start date of the iteration cadence. Iterations are scheduled to
begin on the same day of the week as the day of the week of the start date.
- From the **Duration** dropdown list, select **2**.
- From the **Upcoming iterations** dropdown list, select **4**.
- Select the **Enable roll over** checkbox.
1. Select **Create cadence**. The cadence list page opens.
With your iteration cadence configured this way:
- Each sprint is two weeks in length.
- GitLab automatically creates four sprints in the future.
- Incomplete issues from one sprint are automatically reassigned to the next sprint when the current sprint is closed.
You can also disable **Automatic scheduling** and
[manually create and manage iterations](../../user/group/iterations/index.md#create-an-iteration-manually) in your cadence.
## Managing your feature backlog
A feature backlog captures ideas and desired functionality in the form of epics.
As you refine this backlog, epics will be prioritized to flow into upcoming sprints.
This section covers creating an epic board to facilitate backlog management and writing your first
feature epic.
### Decide on a way to structure your work
GitLab is extensible to support different flavors of backlog management.
For this tutorial, we will structure our deliverables in the following way:
```mermaid
flowchart TD
Epic["Feature (Epic)"] --> Issue["Job Story (Issue)"]
Issue --> Task["Implementation Step (Task)"]
```
- An epic represents a feature that a team can deliver in a single iteration.
- Each epic will contain many
[job stories](https://medium.com/@umang.soni/moving-from-user-role-based-approach-to-problem-statement-based-approach-for-product-development-18b2d2395e5).
- A story should provide tangible customer value, contain explicit acceptance criteria, and be small
enough that an individual can complete it in one or two days.
- You should be able to complete four to ten stories as a team per sprint.
- While there are many strategies for splitting features, a great strategy is to
[vertically slice](https://www.agilerant.info/vertical-slicing-to-boost-software-value/) stories
into discrete, standalone stories a user must take to accomplish their goal.
While you might not be able to ship a single story to your customers, your team should be able to
test and interact with each story by using a feature flag on production or in a staging environment.
Not only does this help provide stakeholders visibility into the story's progress, but also is a
mechanism to break down more complex features into approachable development goals.
- Depending on the complexity of the stories, you can use tasks to break down stories into discrete
implementation steps developers need to take to complete the story.
In terms of time horizons, target the following guidelines to sizing and scoping work items:
- A **feature** can be completed in a single iteration.
- A **story** can be completed in a few days.
- A **task** can be completed in a few hours to a day.
#### Example: Vertically slicing a feature
Here's an example of breaking a feature into vertically sliced job stories based on the end user's
journey:
```mermaid
Epic["Epic: When using the application, I need to create an <br> account, so that I can use the application features"] --> Issue1["Issue: When creating my account, I need to specify my email address,<br> so that I can receive future updates from the application"]
Epic --> Issue2["Issue: When creating my account, I need to <br>specify a password, so that my account remains secure"]
Epic --> Issue3["Issue: When creating my account and entering the required info, I need to <br>finalize creating my account, so that I can login"]
```
You've taken the feature of an unmodified account sign-up for an application and broke it down into
three discrete stories:
1. Entering an email address.
1. Entering a password.
1. Selecting a button to execute the account creation.
After you have broken down a feature into stories, you can further break down the story into discrete
implementation steps:
```mermaid
flowchart TD
Issue1["Issue: When creating my account, I need to specify my email address,<br> so that I can receive future updates from the application"]
Issue1 --> Task2["Task: Backend - Validate email formatting"]
Issue1 --> Task3["Task: Backend - API endpoint to accept POST request from client"]
Issue1 --> Task4["Task: Frontend - Display email input"]
Issue1 --> Task5["Task: Frontend - Display error message when validation fails"]
```
### Set up a release planning board
You've defined your deliverables structure.
The next step is to create an epic board that you will use to develop and maintain your feature backlog.
To create a new epic board:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Epic boards**.
1. In the upper-left corner, select the dropdown list with the current board name.
1. Select **Create new board**.
1. Enter the new board's title: `Release Planning`.
1. Select **Create board**.
Next, [create lists](../../user/group/epics/epic_boards.md#create-a-new-list) for the `priority::later`,
`priority::next`, and `priority::now` labels.
To create a new list:
1. In the upper-right corner of your board, select **Create list**.
1. In the **New list** column expand the **Select a label** dropdown list and select the label to use as
list scope.
1. Select **Add to board**.
You'll use these lists to facilitate moving features through your board from left to right.
Use each list in your release planning board to represent the following time horizons:
- **Open:** Features that are not yet ready for prioritization.
- **Later:** Features that will be prioritized into a later release.
- **Next:** Features tentatively planned for the next release.
- **Now:** Features prioritized for your current release.
- **Closed:** Features that have been completed or canceled.
### Create your first epic
Next, create a new epic in the `priority::now` list:
1. On the top of the **`priority::now`** list, select the **New epic** (**{plus}**) icon.
1. Enter the new epic's title:
```plaintext
When using the application, I need to create an account, so that I can use the application features.
```
1. Select **Create epic**.
When you complete this step, your board should look like this:
![Example epic board](img/epic_board_demo_v16_9.png)
You can now use the **Release Planning** board to quickly build your backlog.
Stub out many features and prioritize them into the **Now**, **Next**, **Later** lists.
Next, spend some time to further break down each story into stories and tasks.
To reorder feature epics in a list or across lists, drag the epic cards.
You can also [move cards to the top or bottom](../../user/group/epics/epic_boards.md#move-an-epic-to-the-start-of-the-list) of a list.
## Managing your story backlog
When you have features defined as epics, the next step is to break down those features into granular,
vertical slices as issues.
You will then refine and sequence those issues across iterations on a dedicated backlog board.
### Break down features into stories
Break features into vertically sliced stories ahead of time to have an efficient sprint planning meeting.
In the previous step, you created your first feature.
Let's break that down into stories.
To create your first stories:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Epic boards**.
1. In the upper-left corner, make sure the dropdown list with the current board name shows **Release Planning**.
If not, from the dropdown list, select that board.
1. Open an epic by clicking the title of the epic card.
1. In the **Child issues and epics** section, select **Add > Add a new issue**.
1. Enter the following title for the issue:
```plaintext
When creating my account, I need to specify my email address so that I can receive future updates from the application
```
1. From the **Project** dropdown list, select the project where you want to create the issue.
1. Select **Create issue**.
1. Repeat this process for the other two vertical slices:
```plaintext
When creating my account, I need to specify a password so that my account remains secure
```
```plaintext
When creating my account and entering the required information, I need to finalize creating my account so that I can log in
```
### Refine your story backlog
In the previous step, you broke down a feature into the necessary user stories to complete the feature.
Next, set up an issue board to serve as your canonical location for managing and refining your story backlog.
In your group, create a new issue board titled **Backlog**.
You will use this board to sequence and schedule your stories into upcoming sprints (iterations):
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Issue boards**.
1. In the upper-left corner, select the dropdown list with the current board name.
1. Select **Create new board**.
1. Enter the new board's title: `Backlog`.
1. Select **Create board**.
After you've created the board, create a new list for each upcoming iteration:
1. In the upper-right corner of the issue board page, select **Create list**.
1. In the column that appears, under **Scope**, select **Iteration**.
1. From the **Value** dropdown list, select one of the iterations.
1. Select **Add to board**.
1. Repeat the previous step for the other upcoming iterations.
Then, when an iteration is over, you should [remove the completed iteration list](../../user/project/issue_board.md#remove-a-list)
and add a new list for the new future iteration that was automatically created based on your cadence settings.
At this point, stories haven't been estimated or refined into tasks.
Mark them for refinement:
1. [Select each issue's card](../../user/project/issue_board.md#edit-an-issue) in the board and apply the `status::refine` label:
1. In the **Labels** section of the sidebar, select **Edit**.
1. From the **Assign labels** list, select the `status::refine` label.
1. Select **X** next to **Assign labels** or select any area outside the label section.
1. Drag the three stories into the desired upcoming sprint to assign the stories to the corresponding sprint timebox.
By this point in the tutorial, your **Backlog** board should look like this:
![Example issue board](img/issue_board_demo_v16_10.png)
In practice, you will use this board to sequence many stories into upcoming iterations.
When your backlog grows, and you have dozens of stories spanning multiple features, it can be helpful
to enable [**Group by epic**](../../user/project/issue_board.md#group-issues-in-swimlanes) so you can
view stories related to their corresponding feature epic.
When stories are grouped, it's easier to sequence them into upcoming sprints.
### Sprint planning ceremony
With the backlog prepared, it's time to plan the upcoming sprint.
You can use synchronous and asynchronous ways to facilitate sprint planning meetings in GitLab.
#### Synchronous planning
When it's time for your sprint planning ceremony, pull up the **Backlog** board with the team and
work through each story.
You should start planning for your next sprint on the last day of your current sprint.
While discussing each issue:
- Review and collaborate on the acceptance criteria.
You can capture this in the issue's description by using checklists or list items.
- Further [break down the story into tasks](../../user/tasks.md#create-a-task) for each implementation step.
- Estimate the issue's story point effort or complexity and set this value in the issue's **Weight** field.
- After the team is satisfied with the scope of the issue and agrees on the story point value,
apply the `status::ready` label to the issue:
1. In the **Labels** section of the sidebar, select **Edit**.
1. From the **Assign labels** list, select the `status::ready` label.
1. Select **X** next to **Assign labels** or select any area outside the label section.
After you've cycled through all the issues in the upcoming iteration, you're done with sprint planning!
Remember to incorporate your team's velocity into your sprint commitment.
You can find the total number of story points (weight) allocated to each sprint at the top of each iteration list.
It's also worth making sure story points that will likely roll over from the previous sprint.
#### Asynchronous planning
Instead of holding a synchronous meeting, use an issue to run your sprint planning.
Given the nature of asynchronous sprint planning, you should start this a few days before the end of
the current sprint.
Provide all team members the appropriate time to contribute and collaborate.
1. Open the **Backlog** issue board:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Issue boards**.
1. In the upper-left corner, select the dropdown list with the current board name.
1. Select **Backlog**.
1. In the list for the upcoming sprint, select **Create new issue** (**{plus-square}**).
1. Enter the issue's title: `Release Planning`.
1. Select **Create issue**.
1. Open the issue and create a discussion thread for each story assigned to the upcoming sprint.
Append `+` to the issue URL to automatically unfurl the title.
Append `+s` to the issue URL to automatically unfurl the title, milestone, and assignees.
You can use the following template for these threads to create checkboxes:
```markdown
## https://gitlab.example.com/my-group/application-b/-/issues/5+
- [ ] Acceptance criteria defined
- [ ] Weight set
- [ ] Implementation steps (tasks) created
```
For example:
![Example threads for planned stories](img/story_threads_v16_10.png)
1. After every story has a thread, edit the issue description and [mention each team member](../../user/discussions/index.md#mentions).
Mentioning team members automatically creates a to-do item for them in their respective [to-do lists](../../user/todos.md).
1. Then, asynchronously, before the start of the upcoming sprint, team members should:
- Discuss each issue, ask questions, and collaborate to align on the acceptance criteria for each planned issue.
- Use a reaction emoji such as `:one:`, `:two:`, and `:three:` to cast their vote on what the story point (weight) should be.
If team members set different story point values, it's an excellent opportunity to discuss further until there is consensus.
You can also average all the various reactions to align on what the story point will be.
- Break down vertical slices (issues) into implementation steps (tasks).
1. As each story discussion concludes, update the issue with any changes to the acceptance criteria
and set the story point value in the **Weight** field.
1. After the story is updated, add the `status::ready` label to each issue.
1. Then, to signal the planning for that vertical slice has been completed,
[resolve each discussion thread](../../user/discussions/index.md#resolve-a-thread) in the planning issue.
## Tracking sprint progress
To visualize and manage the work during a sprint, teams can create a dedicated issue board representing
the current sprint's scope.
This board provides transparency into the team's progress and any potential blockers.
Teams can also use iteration analytics for additional visibility through burndown charts.
### Create a board for your current sprint
In your group, create a new issue board titled **Current Sprint**:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Issue boards**.
1. In the upper-left corner, select the dropdown list with the current board name.
1. Select **Create new board**.
1. Enter the new board's title: `Current Sprint`.
1. Next to **Scope**, select **Expand**.
1. Next to **Iteration**, select **Edit**.
1. Below your iteration cadence, select **Current**.
1. Select **Create board**.
The board is now filtered only to show issues assigned to the current iteration.
Use it to visualize the team's progress in the active sprint.
Next, create label lists for all the statuses:
1. In the upper-right corner of the issue board page, select **Create list**.
1. In the column that appears, under **Scope**, select **Label**.
1. From the **Value** dropdown list, select one of the labels:
- `status::refine`: The issue needs further refinement before being developed.
- `status::ready`: The issue is ready for development.
- `status::in progress`: The issue is in development.
- `status::review`: The issue's corresponding MRs are going through code review.
- `status::acceptance`: The issue is ready for stakeholder acceptance and QA testing.
- `status::done`: The issue's acceptance criteria have been satisfied.
1. Select **Add to board**.
1. Repeat the previous steps for the other labels.
Then, as the sprint progresses, drag issues to different lists to change their `status::` label.
### View burndown and burnup charts for your sprint
It can be helpful to review the iteration report during the sprint.
Iteration reports provide progress metrics and burndown and burnup charts.
To view your iteration report:
1. On the left sidebar, select **Search or go to** and find your group.
1. Select **Plan > Iterations** and select an iteration cadence.
1. Select an iteration.

2
doc/user/application_security/sast/analyzers.md
View File

@ -44,7 +44,7 @@ SAST supports the following official analyzers:
<html>
<small>Footnotes:
<ol>
<li>These analyzers were [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/431123) in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
<li>These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated</a> in GitLab 16.9 and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
</ol>
</small>
</html>

8
doc/user/application_security/sast/index.md
View File

@ -86,9 +86,7 @@ For more information about our plans for language support in SAST, see the [cate
<li>The SpotBugs-based analyzer supports <a href="https://gradle.org/">Gradle</a>, <a href="https://maven.apache.org/">Maven</a>, and <a href="https://www.scala-sbt.org/">SBT</a>. It can also be used with variants like the <a href="https://docs.gradle.org/current/userguide/gradle_wrapper.html">Gradle wrapper</a>, <a href="https://grails.org/">Grails</a>, and the <a href="https://github.com/takari/maven-wrapper">Maven wrapper</a>. However, SpotBugs has <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/350801">limitations</a> when used against <a href="https://ant.apache.org/">Ant</a>-based projects. You should use the Semgrep-based analyzer for Ant-based Java or Scala projects.</li>
</ol>
<ol>
<li>
These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
</li>
<li> These analyzers were <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/431123">deprecated in GitLab 16.9</a> and are planned for removal in 17.0. The <a href="https://gitlab.com/gitlab-org/security-products/analyzers/semgrep">Semgrep analyzer</a> is proposed as their replacement.</li>
</ol>
</html>
@ -98,8 +96,8 @@ GitLab has reached [End of Support](https://about.gitlab.com/handbook/product/gi
| Language / framework | [Analyzer](analyzers.md) used for scanning | Minimum supported GitLab version | End Of Support GitLab version |
|------------------------------|--------------------------------------------------------------------------------------------------------------| --------------------------------- | ------------------------------------------------------------- |
| .NET Core | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 11.0 | [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/390416) |
| .NET Framework | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 13.0 | [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/390416) |
| .NET Core | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 11.0 | [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/390416) |
| .NET Framework | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 13.0 | [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/390416) |
| Go | [Gosec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) | 10.7 | [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/352554) |
| Java | [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) with the find-sec-bugs plugin | 10.6 (Maven), 10.8 (Gradle) & 11.9 (SBT) | [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/352554) |
| Python | [bandit](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) | 10.3 | [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/352554) |

3
doc/user/project/repository/code_suggestions/index.md
View File

@ -10,6 +10,9 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, self-managed, GitLab Dedicated. GitLab Duo Pro required.
NOTE:
GitLab Duo Code Suggestions requires [GitLab 16.8](https://about.gitlab.com/releases/2024/01/18/gitlab-16-8-released/) and newer. Earlier GitLab versions not supported.
> - [Introduced support for Google Vertex AI Codey APIs](https://gitlab.com/groups/gitlab-org/-/epics/10562) in GitLab 16.1.
> - [Removed support for GitLab native model](https://gitlab.com/groups/gitlab-org/-/epics/10752) in GitLab 16.2.
> - [Introduced support for Code Generation](https://gitlab.com/gitlab-org/gitlab/-/issues/415583) in GitLab 16.3.

12
lib/gitlab/ci/jwt_v2.rb
View File

@ -9,27 +9,27 @@ module Gitlab
GITLAB_HOSTED_RUNNER = 'gitlab-hosted'
SELF_HOSTED_RUNNER = 'self-hosted'
def self.for_build(build, aud: DEFAULT_AUD, wlif: nil)
new(build, ttl: build.metadata_timeout, aud: aud, wlif: wlif).encoded
def self.for_build(build, aud: DEFAULT_AUD, target_audience: nil)
new(build, ttl: build.metadata_timeout, aud: aud, target_audience: target_audience).encoded
end
def initialize(build, ttl:, aud:, wlif:)
def initialize(build, ttl:, aud:, target_audience:)
super(build, ttl: ttl)
@aud = aud
@wlif = wlif
@target_audience = target_audience
end
private
attr_reader :aud, :wlif
attr_reader :aud, :target_audience
def reserved_claims
super.merge({
iss: Gitlab.config.gitlab.url,
sub: "project_path:#{project.full_path}:ref_type:#{ref_type}:ref:#{source_ref}",
aud: aud,
wlif: wlif
target_audience: target_audience
}.compact)
end

16
spec/lib/gitlab/ci/jwt_v2_spec.rb
View File

@ -15,7 +15,7 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
let(:pipeline) { build_stubbed(:ci_pipeline, ref: 'auto-deploy-2020-03-19') }
let(:runner) { build_stubbed(:ci_runner) }
let(:aud) { described_class::DEFAULT_AUD }
let(:wlif) { nil }
let(:target_audience) { nil }
let(:build) do
build_stubbed(
@ -27,7 +27,7 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
)
end
subject(:ci_job_jwt_v2) { described_class.new(build, ttl: 30, aud: aud, wlif: wlif) }
subject(:ci_job_jwt_v2) { described_class.new(build, ttl: 30, aud: aud, target_audience: target_audience) }
it { is_expected.to be_a Gitlab::Ci::Jwt }
@ -61,16 +61,16 @@ RSpec.describe Gitlab::Ci::JwtV2, feature_category: :secrets_management do
expect(payload[:aud]).to eq('AWS')
end
it 'does not use wlif claim in the payload' do
expect(payload.include?(:wlif)).to be_falsey
it 'does not use target_audience claim in the payload' do
expect(payload.include?(:target_audience)).to be_falsey
end
end
context 'when given an wlif claim' do
let(:wlif) { '//iam.googleapis.com/foo' }
context 'when given an target_audience claim' do
let(:target_audience) { '//iam.googleapis.com/foo' }
it 'uses specified wlif in the payload' do
expect(payload[:wlif]).to eq(wlif)
it 'uses specified target_audience in the payload' do
expect(payload[:target_audience]).to eq(target_audience)
end
end