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-06-17 09:22:06 +00:00
parent 46cc0b7948
commit e3e9a778f9
87 changed files with 543 additions and 312 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
3bbb3fdc9a3c5294e2bf2b3f5a06b7aa059ca2d5
c3e5dc8bf1d451e09e0e207358bd5df346ccf6df

2
GITLAB_KAS_VERSION
View File

@ -1 +1 @@
8197a694087583b69b30c12f22eac6a9ed2b20eb
v17.1.0-rc11

13
app/assets/javascripts/ci/catalog/components/shared/ci_verification_badge.vue
View File

@ -2,10 +2,14 @@
import { GlIcon, GlLink, GlPopover, GlSprintf } from '@gitlab/ui';
import { s__ } from '~/locale';
import { helpPagePath } from '~/helpers/help_page_helper';
import { VERIFICATION_LEVELS } from '../../constants';
import {
VERIFICATION_LEVELS,
VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED,
} from '../../constants';
export default {
i18n: {
verifiedCreatorPopoverLink: s__('CiCatalog|What are verified component creators?'),
verificationLevelPopoverLink: s__('CiCatalog|Learn more about designated creators'),
},
verificationHelpPagePath: helpPagePath('ci/components/index', {
@ -34,6 +38,11 @@ export default {
},
},
computed: {
popoverLink() {
return this.verificationLevel === VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED
? this.$options.i18n.verifiedCreatorPopoverLink
: this.$options.i18n.verificationLevelPopoverLink;
},
popoverTarget() {
return `${this.resourceId}-verification-icon`;
},
@ -68,7 +77,7 @@ export default {
</gl-sprintf>
</span>
<gl-link :href="$options.verificationHelpPagePath" target="_blank">
{{ $options.i18n.verificationLevelPopoverLink }}
{{ popoverLink }}
</gl-link>
</div>
</gl-popover>

13
app/assets/javascripts/ci/catalog/constants.js
View File

@ -28,7 +28,15 @@ export const VERIFICATION_LEVEL_GITLAB_PARTNER_MAINTAINED_ICON = 'partner-verifi
export const VERIFICATION_LEVEL_GITLAB_PARTNER_MAINTAINED_POPOVER_TEXT = s__(
'CiCatalog|Created and maintained by a %{boldStart}GitLab Partner%{boldEnd}',
);
export const VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_BADGE_TEXT = s__(
'CiCatalog|Verified creator',
);
export const VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_ICON = 'check';
export const VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_POPOVER_TEXT = s__(
'CiCatalog|Created and maintained by a %{boldStart}verified creator%{boldEnd}',
);
export const VERIFICATION_LEVEL_UNVERIFIED = 'UNVERIFIED';
export const VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED = 'VERIFIED_CREATOR_MAINTAINED';
export const VERIFICATION_LEVELS = {
GITLAB_MAINTAINED: {
@ -41,4 +49,9 @@ export const VERIFICATION_LEVELS = {
icon: VERIFICATION_LEVEL_GITLAB_PARTNER_MAINTAINED_ICON,
popoverText: VERIFICATION_LEVEL_GITLAB_PARTNER_MAINTAINED_POPOVER_TEXT,
},
VERIFIED_CREATOR_MAINTAINED: {
badgeText: VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_BADGE_TEXT,
icon: VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_ICON,
popoverText: VERIFICATION_LEVEL_VERIFIED_CREATOR_MAINTAINED_POPOVER_TEXT,
},
};

12
db/docs/batched_background_migrations/resync_basic_epic_fields_to_work_item.yml Normal file
View File

@ -0,0 +1,12 @@
---
migration_job_name: ResyncBasicEpicFieldsToWorkItem
description: We backfilled all epics to the issues table to create an epic work item in 17.0.
This unblocked all migrations that depended on having a work item for every epic. At this time
the epic to work item sync was not enabled so epic work items got out of sync after updates.
By 17.1 we enabled syncing epics to work items by default and with this migration we re-sync
all epic work items to be in a synced state by 17.2.
feature_category: team_planning
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/153736
milestone: '17.1'
queued_migration_version: 20240528112758
finalize_after: '2024-06-21'

36
db/post_migrate/20240528112758_queue_resync_basic_epic_fields_to_work_item.rb Normal file
View File

@ -0,0 +1,36 @@
# frozen_string_literal: true
class QueueResyncBasicEpicFieldsToWorkItem < Gitlab::Database::Migration[2.2]
milestone '17.1'
restrict_gitlab_migration gitlab_schema: :gitlab_main
disable_ddl_transaction!
MIGRATION = "ResyncBasicEpicFieldsToWorkItem"
DELAY_INTERVAL = 2.minutes
BATCH_SIZE = 10_000
SUB_BATCH_SIZE = 50
# not passing any group id, means we'd backfill everything. We still have the option to pass in a group id if we
# need to reschedule the backfilling for a single group
GROUP_ID = nil
def up
queue_batched_background_migration(
MIGRATION,
:epics,
batching_column,
GROUP_ID,
job_interval: DELAY_INTERVAL,
batch_size: BATCH_SIZE,
sub_batch_size: SUB_BATCH_SIZE
)
end
def down
delete_batched_background_migration(MIGRATION, :epics, batching_column, [GROUP_ID])
end
def batching_column
GROUP_ID.present? ? :iid : :id
end
end

1
db/schema_migrations/20240528112758 Normal file
View File

@ -0,0 +1 @@
146e57586d358c69e882ef639469730f2035538ee01425ba8932046cee0e2986

4
doc/.vale/gitlab/RelativeLinksDoubleSlashes.yml
View File

@ -5,9 +5,9 @@
#
# For a list of all options, see https://vale.sh/docs/topics/styles/
extends: existence
message: "Remove the double slash from this relative link."
message: "Do not use double slashes '//' or '../doc' in the link path"
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
level: error
scope: raw
raw:
- '\.//'
- '(\.//)|(\.\.\/doc\/)'

2
doc/administration/auth/ldap/ldap_synchronization.md
View File

@ -19,7 +19,7 @@ You can change when synchronization occurs.
## User sync
> - Preventing LDAP user's profile name synchronization [introduced](<https://gitlab.com/gitlab-org/gitlab/-/issues/11336>) in GitLab 15.11.
> - Preventing LDAP user's profile name synchronization [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/11336) in GitLab 15.11.
Once per day, GitLab runs a worker to check and update GitLab
users against LDAP.

2
doc/api/api_resources.md
View File

@ -108,7 +108,7 @@ The following API resources are available in the project context:
| [Search](search.md) | `/projects/:id/search` (also available for groups and standalone) |
| [Tags](tags.md) | `/projects/:id/repository/tags` |
| [Terraform modules](packages/terraform-modules.md) | `/projects/:id/packages/terraform/modules` (also available standalone) |
| [User-starred metrics dashboards](metrics_user_starred_dashboards.md ) | `/projects/:id/metrics/user_starred_dashboards` |
| [User-starred metrics dashboards](metrics_user_starred_dashboards.md) | `/projects/:id/metrics/user_starred_dashboards` |
| [Vulnerabilities](vulnerabilities.md) | `/vulnerabilities/:id` |
| [Vulnerability exports](vulnerability_exports.md) | `/projects/:id/vulnerability_exports` |
| [Vulnerability findings](vulnerability_findings.md) | `/projects/:id/vulnerability_findings` |

2
doc/api/commits.md
View File

@ -896,7 +896,7 @@ Example response:
## Get signature of a commit
Get the [signature from a commit](../user/project/repository/signed_commits),
Get the [signature from a commit](../user/project/repository/signed_commits/index.md),
if it is signed. For unsigned commits, it results in a 404 response.
```plaintext

2
doc/architecture/blueprints/cells/infrastructure/diff-between-dedicated.md
View File

@ -360,7 +360,7 @@ Deployments of anything to these clusters are managed through at least three rep
VMs:
Managed by Ansible: A mixture of [SSH](<https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html>] (internal link) with the use of [Identify-Aware Proxy](https://cloud.google.com/compute/docs/connect/ssh-using-iap).
Managed by Ansible: A mixture of [SSH](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/runbooks/tenant-ssh.html) (internal link) with the use of [Identify-Aware Proxy](https://cloud.google.com/compute/docs/connect/ssh-using-iap).
This must be used with the [Break glass procedure](https://gitlab-com.gitlab.io/gl-infra/gitlab-dedicated/team/engineering/breaking_glass.html) (internal link).
Kubernetes:

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

@ -151,7 +151,7 @@ The interaction between the registry and its clients, including GitLab Rails and
### Database
Following the GitLab [Go standards and style guidelines](../../../development/go_guide), no ORM is used to manage the database, only the [`database/sql`](https://pkg.go.dev/database/sql) package from the Go standard library, a PostgreSQL driver ([`lib/pq`](https://pkg.go.dev/github.com/lib/pq?tab=doc)) and raw SQL queries, over a TCP connection pool.
Following the GitLab [Go standards and style guidelines](../../../development/go_guide/index.md), no ORM is used to manage the database, only the [`database/sql`](https://pkg.go.dev/database/sql) package from the Go standard library, a PostgreSQL driver ([`lib/pq`](https://pkg.go.dev/github.com/lib/pq?tab=doc)) and raw SQL queries, over a TCP connection pool.
The design and development of the registry database adhere to the GitLab [database guidelines](../../../development/database/index.md). Being a Go application, the required tooling to support the database will have to be developed, such as for running database migrations.

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

@ -94,7 +94,7 @@ the work of this optimization. More context surrounds it but, in summary, there
[server](https://github.com/grpc/grpc-go/blob/master/internal/transport/http2_server.go)). So, even if we can overpass the protobuf problem with a
[custom codec](https://github.com/grpc/grpc-go/blob/master/Documentation/encoding.md), `grpc-go` is still an unsolved problem.
[Upstream discussion](https://github.com/grpc/grpc-go/issues/1455) (for read path only) about reusing memory is still pending.
[An attempt to add pooled memory]( https://github.com/grpc/grpc-go/commit/642675125e198ce612ea9caff4bf75d3a4a45667) was reverted because it conflicts with typical
[An attempt to add pooled memory](https://github.com/grpc/grpc-go/commit/642675125e198ce612ea9caff4bf75d3a4a45667) was reverted because it conflicts with typical
usage patterns.
We have developed a protocol called Sidechannel, which enables us to communicate raw binary data with clients through an out-of-band channel, bypassing the `grpc-go`

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

@ -96,7 +96,7 @@ Gateways can be used, for example, to implement sink endpoints to intercept
Cloud Events, wrap into an internally used Ruby classes and allow developers /
users to subscribe to them.
We also may be able to implement [cross-Cell](../cells) communication through a
We also may be able to implement [cross-Cell](../cells/index.md) communication through a
generic events bus implemented using Gateways.
There are also ideas around cross-instance communication to improve how GitLab

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

@ -187,7 +187,7 @@ The following high level diagram shows the proposed setup of secrets within Vaul
![Runway Vault Architecture](img/runway_vault_4_.drawio.png)
[Diagram Source](img/runway_vault_4_.drawio)
Diagram Source: `https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/architecture/blueprints/runway/img/runway_vault_4_.drawio`
### Identity Management, Authentication, Authorization across Runway Components

2
doc/development/ai_architecture.md
View File

@ -68,7 +68,7 @@ AIGW -down-> Models : prompts
## SaaS-based AI abstraction layer
GitLab currently operates a cloud-hosted AI architecture. We will allow access to it for licensed self managed instances using the AI-gateway. See [the blueprint](../architecture/blueprints/ai_gateway) for details.
GitLab currently operates a cloud-hosted AI architecture. We will allow access to it for licensed self managed instances using the AI-gateway. See [the blueprint](../architecture/blueprints/ai_gateway/index.md) for details.
There are two primary reasons for this: the best AI models are cloud-based as they often depend on specialized hardware designed for this purpose, and operating self-managed infrastructure capable of AI at-scale and with appropriate performance is a significant undertaking. We are actively [tracking self-managed customers interested in AI](https://gitlab.com/gitlab-org/gitlab/-/issues/409183).

6
doc/development/ai_features/duo_chat.md
View File

@ -214,7 +214,7 @@ project will be created during request.
1. Restart GDK.
1. Ask any question to chat.
1. Observe project in the LangSmith [page](https://smith.langchain.com/) > Projects > \[Project name\]. 'Runs' tab should contain
your last requests.
your last requests.
## Testing GitLab Duo Chat
@ -342,9 +342,9 @@ run the `rspec-ee unit gitlab-duo-chat-qa` on the `master` the branch:
run and then manually kick off this job by selecting the "Play" icon.
When the test runs on `master`, the reporter script posts the generated report as an issue,
saves the evaluations artfacts as a snippet, and updates the tracking issue in
saves the evaluations artifacts as a snippet, and updates the tracking issue in
[`GitLab-org/ai-powered/ai-framework/qa-evaluation#1`](https://gitlab.com/gitlab-org/ai-powered/ai-framework/qa-evaluation/-/issues/1)
in the project [`GitLab-org/ai-powered/ai-framework/qa-evaluation`](<https://gitlab.com/gitlab-org/ai-powered/ai-framework/qa-evaluation>).
in the project [`GitLab-org/ai-powered/ai-framework/qa-evaluation`](https://gitlab.com/gitlab-org/ai-powered/ai-framework/qa-evaluation).
## GraphQL Subscription

2
doc/development/ai_features/glossary.md
View File

@ -26,7 +26,7 @@ to AI that you think could benefit from being in this list, add it!
[MVC](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/134610).
[Design doc for next iteration](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/136127).
- **Cloud Connector**: Cloud Connector is a way to access services common to
multiple GitLab deployments, instances, and cells. We use it as an umbrella term to refer to the
multiple GitLab deployments, instances, and cells. We use it as an umbrella term to refer to the
set of technical solutions and APIs used to make such services available to all GitLab customers.
For more information, see the [Cloud Connector architecture](../cloud_connector/architecture.md).
- **Closed Source Model**: A private model fine-tuned or built from scratch by an organisation. These may be hosted as cloud services, for example ChatGPT.

2
doc/development/application_limits.md
View File

@ -166,7 +166,7 @@ This applies to Rails controllers, Grape endpoints, and any other Rack requests.
The process for adding a new throttle is loosely:
1. Add new fields to the [rate_limits JSONB column](https://gitlab.com/gitlab-org/gitlab/-/blob/63b37287ae028842fcdcf56d311e6bb0c7e09e79/app/models/application_setting.rb#L603)
in the `ApplicationSetting` model.
in the `ApplicationSetting` model.
1. Update the JSON schema validator for the [rate_limits column](https://gitlab.com/gitlab-org/gitlab/-/blob/63b37287ae028842fcdcf56d311e6bb0c7e09e79/app/validators/json_schemas/application_setting_rate_limits.json).
1. Extend `Gitlab::RackAttack` and `Gitlab::RackAttack::Request` to configure the new rate limit,
and apply it to the desired requests.

14
doc/development/cascading_settings.md
View File

@ -53,13 +53,13 @@ Settings are not cascading by default. To define a cascading setting, take the f
migrations to add columns and change existing columns. Use the specifications
below to create migrations as required:
1. Columns in `namespace_settings` table:
- `delayed_project_removal`: No default value. Null values allowed. Use any column type.
- `lock_delayed_project_removal`: Boolean column. Default value is false. Null values not allowed.
1. Columns in `application_settings` table:
- `delayed_project_removal`: Type matching for the column created in `namespace_settings`.
Set default value as desired. Null values not allowed.
- `lock_delayed_project_removal`: Boolean column. Default value is false. Null values not allowed.
1. Columns in `namespace_settings` table:
- `delayed_project_removal`: No default value. Null values allowed. Use any column type.
- `lock_delayed_project_removal`: Boolean column. Default value is false. Null values not allowed.
1. Columns in `application_settings` table:
- `delayed_project_removal`: Type matching for the column created in `namespace_settings`.
Set default value as desired. Null values not allowed.
- `lock_delayed_project_removal`: Boolean column. Default value is false. Null values not allowed.
## Convenience methods

24
doc/development/cloud_connector/index.md
View File

@ -210,21 +210,21 @@ The GitLab.com configuration should be almost the same as the [CustomersDot conf
As an example, the feature is delivered as a stand-alone service called `new_feature`.
1. Call `CloudConnector::AvailableServices.find_by_name(:new_feature).access_token(user_or_namespace)`
and include this token in the `Authorization` HTTP header field.
and include this token in the `Authorization` HTTP header field.
- On GitLab.com, it will self-issue a token with scopes that depend on the provided resource:
- For a user: scopes will be based on the user's seat assignment
- For a namespace: scopes will be based on purchased add-ons for this namespace
- If a service can be accessed for free, the token will include all available scopes for that service.
- For Duo Chat, the **JWT** would include the `documentation_search` and `duo_chat` scopes.
- On self-managed, it will always return `::CloudConnector::ServiceAccessToken` **JWT** token.
- Provided parameters such as user, namespace or extra claims would be ignored for Self managed instances.
Refer to [this section](#the-new-feature-is-introduced-through-the-existing-backend-service) to see how custom claims are handled for self-managed instances.
- On GitLab.com, it will self-issue a token with scopes that depend on the provided resource:
- For a user: scopes will be based on the user's seat assignment
- For a namespace: scopes will be based on purchased add-ons for this namespace
- If a service can be accessed for free, the token will include all available scopes for that service.
- For Duo Chat, the **JWT** would include the `documentation_search` and `duo_chat` scopes.
- On self-managed, it will always return `::CloudConnector::ServiceAccessToken` **JWT** token.
- Provided parameters such as user, namespace or extra claims would be ignored for Self managed instances.
Refer to [this section](#the-new-feature-is-introduced-through-the-existing-backend-service) to see how custom claims are handled for self-managed instances.
The **backend service** (i.e. Ai Gateway) must validate this token and any scopes it carries when receiving the request.
The **backend service** (i.e. Ai Gateway) must validate this token and any scopes it carries when receiving the request.
1. If you need to embed additional claims in the token specific to your use case, you can pass these
in the `extra_claims` argument.
in the `extra_claims` argument.
1. Ensure your request sends the required headers to the [backend service](#implement-authorization-checks-in-backend-service).
@ -244,7 +244,7 @@ and include this token in the `Authorization` HTTP header field.
To decide if the service is available or visible to the end user, we need to:
- Optional. On self-managed GitLab, if the new feature is introduced as a new [enterprise feature](../ee_features.md#implement-a-new-ee-feature),
check to determine if user has access to the feature by following the [EE feature guildeline](../ee_features.md#guard-your-ee-feature).
check to determine if user has access to the feature by following the [EE feature guildeline](../ee_features.md#guard-your-ee-feature).
```ruby
next true if ::Gitlab::Saas.feature_available?(:new_feature_on_saas)

2
doc/development/contributing/first_contribution/contribute-gdk.md
View File

@ -42,7 +42,7 @@ Use your local IDE to make changes to the code in the GDK directory.
```
1. Refresh the web browser where you're viewing the GDK.
The changes should be displayed. Take a screenshot.
The changes should be displayed. Take a screenshot.
![UI text - Color Theme](../img/ui_color_theme_after.png)

2
doc/development/contributing/first_contribution/contribute-web-ide.md
View File

@ -14,7 +14,7 @@ to GitLab code using the Web IDE.
1. Go to the [GitLab community fork](https://gitlab.com/gitlab-community/gitlab).
1. Search the GitLab code for the string `Customize the color of GitLab`.
From the [GitLab Community Fork](https://gitlab.com/gitlab-community/gitlab):
From the [GitLab Community Fork](https://gitlab.com/gitlab-community/gitlab):
1. On the left sidebar, select **Search or go to**.
1. Enter the search string `"Customize the color of GitLab"`.

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

@ -74,8 +74,8 @@ To write and test your code, you will use the GitLab Development Kit.
- To run a pre-configured GDK instance in the cloud, use [GDK with Gitpod](../../integration/gitpod.md).
From a project repository:
1. On the left sidebar, select **Search or go to** and find your project.
1. In the upper right, select **Edit > Gitpod**.
1. On the left sidebar, select **Search or go to** and find your project.
1. In the upper right, select **Edit > Gitpod**.
1. If you want to contribute to the [website](https://about.gitlab.com/) or the [handbook](https://handbook.gitlab.com/handbook/),
go to the footer of any page and select **Edit in Web IDE** to open the [Web IDE](../../user/project/web_ide/index.md).

4
doc/development/database/migrations_for_multiple_databases.md
View File

@ -80,9 +80,9 @@ end
introduced_by_url: Merge request link
milestone: Milestone example
feature_categories:
- Feature category example
- Feature category example
classes:
- Class example
- Class example
gitlab_schema: gitlab_main
```

4
doc/development/documentation/experiment_beta.md
View File

@ -28,7 +28,7 @@ For example:
DETAILS:
**Status:** Experiment
> - [Introduced](link) in GitLab 15.10. This feature is an [experiment](<link_to>/policy/experiment-beta-support.md).
> - [Introduced](https://issue-link) in GitLab 15.10. This feature is an [experiment](<link_to>/policy/experiment-beta-support.md).
FLAG:
On self-managed GitLab, by default this feature is not available.
@ -39,7 +39,7 @@ Use this new feature when you need to do this new thing.
This feature is an [experiment](<link_to>/policy/experiment-beta-support.md). To join
the list of users testing this feature, do this thing. If you find a bug,
[open an issue](link).
[open an issue](https://link).
```
When the feature is ready for production, remove:

56
doc/development/documentation/feature_flags.md
View File

@ -49,18 +49,18 @@ When the state of a flag changes (for example, from disabled by default to enabl
Possible history entries are:
```markdown
> - [Introduced](issue-link) in GitLab X.X [with a flag](../../administration/feature_flags.md) named `flag_name`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab X.X.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab X.X.
> - [Enabled on GitLab.com, self-managed, and GitLab Dedicated](issue-link) in GitLab X.X.
> - [Generally available](issue-link) in GitLab X.Y. Feature flag `flag_name` removed.
> - [Introduced](https://issue-link) in GitLab X.X [with a flag](../../administration/feature_flags.md) named `flag_name`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab X.X.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab X.X.
> - [Enabled on GitLab.com, self-managed, and GitLab Dedicated](https://issue-link) in GitLab X.X.
> - [Generally available](https://issue-link) in GitLab X.Y. Feature flag `flag_name` removed.
```
These entries might not fit every scenario. You can adjust to suit your needs.
For example, a flag might be enabled for a group, project, or subset of users only.
In that case, you can use a history entry like:
`> - [Enabled on GitLab.com](issue-link) in GitLab X.X for a subset of users.`
`> - [Enabled on GitLab.com](https://issue-link) in GitLab X.X for a subset of users.`
## Add a flag note
@ -87,7 +87,7 @@ This feature is available for testing, but not ready for production use.
The following examples show the progression of a feature flag. Update the history with every change:
```markdown
> - [Introduced](issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Introduced](https://issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
FLAG:
The availability of this feature is controlled by a feature flag. For more information, see the history.
@ -96,8 +96,8 @@ The availability of this feature is controlled by a feature flag. For more infor
When the feature is enabled by default on GitLab.com:
```markdown
> - [Introduced](issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab 13.8.
> - [Introduced](https://issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab 13.8.
FLAG:
The availability of this feature is controlled by a feature flag. For more information, see the history.
@ -106,9 +106,9 @@ The availability of this feature is controlled by a feature flag. For more infor
When the feature is enabled by default for all offerings:
```markdown
> - [Introduced](issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab 13.8.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab 13.9.
> - [Introduced](https://issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab 13.8.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab 13.9.
FLAG:
The availability of this feature is controlled by a feature flag. For more information, see the history.
@ -117,10 +117,10 @@ The availability of this feature is controlled by a feature flag. For more infor
When the flag is removed, add a `Generally available` entry. Ensure that you delete the `FLAG` note as well:
```markdown
> - [Introduced](issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab 13.8.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab 13.9.
> - [Generally available](issue-link) in GitLab 14.0. Feature flag `forti_token_cloud` removed.
> - [Introduced](https://issue-link) in GitLab 13.7 [with a flag](../../administration/feature_flags.md) named `forti_token_cloud`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab 13.8.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab 13.9.
> - [Generally available](https://issue-link) in GitLab 14.0. Feature flag `forti_token_cloud` removed.
```
## Simplify long history
@ -132,16 +132,16 @@ Combine entries if they happened in the same release:
- Before:
```markdown
> - [Introduced](issue-link) in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab 14.3.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab 14.3.
> - [Introduced](https://issue-link) in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab 14.3.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab 14.3.
```
- After:
```markdown
> - [Introduced](issue-link) in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
> - [Enabled on GitLab.com, self-managed, and GitLab Dedicated](issue-link) in GitLab 14.3.
> - [Introduced](https://issue-link) in GitLab 14.2 [with a flag](../../administration/feature_flags.md) named `ci_include_rules`. Disabled by default.
> - [Enabled on GitLab.com, self-managed, and GitLab Dedicated](https://issue-link) in GitLab 14.3.
```
Delete `Enabled on GitLab.com` entries only when the feature is enabled by default for all offerings and the flag is removed:
@ -149,16 +149,16 @@ Delete `Enabled on GitLab.com` entries only when the feature is enabled by defau
- Before:
```markdown
> - [Introduced](issue-link) in GitLab 15.6 [with a flag](../../administration/feature_flags.md) named `ci_hooks_pre_get_sources_script`. Disabled by default.
> - [Enabled on GitLab.com](issue-link) in GitLab 15.7.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab 15.8.
> - [Generally available](issue-link) in GitLab 15.9. Feature flag `ci_hooks_pre_get_sources_script` removed.
> - [Introduced](https://issue-link) in GitLab 15.6 [with a flag](../../administration/feature_flags.md) named `ci_hooks_pre_get_sources_script`. Disabled by default.
> - [Enabled on GitLab.com](https://issue-link) in GitLab 15.7.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab 15.8.
> - [Generally available](https://issue-link) in GitLab 15.9. Feature flag `ci_hooks_pre_get_sources_script` removed.
```
- After:
```markdown
> - [Introduced](issue-link) in GitLab 15.6 [with a flag](../../administration/feature_flags.md) named `ci_hooks_pre_get_sources_script`. Disabled by default.
> - [Enabled on self-managed and GitLab Dedicated](issue-link) in GitLab 15.8.
> - [Generally available](issue-link) in GitLab 15.9. Feature flag `ci_hooks_pre_get_sources_script` removed.
> - [Introduced](https://issue-link) in GitLab 15.6 [with a flag](../../administration/feature_flags.md) named `ci_hooks_pre_get_sources_script`. Disabled by default.
> - [Enabled on self-managed and GitLab Dedicated](https://issue-link) in GitLab 15.8.
> - [Generally available](https://issue-link) in GitLab 15.9. Feature flag `ci_hooks_pre_get_sources_script` removed.
```

6
doc/development/documentation/restful_api_styleguide.md
View File

@ -106,7 +106,7 @@ for the section. For example:
```markdown
### Edit a widget
> - `widget_message` [introduced](<link-to-issue>) in GitLab 14.3.
> - `widget_message` [introduced](https://link-to-issue) in GitLab 14.3.
```
If the API or attribute is deployed behind a feature flag,
@ -122,7 +122,7 @@ To deprecate an attribute:
1. Add a history note.
```markdown
> - `widget_name` [deprecated](<link-to-issue>) in GitLab 14.7.
> - `widget_name` [deprecated](https://link-to-issue) in GitLab 14.7.
```
1. Add inline deprecation text to the description.
@ -130,7 +130,7 @@ To deprecate an attribute:
```markdown
| Attribute | Type | Required | Description |
|---------------|--------|----------|-------------|
| `widget_name` | string | No | [Deprecated](<link-to-issue>) in GitLab 14.7 and is planned for removal in 15.4. Use `widget_id` instead. The name of the widget. |
| `widget_name` | string | No | [Deprecated](https://link-to-issue) in GitLab 14.7 and is planned for removal in 15.4. Use `widget_id` instead. The name of the widget. |
```
To widely announce a deprecation, or if it's a breaking change,

4
doc/development/documentation/site_architecture/folder_structure.md
View File

@ -62,8 +62,8 @@ When working with directories and files:
Every page you would navigate under `/profile` should have its own document,
for example, `account.md`, `applications.md`, or `emails.md`.
1. In the `doc/administration/` directory: all administrator-related
documentation for administrators, including admin tasks done in both
the UI and on the backend servers.
documentation for administrators, including admin tasks done in both
the UI and on the backend servers.
If you're unsure where to place a document or a content addition, this shouldn't
stop you from authoring and contributing. Use your best judgment, and then ask

2
doc/development/documentation/styleguide/availability_details.md
View File

@ -21,7 +21,7 @@ DETAILS:
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
**Status:** Experiment
> - [Introduced](<link-to-issue>) in GitLab 16.3.
> - [Introduced](https://link-to-issue) in GitLab 16.3.
> - Updated in GitLab 16.4.
```

28
doc/development/documentation/styleguide/index.md
View File

@ -857,13 +857,13 @@ Follow these guidelines for link text.
As much as possible, use text that follows one of these patterns:
- `For more information, see [LINK TEXT](LINK)`.
- `To [DO THIS THING], see [LINK TEXT](LINK)`
- `For more information, see [link text](link.md)`.
- `To [DO THIS THING], see [link text](link.md)`
For example:
- `For more information, see [merge requests](LINK).`
- `To create a review app, see [review apps](LINK).`
- `For more information, see [merge requests](link.md).`
- `To create a review app, see [review apps](link.md).`
You can expand on this text by using phrases like
`For more information about this feature, see...`
@ -872,8 +872,8 @@ Do not use the following constructions:
- `Learn more about...`
- `To read more...`.
- `For more information, see the [Merge requests](LINK) page.`
- `For more information, see the [Merge requests](LINK) documentation.`
- `For more information, see the [Merge requests](link.md) page.`
- `For more information, see the [Merge requests](link.md) documentation.`
#### Descriptive text rather than `here`
@ -881,18 +881,18 @@ Use descriptive text for links, rather than words like `here` or `this page.`
For example, instead of:
- `For more information, see [this page](LINK).`
- `For more information, go [here](LINK).`
- `For more information, see [this page](link.md).`
- `For more information, go [here](link.md).`
Use:
- `For more information, see [merge requests](LINK)`.
- `For more information, see [merge requests](link.md)`.
#### Links to issues
When linking to an issue, include the issue number in the link. For example:
- `For more information, see [issue 12345](LINK).`
- `For more information, see [issue 12345](link.md).`
Do not use the pound sign (`issue #12345`).
@ -1420,7 +1420,7 @@ videos that might be out-of-date.
```markdown
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview, see [Video Title](link-to-video).
For an overview, see [Video Title](https://link-to-video).
<!-- Video published on YYYY-MM-DD -->
```
@ -1489,7 +1489,7 @@ With this formatting:
Linking to click-through demos should follow similar guidelines to [videos](#videos).
```markdown
For a click-through demo, see [Demo Title](link-to-demo).
For a click-through demo, see [Demo Title](https://link-to-demo).
<!-- Demo published on YYYY-MM-DD -->
```
@ -2003,8 +2003,8 @@ DETAILS:
**Tier:** Premium, Ultimate
**Offering:** Self-managed
- Information specific to Geo.
- ...
- Information specific to Geo.
- ...
## X.Y.0

2
doc/development/documentation/styleguide/word_list.md
View File

@ -12,7 +12,7 @@ recommends these word choices. In addition:
- The GitLab handbook contains a list of
[top misused terms](https://handbook.gitlab.com/handbook/communication/top-misused-terms/).
- The documentation [style guide](../styleguide#language) includes details
- The documentation [style guide](../styleguide/index.md#language) includes details
about language and capitalization.
- The GitLab handbook provides guidance on the [use of third-party trademarks](https://handbook.gitlab.com/handbook/legal/policies/product-third-party-trademarks-guidelines/#process-for-adding-third-party-trademarks-to-gitlab).

8
doc/development/documentation/topic_types/get_started.md
View File

@ -53,8 +53,8 @@ Finally, add links, in this format:
For more information, see:
- [Create your first abc](LINK).
- [Learn more about abc](LINK).
- [Create your first abc](link.md).
- [Learn more about abc](link.md).
## Step 2: The next thing
@ -62,8 +62,8 @@ Don't link in the body content. Save links for the `for more information` area.
For more information, see:
- [Create your first abc](LINK).
- [Learn more about abc](LINK).
- [Create your first abc](link.md).
- [Learn more about abc](link.md).
```
## Get started page titles

4
doc/development/documentation/topic_types/index.md
View File

@ -64,6 +64,6 @@ full sentences, and so should not end in a period.
```markdown
## Related topics
- [CI/CD variables](link-to-topic)
- [Environment variables](link-to-topic)
- [CI/CD variables](link-to-topic.md)
- [Environment variables](link-to-topic.md)
```

2
doc/development/documentation/topic_types/task.md
View File

@ -138,7 +138,7 @@ When this situation occurs:
- If someone feels strongly that you mention the API, at the end
of the UI task, add this sentence:
`To create an issue, you can also [use the API](link).`
`To create an issue, you can also [use the API](link.md).`
## Task introductions

50
doc/development/documentation/versions.md
View File

@ -37,7 +37,7 @@ For example:
```markdown
## Feature name
> - [Introduced](<link-to-issue>) in GitLab 11.3.
> - [Introduced](https://issue-link) in GitLab 11.3.
This feature does something.
```
@ -67,15 +67,15 @@ Start the sentence with the feature name or a gerund.
For example, on the issue boards page:
```markdown
> - [Introduced](<link-to-issue>) in GitLab 13.1.
> - Creating an issue from an issue board [introduced](<link-to-issue>) in GitLab 14.1.
> - [Introduced](https://issue-link) in GitLab 13.1.
> - Creating an issue from an issue board [introduced](https://issue-link) in GitLab 14.1.
```
Or on email notifications page:
```markdown
> - [Introduced](<link-to-issue>) in GitLab 13.1.
> - Notifications for expiring tokens [introduced](<link-to-issue>) in GitLab 14.3.
> - [Introduced](https://issue-link) in GitLab 13.1.
> - Notifications for expiring tokens [introduced](https://issue-link) in GitLab 14.3.
```
#### Making features available as part of a program
@ -83,8 +83,8 @@ Or on email notifications page:
When a feature is made available to users as a part of a program, add a new list item.
```markdown
> - [Introduced](<link-to-issue>) in GitLab 15.1.
> - Merged results pipelines [added](<link-to-issue>) to the [Registration Features Program](<link-to-page>) in GitLab 16.7.
> - [Introduced](https://issue-link) in GitLab 15.1.
> - Merged results pipelines [added](https://issue-link) to the [Registration Features Program](https://page-link) in GitLab 16.7.
```
#### Moving subscription tiers
@ -92,8 +92,8 @@ When a feature is made available to users as a part of a program, add a new list
If a feature is moved to another subscription tier, use `moved`:
```markdown
> - [Moved](<link-to-issue>) from GitLab Ultimate to GitLab Premium in 11.8.
> - [Moved](<link-to-issue>) from GitLab Premium to GitLab Free in 12.0.
> - [Moved](https://issue-link) from GitLab Ultimate to GitLab Premium in 11.8.
> - [Moved](https://issue-link) from GitLab Premium to GitLab Free in 12.0.
```
#### Changing the feature status
@ -101,14 +101,14 @@ If a feature is moved to another subscription tier, use `moved`:
If the feature status changes to experiment or beta, use `changed`:
```markdown
> - [Introduced](<link-to-issue>) as an [experiment](../../policy/experiment-beta-support.md) in GitLab 15.7.
> - [Changed](<link-to-issue>) to beta in GitLab 16.0.
> - [Introduced](https://issue-link) as an [experiment](../../policy/experiment-beta-support.md) in GitLab 15.7.
> - [Changed](https://issue-link) to beta in GitLab 16.0.
```
For a change to generally available, use:
```markdown
> - [Generally available](issue-link) in GitLab 16.10.
> - [Generally available](https://issue-link) in GitLab 16.10.
```
#### Features introduced behind feature flags
@ -123,7 +123,7 @@ inline with the existing text. If possible, include a link to the related issue,
merge request, or epic. For example:
```markdown
The voting strategy [in GitLab 13.4 and later](<link-to-issue>) requires the primary and secondary
The voting strategy [in GitLab 13.4 and later](https://issue-link) requires the primary and secondary
voters to agree.
```
@ -150,8 +150,8 @@ To deprecate a page or topic:
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
WARNING:
This feature was [deprecated](<link-to-issue>) in GitLab 14.8
and is planned for removal in 15.4. Use [feature X](<link-to-docs>) instead.
This feature was [deprecated](https://issue-link) in GitLab 14.8
and is planned for removal in 15.4. Use [feature X](link-to-docs.md) instead.
```
If you're not sure when the feature will be removed or no
@ -178,8 +178,8 @@ To deprecate a page or topic:
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
WARNING:
This feature was [deprecated](<link-to-issue>) in GitLab 14.8
and is planned for removal in 15.4. Use [feature X](<link-to-docs>) instead.
This feature was [deprecated](https://issue-link) in GitLab 14.8
and is planned for removal in 15.4. Use [feature X](link-to-docs.md) instead.
<!--- end_remove -->
```
@ -216,9 +216,9 @@ To remove a page:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
This feature was [deprecated](<link-to-issue>) in GitLab X.Y
and [removed](<link-to-issue>) in X.Y.
Use [feature X](<link-to-docs>) instead.
This feature was [deprecated](https://issue-link) in GitLab X.Y
and [removed](https://issue-link) in X.Y.
Use [feature X](link-to-docs.md) instead.
```
1. Remove the page's entry from the global navigation by editing [`navigation.yaml`](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/content/_data/navigation.yaml) in `gitlab-docs`.
@ -245,9 +245,9 @@ To remove a topic:
**Tier:** Premium, Ultimate
**Offering:** GitLab.com, Self-managed, GitLab Dedicated
This feature was [deprecated](<link-to-issue>) in GitLab X.Y
and [removed](<link-to-issue>) in X.Y.
Use [feature X](<link-to-docs>) instead.
This feature was [deprecated](https://issue-link) in GitLab X.Y
and [removed](https://issue-link) in X.Y.
Use [feature X](link-to-docs.md) instead.
<!--- end_remove -->
```
@ -316,8 +316,8 @@ We cannot guarantee future feature work, and promises
like these can raise legal issues. Instead, say that an issue exists.
For example:
- Support for improvements is proposed in `[issue <issue_number>](LINK-TO-ISSUE)`.
- You cannot do this thing, but `[issue 12345](LINK-TO-ISSUE)` proposes to change this behavior.
- Support for improvements is proposed in `[issue <issue_number>](https://link-to-issue)`.
- You cannot do this thing, but `[issue 12345](https://link-to-issue)` proposes to change this behavior.
You can say that we plan to remove a feature.

2
doc/development/documentation/workflow.md
View File

@ -53,7 +53,7 @@ and link to it from the merged merge request that introduced the documentation c
Circumstances in which a regular pre-merge Technical Writer review might be skipped include:
- There is a short amount of time left before the milestone release. If fewer than three
days are remaining, seek a post-merge review and ping the writer via Slack to ensure the review is
days are remaining, seek a post-merge review and ping the writer via Slack to ensure the review is
completed as soon as possible.
- The size of the change is small and you have a high degree of confidence
that early users of the feature (for example, GitLab.com users) can easily

2
doc/development/experiment_guide/experiment_rollout.md
View File

@ -23,7 +23,7 @@ In either case, an outcome of the experiment should be posted to the issue with
When there is a case on GitLab.com (SaaS) that necessitates turning off all experiments, we have this control.
You can toggle experiments on SaaS on and off using the `gitlab_experiment` [feature flag](../feature_flags).
You can toggle experiments on SaaS on and off using the `gitlab_experiment` [feature flag](../feature_flags/index.md).
This can be done via ChatOps:

23
doc/development/fe_guide/customizable_dashboards.md
View File

@ -312,3 +312,26 @@ export default {
</customizable-dashboard>
</template>
```
## Introducing visualizations behind a feature flag
While developing new visualizations we can use [feature flags](../feature_flags/index.md#create-a-new-feature-flag) to mitigate risks of disruptions or incorrect data for users.
The [`from_data`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/product_analytics/panel.rb#L7) method builds the panel objects for a dashboard. Using the `filter_map` method, we can add a condition to skip rendering panels that include the visualization we are developing.
For example, here we have added the `enable_usage_overview_visualization` feature flag and can check it's current state to determine whether panels using the `usage_overview` visualization should be rendered:
```ruby
panel_yaml.filter_map do |panel|
# Skip processing the usage_overview panel if the feature flag is disabled
next if panel['visualization'] == 'usage_overview' && Feature.disabled?(:enable_usage_overview_visualization)
new(
title: panel['title'],
project: project,
grid_attributes: panel['gridAttributes'],
query_overrides: panel['queryOverrides'],
visualization: panel['visualization']
)
end
```

12
doc/development/fe_guide/diagrams_net_integration.md
View File

@ -46,16 +46,16 @@ The `event` property tells the GitLab application how it should
react to the message. The diagrams.net editor sends the following events:
- `configure`: When the GitLab application receives this message, it sends back
a `configure` action to set the color theme of the diagrams.net editor.
a `configure` action to set the color theme of the diagrams.net editor.
- `init`: When the GitLab application receives this message,
it can upload an existing diagram using the `load` action.
it can upload an existing diagram using the `load` action.
- `exit`: The GitLab application closes and disposes the
diagrams.net editor.
diagrams.net editor.
- `prompt`: This event has a `value` attribute with the
diagram's filename. If the `value` property is an empty value,
the GitLab application should send a `prompt`requesting the user to introduce a filename.
diagram's filename. If the `value` property is an empty value,
the GitLab application should send a `prompt`requesting the user to introduce a filename.
- `export`: This event has a `data` attribute that contains
the diagram created by the user in the SVG format.
the diagram created by the user in the SVG format.
## Markdown Editor integration

2
doc/development/fe_guide/graphql.md
View File

@ -80,7 +80,7 @@ the GraphQL extension, follow these steps:
Our GraphQL API can be explored via GraphiQL at your instance's
`/-/graphql-explorer` or at [GitLab.com](https://gitlab.com/-/graphql-explorer). Consult the
[GitLab GraphQL API Reference documentation](../../api/graphql/reference)
[GitLab GraphQL API Reference documentation](../../api/graphql/reference/index.md)
where needed.
To check all existing queries and mutations, on the right side of GraphiQL, select **Documentation explorer**.

10
doc/development/fe_guide/merge_request_widget_extensions.md
View File

@ -332,7 +332,7 @@ To generate these known events for a single widget:
1. `product_group` = `code_review`
1. `introduced_by_url` = `'[your MR]'`
1. `options.events` = (the event in the command from above that generated this file, like `i_code_review_merge_request_widget_test_reports_count_view`)
- This value is how the telemetry events are linked to "metrics" so this is probably one of the more important values.
- This value is how the telemetry events are linked to "metrics" so this is probably one of the more important values.
1. `data_source` = `redis`
1. `data_category` = `optional`
1. Generate known HLL events on the command line with the following command.
@ -353,10 +353,10 @@ To generate these known events for a single widget:
1. Add each event (those listed in the command in step 7, replacing `test_reports`
with the appropriate name slug) to the aggregate files:
1. `config/metrics/counts_7d/{timestamp}_code_review_category_monthly_active_users.yml`
1. `config/metrics/counts_7d/{timestamp}_code_review_group_monthly_active_users.yml`
1. `config/metrics/counts_28d/{timestamp}_code_review_category_monthly_active_users.yml`
1. `config/metrics/counts_28d/{timestamp}_code_review_group_monthly_active_users.yml`
1. `config/metrics/counts_7d/{timestamp}_code_review_category_monthly_active_users.yml`
1. `config/metrics/counts_7d/{timestamp}_code_review_group_monthly_active_users.yml`
1. `config/metrics/counts_28d/{timestamp}_code_review_category_monthly_active_users.yml`
1. `config/metrics/counts_28d/{timestamp}_code_review_group_monthly_active_users.yml`
### Add new events

8
doc/development/fe_guide/vuex.md
View File

@ -152,10 +152,10 @@ Instead of creating an mutation to toggle the loading state, we should:
1. A mutation with type `RECEIVE_SOMETHING_SUCCESS`, to handle the success callback
1. A mutation with type `RECEIVE_SOMETHING_ERROR`, to handle the error callback
1. An action `fetchSomething` to make the request and commit mutations on mentioned cases
1. In case your application does more than a `GET` request you can use these as examples:
- `POST`: `createSomething`
- `PUT`: `updateSomething`
- `DELETE`: `deleteSomething`
1. In case your application does more than a `GET` request you can use these as examples:
- `POST`: `createSomething`
- `PUT`: `updateSomething`
- `DELETE`: `deleteSomething`
As a result, we can dispatch the `fetchNamespace` action from the component and it is responsible to commit `REQUEST_NAMESPACE`, `RECEIVE_NAMESPACE_SUCCESS` and `RECEIVE_NAMESPACE_ERROR` mutations.

46
doc/development/gems.md
View File

@ -273,34 +273,34 @@ The project for a new Gem should always be created in [`gitlab-org/ruby/gems` na
1. Visit `https://rubygems.org/gems/<gem-name>` and verify that the gem was published
successfully and `gitlab_rubygems` is also an owner.
1. Create a project in the [`gitlab-org/ruby/gems` group](https://gitlab.com/gitlab-org/ruby/gems/) (or in a subgroup of it):
1. Follow the [instructions for new projects](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project).
1. Follow the instructions for setting up a [CI/CD configuration](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration).
1. Use the [`gem-release` CI component](https://gitlab.com/gitlab-org/components/gem-release)
to release and publish new gem versions by adding the following to their `.gitlab-ci.yml`:
1. Follow the [instructions for new projects](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project).
1. Follow the instructions for setting up a [CI/CD configuration](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#cicd-configuration).
1. Use the [`gem-release` CI component](https://gitlab.com/gitlab-org/components/gem-release)
to release and publish new gem versions by adding the following to their `.gitlab-ci.yml`:
```yaml
include:
- component: $CI_SERVER_FQDN/gitlab-org/components/gem-release/gem-release@~latest
```
```yaml
include:
- component: $CI_SERVER_FQDN/gitlab-org/components/gem-release/gem-release@~latest
```
This job will handle building and publishing the gem (it uses a `gitlab_rubygems` Rubygems.org
API token inherited from the `gitlab-org/ruby/gems` group, in order to publish the gem
package), as well as creating the tag, release and populating its release notes by
using the
[Generate changelog data](../api/repositories.md#generate-changelog-data)
API endpoint.
This job will handle building and publishing the gem (it uses a `gitlab_rubygems` Rubygems.org
API token inherited from the `gitlab-org/ruby/gems` group, in order to publish the gem
package), as well as creating the tag, release and populating its release notes by
using the
[Generate changelog data](../api/repositories.md#generate-changelog-data)
API endpoint.
For instructions for when and how to generate a changelog entry file, see the
dedicated [Changelog entries](changelog.md)
page.
[To be consistent with the GitLab project](changelog.md),
Gem projects could also define a changelog YAML configuration file at
`.gitlab/changelog_config.yml` with the same content
as [in the `gitlab-styles` gem](https://gitlab.com/gitlab-org/ruby/gems/gitlab-styles/-/blob/master/.gitlab/changelog_config.yml).
1. To ease the release process, you could also create a `.gitlab/merge_request_templates/Release.md` MR template with the same content
For instructions for when and how to generate a changelog entry file, see the
dedicated [Changelog entries](changelog.md)
page.
[To be consistent with the GitLab project](changelog.md),
Gem projects could also define a changelog YAML configuration file at
`.gitlab/changelog_config.yml` with the same content
as [in the `gitlab-styles` gem](https://gitlab.com/gitlab-org/ruby/gems/gitlab-styles/-/blob/master/.gitlab/changelog_config.yml).
1. To ease the release process, you could also create a `.gitlab/merge_request_templates/Release.md` MR template with the same content
as [in the `gitlab-styles` gem](https://gitlab.com/gitlab-org/ruby/gems/gitlab-styles/-/raw/master/.gitlab/merge_request_templates/Release.md)
(make sure to replace `gitlab-styles` with the actual gem name).
1. Follow the instructions for [publishing a project](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#publishing-a-project).
1. Follow the instructions for [publishing a project](https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#publishing-a-project).
Notes: In some cases we may want to move a gem to its own namespace. Some
examples might be that it will naturally have more than one project

8
doc/development/gitlab_flavored_markdown/specification_guide/index.md
View File

@ -517,9 +517,9 @@ specification and testing infrastructure:
1. There is an official specification and single source of truth for how GLFM should render Markdown to HTML.
This source of truth is represented by three Markdown files:
1. [`ghfm_spec_v_?.??.md`](#github-flavored-markdown-specification) for the CommonMark + GFM examples.
1. [`glfm_official_specification.md`](#glfm_official_specificationmd) for the GLFM official examples.
1. [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd) for the GLFM internal extensions.
1. [`ghfm_spec_v_?.??.md`](#github-flavored-markdown-specification) for the CommonMark + GFM examples.
1. [`glfm_official_specification.md`](#glfm_official_specificationmd) for the GLFM official examples.
1. [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd) for the GLFM internal extensions.
1. This official specification meets these requirements:
1. The specification is a strict superset of the GitHub Flavored Markdown
(GFM) specification, just as
@ -1404,7 +1404,7 @@ This section describes how the scripts can be used to manage the GLFM specificat
1. If you are working on an in-progress feature or bug, make any necessary manual updates to the [input specification files](#input-specification-files). This may include:
1. Updating the canonical Markdown or HTML examples in
[`glfm_official_specification.md`](#glfm_official_specificationmd) or [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd).
[`glfm_official_specification.md`](#glfm_official_specificationmd) or [`glfm_internal_extensions.md`](#glfm_internal_extensionsmd).
1. Updating `glfm_specification/input/gitlab_flavored_markdown/glfm_example_status.yml` to reflect the current status of the examples or tests.
1. Run [`update-specification.rb`](#update-specificationrb-script) to update the `spec.txt` to reflect any changes which were made to the [input specification files](#input-specification-files).
1. Visually inspect and confirm any resulting changes to the [output specification files](#output-specification-files).

2
doc/development/image_scaling.md
View File

@ -31,7 +31,7 @@ The hard-coded rules only permit:
Furthermore, configuration in Workhorse can lead to the image scaler rejecting a request if:
- The image file is too large (controlled by [`max_filesize`](- we only rescale images that do not exceed a configured size in bytes (see [`max_filesize`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/workhorse/config.toml.example#L22)))).
- The image file is too large (controlled by `max_filesize`, we only rescale images that do not exceed a configured size in bytes, see [`max_filesize`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/workhorse/config.toml.example#L22)).
- Too many image scalers are already running (controlled by [`max_scaler_procs`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/workhorse/config.toml.example#L21)).
For instance, here are two different URLs that serve the GitLab project avatar both in its

22
doc/development/integrations/secure_partner_integration.md
View File

@ -55,16 +55,16 @@ best place to integrate your own product and its results into GitLab.
vulnerabilities that need to be addressed in the code.
- When the developer reads the details about a vulnerability, they are
presented with additional information and choices on next steps:
1. Create Issue (Confirm finding): Creates a new issue to be prioritized.
1. Add Comment and Dismiss Vulnerability: When dismissing a finding, users
can comment to note items that they
have mitigated, that they accept the vulnerability, or that the
vulnerability is a false positive.
1. Auto-Remediation / Create Merge Request: A fix for the vulnerability can
be offered, allowing an easy solution that does not require extra effort
from users. This should be offered whenever possible.
1. Links: Vulnerabilities can link out external sites or sources for users
to get more data around the vulnerability.
1. Create Issue (Confirm finding): Creates a new issue to be prioritized.
1. Add Comment and Dismiss Vulnerability: When dismissing a finding, users
can comment to note items that they
have mitigated, that they accept the vulnerability, or that the
vulnerability is a false positive.
1. Auto-Remediation / Create Merge Request: A fix for the vulnerability can
be offered, allowing an easy solution that does not require extra effort
from users. This should be offered whenever possible.
1. Links: Vulnerabilities can link out external sites or sources for users
to get more data around the vulnerability.
## How to onboard
@ -77,7 +77,7 @@ and complete an integration with the Secure stage.
1. Get a test account to begin developing your integration. You can
request a [GitLab.com Subscription Sandbox](https://about.gitlab.com/partners/technology-partners/integrate/#gitlabcom-subscription-sandbox-request)
or an [EE Developer License](https://about.gitlab.com/partners/technology-partners/integrate/#requesting-ultimate-dev-license-for-rd).
1. Provide a [pipeline job](../../development/pipelines)
1. Provide a [pipeline job](../../development/pipelines/index.md)
template that users could integrate into their own GitLab pipelines.
1. Create a report artifact with your pipeline jobs.
1. Ensure your pipeline jobs create a report artifact that GitLab can process

8
doc/development/internal_analytics/metrics/metrics_lifecycle.md
View File

@ -37,14 +37,14 @@ Currently, the [Metrics Dictionary](https://metrics.gitlab.com/) is built automa
- **If the metric has at least one `performance_indicator_type` of the `[x]mau` kind**:
Notify the Customer Success Ops team (`@csops-team`), Analytics Engineers (`@gitlab-data/analytics-engineers`), and Product Analysts (`@gitlab-data/product-analysts`) by `@` mentioning the groups in a comment in the issue. Unexpected changes to these metric could break reporting.
- **If the metric is owned by a different group than the one doing the removal**:
Tag the PM and EM of the owning group according to the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
Tag the PM and EM of the owning group according to the [stages file](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml).
1. Remove the metric instrumentation code, depending on `data_source`:
- **`database/system`**: If the metric has an `instrumentation_class` and the assigned class is no longer used by any other metric you can remove the class and specs.
If the metric is instrumented within [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb)
or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb) then remove the associated code and specs
([example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167)).
If the metric is instrumented within [`lib/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data.rb)
or [`ee/lib/ee/gitlab/usage_data.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/usage_data.rb) then remove the associated code and specs
([example](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60149/diffs#6335dc533bd21df26db9de90a02dd66278c2390d_167_167)).
- **`redis_hll/redis/internal_events`**: Remove the tracking code e.g. `track_internal_event` and associated specs.
1. Update the attributes of the metric's YAML definition:

2
doc/development/logging.md
View File

@ -189,7 +189,7 @@ logger.info(a_list: ["foo", 1, true])
Resources:
- [Elasticsearch mapping - avoiding type gotchas](https://www.elastic.co/guide/en/elasticsearch/guide/current/mapping.html#_avoiding_type_gotchas)
- [Elasticsearch mapping types]( https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html)
- [Elasticsearch mapping types](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html)
#### Include a class attribute

32
doc/development/pages/index.md
View File

@ -158,26 +158,26 @@ GitLab Pages access control is disabled by default. To enable it:
- With GDK, in `gdk.yml`:
```yaml
gitlab_pages:
enabled: true
access_control: true
auth_client_id: $CLIENT_ID # the OAuth application id created in http://gdk.test:3000/admin/applications
auth_client_secret: $CLIENT_SECRET # the OAuth application secret created in http://gdk.test:3000/admin/applications
```
```yaml
gitlab_pages:
enabled: true
access_control: true
auth_client_id: $CLIENT_ID # the OAuth application id created in http://gdk.test:3000/admin/applications
auth_client_secret: $CLIENT_SECRET # the OAuth application secret created in http://gdk.test:3000/admin/applications
```
GDK generates random `auth_secret` and builds the `auth_redirect_uri` based on GitLab Pages
host configuration.
GDK generates random `auth_secret` and builds the `auth_redirect_uri` based on GitLab Pages
host configuration.
- Without GDK, in `gitlab-pages.conf`:
```conf
## the following are only needed if you want to test auth for private projects
auth-client-id=$CLIENT_ID # the OAuth application id created in http://gdk.test:3000/admin/applications
auth-client-secret=$CLIENT_SECRET # the OAuth application secret created in http://gdk.test:3000/admin/applications
auth-secret=$SOME_RANDOM_STRING # should be at least 32 bytes long
auth-redirect-uri=http://pages.gdk.test:3010/auth # the authentication callback url for GitLab Pages
```
```conf
## the following are only needed if you want to test auth for private projects
auth-client-id=$CLIENT_ID # the OAuth application id created in http://gdk.test:3000/admin/applications
auth-client-secret=$CLIENT_SECRET # the OAuth application secret created in http://gdk.test:3000/admin/applications
auth-secret=$SOME_RANDOM_STRING # should be at least 32 bytes long
auth-redirect-uri=http://pages.gdk.test:3010/auth # the authentication callback url for GitLab Pages
```
1. If running Pages inside the GDK, you can use GDK `protected_config_files` section under `gdk` in
your `gdk.yml` to avoid getting `gitlab-pages.conf` configuration rewritten:

4
doc/development/reference_processing.md
View File

@ -76,8 +76,8 @@ a minimum implementation of `AbstractReferenceFilter` should define:
- `#record_identifier(record)`: the inverse of `.parse_symbol`, that is, transform a domain object to an identifier (`#id` by default).
- `#url_for_object(object, parent_object)`: generate the URL for a domain object.
- `#find_object(parent_object, id)`: given the parent (usually a [`Project`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/project.rb))
and an identifier, find the object. For example, this in a reference filter for
merge requests, this might be `project.merge_requests.where(iid: iid)`.
and an identifier, find the object. For example, this in a reference filter for
merge requests, this might be `project.merge_requests.where(iid: iid)`.
### Add a new reference prefix and filter

2
doc/development/sec/analyzer_development_guide.md
View File

@ -39,7 +39,7 @@ Analyzers are shipped as Docker images. For example, to run the
registry.gitlab.com/gitlab-org/security-products/analyzers/semgrep:latest /analyzer run
```
1. The Docker container generates a report in the mounted project directory with a report filename corresponding to the analyzer category. For example, [SAST](../../user/application_security/sast) generates a file named `gl-sast-report.json`.
1. The Docker container generates a report in the mounted project directory with a report filename corresponding to the analyzer category. For example, [SAST](../../user/application_security/sast/index.md) generates a file named `gl-sast-report.json`.
## Analyzers development

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

@ -9,7 +9,7 @@ info: Any user with at least the Maintainer role can merge updates to this conte
The Sec section is responsible for GitLab application security features, the "Sec" part of
DevSecOps. Development guides that are specific to the Sec section are listed here.
See [Terminology](../../user/application_security/terminology) for an overview of our shared terminology.
See [Terminology](../../user/application_security/terminology/index.md) for an overview of our shared terminology.
## Architecture
@ -78,7 +78,7 @@ If you are working with CI/CD templates, read the [development guide for GitLab
Within analyzer JSON reports, the [`identifiers` field](../integrations/secure.md#identifiers) contains a collection of types and categories by which
a vulnerability can be described (that is, a CWE family).
The first item in the `identifiers` collection is known as the [primary identifier](../../user/application_security/terminology#primary-identifier),
The first item in the `identifiers` collection is known as the [primary identifier](../../user/application_security/terminology/index.md#primary-identifier),
a critical component to both describing and tracking vulnerabilities.
In most other cases, the `identifiers` collection is unordered, where the remaining secondary identifiers act as metadata for grouping vulnerabilities

4
doc/development/sec/security_report_ingestion_overview.md
View File

@ -60,7 +60,7 @@ An instance of the `Vulnerabilities::Remediation` class. A remediation is repres
Assumptions:
- Project uses GitLab CI
- Project uses [security scanning tools](../../user/application_security)
- Project uses [security scanning tools](../../user/application_security/index.md)
- No Vulnerabilities are present in the database
- All pipelines perform security scans
@ -120,5 +120,5 @@ This style of creation was intended to be fast and seamless, but has proven diff
The "No longer detected" badge on the vulnerability report is displayed if the `Vulnerability` record has `resolved_on_default_branch: true`.
This is set by `Security::Ingestion::MarkAsResolvedService` when a pipeline runs on the default branch. Vulnerabilities which have
`resolved_on_default_branch: false` and _are not_ present in the pipeline scan results are marked as resolved.
[Secret Detection](../../user/application_security/secret_detection) and [manual](../../user/application_security/vulnerability_report#manually-add-a-vulnerability)
[Secret Detection](../../user/application_security/secret_detection/index.md) and [manual](../../user/application_security/vulnerability_report/index.md#manually-add-a-vulnerability)
vulnerabilities are excluded from this process.

4
doc/development/secure_coding_guidelines.md
View File

@ -59,7 +59,7 @@ MR. Also add the Guideline to the "SAST Coverage" table above.
### Creating new RuboCop rule
1. Follow the [RuboCop development doc](rubocop_development_guide.md#creating-new-rubocop-cops).
For an example, see [this merge request](https://gitlab.com/gitlab-org/gitlab-qa/-/merge_requests/1280) on adding a rule to the `gitlab-qa` project.
For an example, see [this merge request](https://gitlab.com/gitlab-org/gitlab-qa/-/merge_requests/1280) on adding a rule to the `gitlab-qa` project.
1. The cop itself should reside in the `gitlab-security` [gem project](https://gitlab.com/gitlab-org/ruby/gems/gitlab-styles/-/tree/master/lib/rubocop/cop/gitlab_security)
## Permissions
@ -1361,7 +1361,7 @@ This sensitive data must be handled carefully to avoid leaks which could lead to
- The [Gitleaks Git hook](https://gitlab.com/gitlab-com/gl-security/security-research/gitleaks-endpoint-installer) is recommended for preventing credentials from being committed.
- Never log credentials under any circumstance. Issue [#353857](https://gitlab.com/gitlab-org/gitlab/-/issues/353857) is an example of credential leaks through log file.
- When credentials are required in a CI/CD job, use [masked variables](../ci/variables/index.md#mask-a-cicd-variable) to help prevent accidental exposure in the job logs. Be aware that when [debug logging](../ci/variables/index.md#enable-debug-logging) is enabled, all masked CI/CD variables are visible in job logs. Also consider using [protected variables](../ci/variables/index.md#protect-a-cicd-variable) when possible so that sensitive CI/CD variables are only available to pipelines running on protected branches or protected tags.
- Proper scanners must be enabled depending on what data those credentials are protecting. See the [Application Security Inventory Policy](hhttps://handbook.gitlab.com/handbook/security/product-security/application-security/inventory/#policies) and our [Data Classification Standards](https://handbook.gitlab.com/handbook/security/data-classification-standard/#standard).
- Proper scanners must be enabled depending on what data those credentials are protecting. See the [Application Security Inventory Policy](https://handbook.gitlab.com/handbook/security/product-security/application-security/inventory/#policies) and our [Data Classification Standards](https://handbook.gitlab.com/handbook/security/data-classification-standard/#standard).
- To store and/or share credentials between teams, refer to [1Password for Teams](https://handbook.gitlab.com/handbook/security/password-guidelines/#1password-for-teams) and follow [the 1Password Guidelines](https://handbook.gitlab.com/handbook/security/password-guidelines/#1password-guidelines).
- If you need to share a secret with a team member, use 1Password. Do not share a secret over email, Slack, or other service on the Internet.

8
doc/development/sidekiq/index.md
View File

@ -18,10 +18,10 @@ There are pages with additional detail on the following topics:
1. [Limited capacity worker: continuously performing work with a specified concurrency](limited_capacity_worker.md)
1. [Logging](logging.md)
1. [Worker attributes](worker_attributes.md)
1. **Job urgency** specifies queuing and execution SLOs
1. **Resource boundaries** and **external dependencies** for describing the workload
1. **Feature categorization**
1. **Database load balancing**
1. **Job urgency** specifies queuing and execution SLOs
1. **Resource boundaries** and **external dependencies** for describing the workload
1. **Feature categorization**
1. **Database load balancing**
## ApplicationWorker

12
doc/development/software_design.md
View File

@ -182,21 +182,21 @@ In exceptional cases, we may need to add a new bounded context to the list. This
1. **Is there ever a situation where the cop should be disabled?**
- The cop **should not** be disabled but it **could** be disabled temporarily if the offending class or module is part
of a cluster of classes that should otherwise be moved all together.
In this case you could disable the cop and create a follow-up issue to move all the classes at once.
of a cluster of classes that should otherwise be moved all together.
In this case you could disable the cop and create a follow-up issue to move all the classes at once.
1. **Is there a suggested timeline to get all of the existing code refactored into compliance?**
- We do not have a timeline defined but the quicker we consolidate code the more consistent it becomes.
1. **Do the bounded contexts apply for existing Sidekiq workers?**
- Existing workers would be already in the RuboCop TODO file so they do not raise offenses. However, they should
also be moved into the bounded context whenever possible.
Follow the Sidekiq [renaming worker](../development/sidekiq/compatibility_across_updates.md#renaming-worker-classes) guide.
also be moved into the bounded context whenever possible.
Follow the Sidekiq [renaming worker](../development/sidekiq/compatibility_across_updates.md#renaming-worker-classes) guide.
1. **We are renaming a feature category and the `config/bounded_contexts.yml` references that. Is it safe to update?**
- Yes the file only expects that the feature categories mapped to bounded contexts are defined in `config/feature_categories.yml`
and nothing specifically depends on these values. This mapping is primarily for contributors to understand where features
may be living in the codebase.
and nothing specifically depends on these values. This mapping is primarily for contributors to understand where features
may be living in the codebase.
## Distinguish domain code from generic code

60
doc/development/spam_protection_and_captcha/exploratory_testing.md
View File

@ -26,33 +26,33 @@ Enable any relevant feature flag, if the spam/CAPTCHA support is behind a featur
## Set up Akismet and reCAPTCHA
1. To set up reCAPTCHA:
1. Review the [GitLab reCAPTCHA documentation](../../integration/recaptcha.md).
1. Get Google's official test reCAPTCHA credentials using the instructions from
[Google's reCAPTCHA documentation](https://developers.google.com/recaptcha/docs/faq#id-like-to-run-automated-tests-with-recaptcha.-what-should-i-do).
1. For **Site key**, use: `6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI`
1. For **Secret key**, use: `6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe`
1. Go to **Admin -> Settings -> Reporting** settings: `http://gdk.test:3000/admin/application_settings/reporting#js-spam-settings`
1. Expand the **Spam and Anti-bot Protection** section.
1. Select **Enable reCAPTCHA**. Enabling for login is not required unless you are testing that feature.
1. Enter the **Site key** and **Secret key**.
1. Review the [GitLab reCAPTCHA documentation](../../integration/recaptcha.md).
1. Get Google's official test reCAPTCHA credentials using the instructions from
[Google's reCAPTCHA documentation](https://developers.google.com/recaptcha/docs/faq#id-like-to-run-automated-tests-with-recaptcha.-what-should-i-do).
1. For **Site key**, use: `6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI`
1. For **Secret key**, use: `6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe`
1. Go to **Admin -> Settings -> Reporting** settings: `http://gdk.test:3000/admin/application_settings/reporting#js-spam-settings`
1. Expand the **Spam and Anti-bot Protection** section.
1. Select **Enable reCAPTCHA**. Enabling for login is not required unless you are testing that feature.
1. Enter the **Site key** and **Secret key**.
1. To set up Akismet:
1. Review the [GitLab documentation on Akismet](../../integration/akismet.md).
1. Get an Akismet API key. You can sign up for [a testing key from Akismet](https://akismet.com).
You must enter your local host (such as`gdk.test`) and email when signing up.
1. Go to GitLab Akismet settings page, for example:
`http://gdk.test:3000/admin/application_settings/reporting#js-spam-settings`
1. Enable Akismet and enter your Akismet **API key**.
1. Review the [GitLab documentation on Akismet](../../integration/akismet.md).
1. Get an Akismet API key. You can sign up for [a testing key from Akismet](https://akismet.com).
You must enter your local host (such as`gdk.test`) and email when signing up.
1. Go to GitLab Akismet settings page, for example:
`http://gdk.test:3000/admin/application_settings/reporting#js-spam-settings`
1. Enable Akismet and enter your Akismet **API key**.
1. To force an Akismet false-positive spam check, refer to the
[Akismet API documentation](https://akismet.com/developers/detailed-docs/comment-check/) and
[Akismet Getting Started documentation](https://akismet.com/support/getting-started/confirm/) for more details:
1. You can use `akismet-guaranteed-spam@example.com` as the author email to force spam using the following steps:
1. Go to user email settings: `http://gdk.test:3000/-/profile/emails`
1. Add `akismet-guaranteed-spam@example.com` as a secondary email for the administrator user.
1. Confirm it in the Rails console: `bin/rails c` -> `User.find_by_username('root').emails.last.confirm`
1. Switch this verified email to be your primary email:
1. Go to **Avatar dropdown list -> Edit Profile -> Main Settings**.
1. For **Email**, enter `akismet-guaranteed-spam@example.com` to replace `admin@example.com`.
1. Select **Update Profile Settings** to save your changes.
1. You can use `akismet-guaranteed-spam@example.com` as the author email to force spam using the following steps:
1. Go to user email settings: `http://gdk.test:3000/-/profile/emails`
1. Add `akismet-guaranteed-spam@example.com` as a secondary email for the administrator user.
1. Confirm it in the Rails console: `bin/rails c` -> `User.find_by_username('root').emails.last.confirm`
1. Switch this verified email to be your primary email:
1. Go to **Avatar dropdown list -> Edit Profile -> Main Settings**.
1. For **Email**, enter `akismet-guaranteed-spam@example.com` to replace `admin@example.com`.
1. Select **Update Profile Settings** to save your changes.
## Test in the web UI
@ -165,20 +165,6 @@ In this example, Akismet and CAPTCHA are enabled:
1. [Initial request](#initial-request).
<!-- TODO in future edit
Some example videos:
- REST API:
![CAPTCHA REST API](/uploads/b148cbe45496e6f4a4f63d00bb9fbd8a/captcha_rest_api.mov)
GraphQL API:
![CAPTCHA GraphQL API](/uploads/3c7ef0fad0b84bd588572bae51519463/captcha_graphql_api.mov)
-->
#### Initial request
This initial request fails because no CAPTCHA response is provided.

16
doc/development/spam_protection_and_captcha/web_ui.md
View File

@ -15,8 +15,8 @@ Three different scenarios are supported. Two are used with JavaScript XHR/Fetch
for either Apollo or Axios, and one is used only with standard HTML form requests:
1. A JavaScript-based submission (possibly via Vue)
1. Using Apollo (GraphQL API via Fetch/XHR request)
1. Using Axios (REST API via Fetch/XHR request)
1. Using Apollo (GraphQL API via Fetch/XHR request)
1. Using Axios (REST API via Fetch/XHR request)
1. A standard HTML form submission (HTML request)
Some parts of the implementation depend upon which of these scenarios you must support.
@ -82,12 +82,12 @@ changes required to the relevant backend controller actions (typically just `cre
- The `needs_recaptcha` property on the model is set to true.
1. Wrap the existing controller action return value (rendering or redirecting) in a block passed to
a `#with_captcha_check_json_format` helper method, which transparently handles:
1. Check if CAPTCHA is enabled, and if so, proceeding with the next step.
1. Checking if there the model contains an error, and the `needs_recaptcha` flag is true.
- If yes: Add the appropriate spam or CAPTCHA fields to the JSON response, and return
a `409 - Conflict` HTTP status code.
- If no (if CAPTCHA is disabled or if no spam was detected): The standard request return
logic passed in the block is run.
1. Check if CAPTCHA is enabled, and if so, proceeding with the next step.
1. Checking if there the model contains an error, and the `needs_recaptcha` flag is true.
- If yes: Add the appropriate spam or CAPTCHA fields to the JSON response, and return
a `409 - Conflict` HTTP status code.
- If no (if CAPTCHA is disabled or if no spam was detected): The standard request return
logic passed in the block is run.
Thanks to the abstractions, it's more straightforward to implement than it is to explain it.
You don't have to worry much about the hidden details!

8
doc/development/testing_guide/end_to_end/best_practices.md
View File

@ -127,14 +127,14 @@ end
1. Every `describe`, `context`, and `it` blocks should have a short description attached
1. Keep descriptions as concise as possible.
1. Long descriptions or multiple conditionals could be a sign it should be split up (additional `context` blocks).
1. The [Documentation Style Guide](../../documentation/styleguide/index.md) gives recommendations on how to write concisely and with [active voice](../../documentation/styleguide/index.md#active-voice).
1. Long descriptions or multiple conditionals could be a sign it should be split up (additional `context` blocks).
1. The [Documentation Style Guide](../../documentation/styleguide/index.md) gives recommendations on how to write concisely and with [active voice](../../documentation/styleguide/index.md#active-voice).
1. The outermost `Rspec.describe` block should be [the DevOps stage name](https://handbook.gitlab.com/handbook/product/categories/#devops-stages)
1. Inside the `Rspec.describe` block is a `describe` block with the name of the feature being tested
1. Optional `context` blocks define what the conditions being tested are
1. `context` blocks descriptions should begin with `when`, `with`, `without`, `for`, `and`, `on`, `in`, `as`, or `if` to match the [RuboCop rule](https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/ContextWording)
1. `context` blocks descriptions should begin with `when`, `with`, `without`, `for`, `and`, `on`, `in`, `as`, or `if` to match the [RuboCop rule](https://www.rubydoc.info/gems/rubocop-rspec/RuboCop/Cop/RSpec/ContextWording)
1. The `it` block describes the pass/fail criteria for the test
1. In `shared_examples` with a single example a `specify` block can be used instead of a named `it` block
1. In `shared_examples` with a single example a `specify` block can be used instead of a named `it` block
## Prefer API over UI

5
doc/development/testing_guide/end_to_end/test_pipelines.md
View File

@ -194,7 +194,8 @@ This stage is responsible for [allure test report](index.md#allure-report) gener
The `e2e:test-on-cng` child pipeline runs tests against [Cloud Native GitLab](https://gitlab.com/gitlab-org/build/CNG) installation.
Unlike `review-apps`, this pipeline uses local [kind](https://github.com/kubernetes-sigs/kind) Kubernetes cluster.
Deployment is managed by the [`cng`](../../../../gems/gitlab-cng/README.md) orchestrator tool, which you can also use to locally recreate CI/CD deployments.
Deployment is managed by the [`cng`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/gems/gitlab-cng/README.md)
orchestrator tool, which you can also use to locally recreate CI/CD deployments.
This pipeline is executed every two hours on scheduled pipelines and runs the following validations:
@ -206,7 +207,7 @@ This pipeline is executed every two hours on scheduled pipelines and runs the fo
The pipeline setup consists of several jobs in the main GitLab pipeline:
- `compile-production-assets` and `build-assets-image` jobs are responsible for compiling frontend assets which are required
by [CNG](https://gitlab.com/gitlab-org/build/CNG-mirror) build pipeline.
by [CNG](https://gitlab.com/gitlab-org/build/CNG-mirror) build pipeline.
- `e2e-test-pipeline-generate` job is responsible for generating `e2e:test-on-cng` child pipeline
### `e2e:test-on-cng` child pipeline

2
doc/development/testing_guide/testing_levels.md
View File

@ -138,7 +138,7 @@ graph RL
- **Methods of the class under test**:
By mocking methods of the class under test, the mocks are tested and not the real methods.
- **Utility functions (pure functions, or those that only modify parameters)**:
If a function has no side effects because it has no state, it is safe to not mock it in tests.
If a function has no side effects because it has no state, it is safe to not mock it in tests.
- **Full HTML pages**:
Avoid loading the HTML of a full page in unit tests, as it slows down tests.

3
doc/development/work_items.md
View File

@ -231,6 +231,7 @@ Keep the following in mind when you write your migration:
instead of having to wait for the next release.
**Important:** Because we use a regular migration, we need to make sure it does two things:
1. Don't exceed the [time guidelines](migration_style_guide.md#how-long-a-migration-should-take) of regular migrations.
1. Make sure the migration is [backwards-compatible](multi_version_compatibility.md).
This means that deployed code should continue to work even if the MR that introduced this migration is
@ -268,7 +269,7 @@ Keep the following in mind when you write your migration:
- Use shared examples for migrations specs.
There are different shared examples you should use for the different migration types (new work item type, new widget definition, etc) in
[`add_work_item_widget_shared_examples.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/14c0a4df57a562a7c2dd4baed98f26d208a2e6ce/spec/support/shared_examples/migrations/add_work_item_widget_shared_examples.rb).
[`add_work_item_widget_shared_examples.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/14c0a4df57a562a7c2dd4baed98f26d208a2e6ce/spec/support/shared_examples/migrations/add_work_item_widget_shared_examples.rb).
##### Example of adding a ticket work item

6
doc/development/workhorse/index.md
View File

@ -142,9 +142,3 @@ for specific behavior but the high-level integration tests should have
the first priority during development.
It is OK if a feature is only covered by integration tests.
<!--
## License
This code is distributed under the MIT license, see the [LICENSE](LICENSE) file.
-->

2
doc/integration/index.md
View File

@ -24,7 +24,7 @@ You can configure an [external issue tracker](external-issue-tracker.md) and use
You can integrate GitLab with authentication providers like LDAP and SAML.
For more information, see [GitLab authentication and authorization](../administration/auth).
For more information, see [GitLab authentication and authorization](../administration/auth/index.md).
## Security improvements

2
doc/integration/partner_marketplace.md
View File

@ -76,7 +76,7 @@ own resources, instead of accessing resources on behalf of a user.
### Step 1: Request access
Before you can use the Marketplace API, you must contact your Marketplace partner Manager or email [`partnerorderops`](mailto:partnerorderops@gitlab.com)
Before you can use the Marketplace API, you must contact your Marketplace partner Manager or email `partnerorderops@gitlab.com`
to request access. After you request access, GitLab configures the following accounts and credentials for you:
1. Client credentials. Marketplace APIs are secured with OAuth 2.0. The client credentials include the client ID and client secret

2
doc/topics/release_your_application.md
View File

@ -31,7 +31,7 @@ release features incrementally.
deployment using GitLab CI/CD. Auto Deploy has built-in support for EC2 and ECS deployments.
- Deploy to Kubernetes clusters by using the [GitLab agent](../user/clusters/agent/install/index.md).
- Use Docker images to run AWS commands from GitLab CI/CD, and a template to
facilitate [deployment to AWS](../ci/cloud_deployment).
facilitate [deployment to AWS](../ci/cloud_deployment/index.md).
- Use GitLab CI/CD to target any type of infrastructure accessible by GitLab Runner.
[User and pre-defined environment variables](../ci/variables/index.md) and CI/CD templates
support setting up a vast number of deployment strategies.

12
doc/user/application_security/api_security/index.md
View File

@ -16,9 +16,9 @@ However, this also makes them attractive to attackers and vulnerable to security
In this section, we discuss GitLab features that can be used to ensure the security of web APIs in your application.
Some of the features discussed are specific to web APIs and others are more general solutions that are also used with web API applications.
- [SAST](../sast) identified vulnerabilities by analyzing the application's codebase.
- [Dependency Scanning](../dependency_scanning) reviews a project 3rd party dependencies for known vulnerabilities (for example CVEs).
- [Container Scanning](../container_scanning) analyzes container images to identify known OS package vulnerabilities and installed language dependencies.
- [API Discovery](api_discovery) examines an application containing a REST API and intuits an OpenAPI specification for that API. OpenAPI specification documents are used by other GitLab security tools.
- [DAST API](../dast_api) performs dynamic analysis security testing of web APIs. It can identify various security vulnerabilities in your application, including the OWASP Top 10.
- [API Fuzzing](../api_fuzzing) performs fuzz testing of a web API. Fuzz testing looks for issues in an application that are not previously known and don't map to classic vulnerability types such as SQL Injection.
- [SAST](../sast/index.md) identified vulnerabilities by analyzing the application's codebase.
- [Dependency Scanning](../dependency_scanning/index.md) reviews a project 3rd party dependencies for known vulnerabilities (for example CVEs).
- [Container Scanning](../container_scanning/index.md) analyzes container images to identify known OS package vulnerabilities and installed language dependencies.
- [API Discovery](api_discovery/index.md) examines an application containing a REST API and intuits an OpenAPI specification for that API. OpenAPI specification documents are used by other GitLab security tools.
- [DAST API](../dast_api/index.md) performs dynamic analysis security testing of web APIs. It can identify various security vulnerabilities in your application, including the OWASP Top 10.
- [API Fuzzing](../api_fuzzing/index.md) performs fuzz testing of a web API. Fuzz testing looks for issues in an application that are not previously known and don't map to classic vulnerability types such as SQL Injection.

2
doc/user/application_security/api_security_testing/checks/json_injection_check.md
View File

@ -17,4 +17,4 @@ JSON injection is an attack technique used to manipulate or compromise the logic
## Links
- [OWASP](https://owasp.org/Top10/A03_2021-Injection/)
- [CWE](CWE-929: OWASP Top Ten 2013 Category A1 - Injection)
- [CWE](https://cwe.mitre.org/data/definitions/929.html)

2
doc/user/application_security/dast/browser_based_4_to_5_migration_guide.md
View File

@ -74,7 +74,7 @@ Follow the progress of the remaining checks in the epic [Remaining active checks
## Changes to CI/CD variables
The following table outlines migration actions required for each browser-based analyzer DAST version 4 CI/CD variable.
See [configuration](browser/configuration) for more information on configuring the browser-based analyzer.
See [configuration](browser/configuration/index.md) for more information on configuring the browser-based analyzer.
| DAST version 4 CI/CD variable | Required action | Notes |
|:--------------------------------------------|:-------------------|:----------------------------------------------|

2
doc/user/application_security/dast/proxy_based_to_browser_based_migration_guide.md
View File

@ -141,7 +141,7 @@ See the DAST version 5 [troubleshooting](browser/troubleshooting.md) documentati
## Changes to CI/CD variables
The following table outlines migration actions required for each proxy-based analyzer CI/CD variable.
See [configuration](browser/configuration) for more information on configuring DAST version 5.
See [configuration](browser/configuration/index.md) for more information on configuring DAST version 5.
| Proxy-based analyzer CI/CD variable | Required action | Notes |
|:-------------------------------------|:-------------------------|:-----------------------------------------------------------------------------------------|

2
doc/user/application_security/dependency_list/index.md
View File

@ -81,7 +81,7 @@ The dependency list shows only dependencies that match your filters.
If a dependency has known vulnerabilities, view them by selecting the arrow next to the
dependency's name or the badge that indicates how many known vulnerabilities exist. For each
vulnerability, its severity and description appears below it. To view more details of a vulnerability,
select the vulnerability's description. The [vulnerability's details](../vulnerabilities) page is opened.
select the vulnerability's description. The [vulnerability's details](../vulnerabilities/index.md) page is opened.
## Dependency paths

2
doc/user/application_security/vulnerability_report/index.md
View File

@ -167,7 +167,7 @@ Selection behavior when using the activity filter:
## View details of a vulnerability
To view more details of a vulnerability, select the vulnerability's **Description**. The
[vulnerability's details](../vulnerabilities) page is opened.
[vulnerability's details](../vulnerabilities/index.md) page is opened.
## View vulnerable source location

2
doc/user/infrastructure/iac/terraform_template_recipes.md
View File

@ -185,7 +185,7 @@ To define a custom container image:
```
1. In a new job, define a `prepare` stage that builds the image whenever the `Dockerfile` changes.
- The built image is pushed to the [GitLab container registry](../../packages/container_registry). A tag is applied to indicate whether the image was built from a merge request or from the default branch.
- The built image is pushed to the [GitLab container registry](../../packages/container_registry/index.md). A tag is applied to indicate whether the image was built from a merge request or from the default branch.
1. Use your image in your Terraform jobs, such as `build` and `deploy`.
- You can combine your image with specialized `before_script` configurations to perform setup commands, like to generate inputs for Terraform.

2
doc/user/project/merge_requests/approvals/settings.md
View File

@ -146,7 +146,7 @@ Prerequisites:
- Password authentication, see
[sign-in restrictions documentation](../../../../administration/settings/sign_in_restrictions.md#password-authentication-enabled).
- SAML authentication for GitLab.com groups, see
[SAML SSO for GitLab.com groups documentation](../../../../user/group/saml_sso).
[SAML SSO for GitLab.com groups documentation](../../../../user/group/saml_sso/index.md).
- SAML authentication for self-managed instances, see [SAML SSO for self-managed GitLab instances](../../../../integration/saml.md).
1. On the left sidebar, select **Settings > Merge requests**.
1. In the **Merge request approvals** section, scroll to **Approval settings** and

2
doc/user/project/repository/push_rules.md
View File

@ -143,7 +143,7 @@ Some validation examples:
Use these rules to prevent unintended consequences.
- **Reject unsigned commits**: Commit [must be signed](signed_commits). This rule
- **Reject unsigned commits**: Commit [must be signed](signed_commits/index.md). This rule
can block some legitimate commits [created in the Web IDE](#reject-unsigned-commits-push-rule-disables-web-ide),
and allow [unsigned commits created in the GitLab UI](#unsigned-commits-created-in-the-gitlab-ui).
- **Do not allow users to remove Git tags with `git push`**: Users cannot use `git push` to remove Git tags.

2
doc/user/rich_text_editor.md
View File

@ -70,7 +70,7 @@ Supported input rules:
| `**bold**` or `__bold__` | Bold text |
| `_italics_` or `*italics*` | Italicized text |
| `~~strike~~` | Strikethrough |
| `[link](url)` | Hyperlink |
| `[link](https://example.com)` | Hyperlink |
| `code` | Inline code |
| <code>&#96;&#96;&#96;rb</code> + <kbd>Enter</kbd> <br> <code>&#96;&#96;&#96;js</code> + <kbd>Enter</kbd> | Code block |
| `* List item`, or<br> `- List item`, or<br> `+ List item` | Unordered list |

2
lib/gitlab/background_migration/backfill_epic_basic_fields_to_work_item_record.rb
View File

@ -16,7 +16,7 @@ module Gitlab
MATCHING_BASIC_FIELDS = %i[
author_id iid state_id title title_html description description_html cached_markdown_version lock_version
last_edited_at last_edited_by_id created_at updated_at closed_at closed_by_id confidential
external_key
external_key imported_from
].freeze
class Epics < ApplicationRecord

12
lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item.rb Normal file
View File

@ -0,0 +1,12 @@
# frozen_string_literal: true
module Gitlab
module BackgroundMigration
# rubocop: disable Migration/BatchedMigrationBaseClass -- BackfillEpicBasicFieldsToWorkItemRecord inherits from BatchedMigrationJob.
class ResyncBasicEpicFieldsToWorkItem < BackfillEpicBasicFieldsToWorkItemRecord
operation_name :resync_basic_epic_fields_to_work_item
feature_category :team_planning
end
# rubocop: enable Migration/BatchedMigrationBaseClass
end
end

12
locale/gitlab.pot
View File

@ -11139,6 +11139,9 @@ msgstr ""
msgid "CiCatalog|Created and maintained by a %{boldStart}GitLab Partner%{boldEnd}"
msgstr ""
msgid "CiCatalog|Created and maintained by a %{boldStart}verified creator%{boldEnd}"
msgstr ""
msgid "CiCatalog|Discover CI/CD components that can improve your pipeline with additional functionality."
msgstr ""
@ -11232,9 +11235,15 @@ msgstr ""
msgid "CiCatalog|Use the 'release' keyword in a CI/CD job to publish to the CI/CD Catalog."
msgstr ""
msgid "CiCatalog|Verified creator"
msgstr ""
msgid "CiCatalog|We want to help you create and manage pipeline component repositories, while also making it easier to reuse pipeline configurations. Let us know how we're doing!"
msgstr ""
msgid "CiCatalog|What are verified component creators?"
msgstr ""
msgid "CiCatalog|Your groups"
msgstr ""
@ -39871,6 +39880,9 @@ msgstr ""
msgid "ProductAnalytics|Details on how to configure product analytics to collect data."
msgstr ""
msgid "ProductAnalytics|Dimension"
msgstr ""
msgid "ProductAnalytics|Dimensions"
msgstr ""

2
qa/Gemfile
View File

@ -36,7 +36,7 @@ gem 'chemlab', '~> 0.11', '>= 0.11.1'
gem 'chemlab-library-www-gitlab-com', '~> 0.1', '>= 0.1.1'
# dependencies for jenkins client
gem 'nokogiri', '~> 1.16', '>= 1.16.5'
gem 'nokogiri', '~> 1.16', '>= 1.16.6'
gem 'deprecation_toolkit', '~> 2.2.0', require: false

4
qa/Gemfile.lock
View File

@ -229,7 +229,7 @@ GEM
multi_json (1.15.0)
multi_xml (0.6.0)
netrc (0.11.0)
nokogiri (1.16.5)
nokogiri (1.16.6)
mini_portile2 (~> 2.8.2)
racc (~> 1.4)
octokit (9.1.0)
@ -396,7 +396,7 @@ DEPENDENCIES
influxdb-client (~> 3.1)
junit_merge (~> 0.1.2)
knapsack (~> 4.0)
nokogiri (~> 1.16, >= 1.16.5)
nokogiri (~> 1.16, >= 1.16.6)
octokit (~> 9.1.0)
parallel (~> 1.25, >= 1.25.1)
parallel_tests (~> 4.7, >= 4.7.1)

9
qa/qa/specs/features/browser_ui/3_create/source_editor/source_editor_toolbar_spec.rb
View File

@ -11,7 +11,12 @@ module QA
end
it 'can preview markdown side-by-side while editing', :blocking,
testcase: 'https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/367749' do
testcase: 'https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases/367749',
quarantine: {
only: { job: 'gdk' },
type: 'test_environment',
issue: 'https://gitlab.com/gitlab-org/gitlab/-/issues/466663'
} do
project.visit!
Page::Project::Show.perform do |project|
project.click_file('README.md')
@ -21,7 +26,7 @@ module QA
Page::File::Edit.perform do |file|
file.remove_content
file.add_content('# ' + edited_readme_content)
file.add_content("# #{edited_readme_content}")
file.preview
expect(file.has_markdown_preview?('h1', edited_readme_content)).to be true
file.commit_changes

9
spec/frontend/ci/catalog/components/shared/ci_verification_badge_spec.js
View File

@ -64,10 +64,11 @@ describe('Catalog Verification Badge', () => {
});
describe.each`
verificationLevel | describeText
${'GITLAB_MAINTAINED'} | ${'GitLab'}
${'GITLAB_PARTNER_MAINTAINED'} | ${'partner'}
`('when the resource is $describeText maintained', ({ verificationLevel }) => {
verificationLevel | describeText
${'GITLAB_MAINTAINED'} | ${'GitLab'}
${'GITLAB_PARTNER_MAINTAINED'} | ${'a GitLab partner'}
${'VERIFIED_CREATOR_MAINTAINED'} | ${'a verified creator'}
`('when the resource is maintained by $describeText', ({ verificationLevel }) => {
beforeEach(() => {
createComponent({ ...defaultProps, verificationLevel });
});

98
spec/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item_spec.rb Normal file
View File

@ -0,0 +1,98 @@
# frozen_string_literal: true
require 'spec_helper'
RSpec.describe Gitlab::BackgroundMigration::ResyncBasicEpicFieldsToWorkItem, feature_category: :team_planning do
let!(:author) { table(:users).create!(username: 'tester', projects_limit: 100) }
let!(:namespace1) { table(:namespaces).create!(name: 'my test group1', path: 'my-test-group1') }
let!(:namespace2) { table(:namespaces).create!(name: 'my test group2', path: 'my-test-group2') }
let!(:epics) { table(:epics) }
let!(:issues) { table(:issues) }
let!(:wi_colors) { table(:work_item_colors) }
let!(:start_id) { epics.minimum(:id) }
let!(:end_id) { epics.maximum(:id) }
let!(:epic_work_item_type_id) { table(:work_item_types).where(base_type: 7).first.id }
before do
(1..5).each do |idx|
epic_data = epic_data(idx, namespace1)
issue_id = issues.create!(
title: "out of sync #{idx}", iid: idx, namespace_id: namespace1.id, work_item_type_id: epic_work_item_type_id
).id
table(:epics).create!(**epic_data, issue_id: issue_id)
# synced work items have the same color as the epic
color_data = { issue_id: issue_id, namespace_id: namespace1.id, color: epic_data[:color] }
table(:work_item_colors).create!(color_data) if idx % 3 == 0
end
(6..10).each do |idx|
issue_id = issues.create!(
title: "epic #{idx}", iid: idx, namespace_id: namespace2.id, work_item_type_id: epic_work_item_type_id
).id
table(:epics).create!(**epic_data(idx, namespace2), issue_id: issue_id)
# synced work items have a different color from epics
color_data = { issue_id: issue_id, namespace_id: namespace2.id, color: color((idx * 1000) + 1) }
table(:work_item_colors).create!(color_data) if idx % 3 == 0
end
end
context 'when backfilling all epics', :aggregate_failures do
let!(:migration) do
described_class.new(
start_id: start_id,
end_id: end_id,
batch_table: :epics,
batch_column: :id,
job_arguments: [nil],
sub_batch_size: 2,
pause_ms: 2,
connection: ::ApplicationRecord.connection
)
end
it 'backfills the work items for specific group only' do
migration.perform
backfilled_epics = epics.where.not(issue_id: nil)
expect(backfilled_epics.count).to eq(10)
expect(backfilled_epics.map(&:group_id).uniq).to match_array([namespace1.id, namespace2.id])
epic_wis = table(:issues).where(work_item_type_id: epic_work_item_type_id)
epic_wi_colors = wi_colors.where(issue_id: backfilled_epics.pluck(:issue_id))
expect(epic_wis.map(&:namespace_id).uniq).to match_array([namespace1.id, namespace2.id])
expect(epic_wis.map(&:iid).uniq).to match_array(backfilled_epics.map(&:iid).uniq)
expect(epic_wis.map(&:title).uniq).to match_array(backfilled_epics.map(&:title).uniq)
# all colors on the work items with a color should be the same as the epic colors
expect(epic_wi_colors.map { |wi_color| [wi_color.issue_id, wi_color.color] }).to match_array(
backfilled_epics.where(issue_id: epic_wi_colors.pluck(:issue_id)).map { |epic| [epic.issue_id, epic.color] }
)
# for colors not linked to an epic work item we should have epics on default color
default_color_epics = backfilled_epics.where.not(issue_id: epic_wi_colors.pluck(:issue_id)).pluck(:color).uniq
expect(default_color_epics).to eq(['#1068bf'])
end
end
def epic_data(idx, namespace)
{
title: "epic #{idx}",
title_html: "epic #{idx}",
iid: idx,
author_id: author.id,
# this is to reproduce the PG::ForeignKeyViolation handled in
# BackfillEpicBasicFieldsToWorkItemRecord#build_work_items by fetching the updated_by_user_ids data
updated_by_id: idx.even? ? author.id : rand(10_000),
group_id: namespace.id,
# set every other epic color to default one
color: idx.even? ? color(idx * 1000) : '#1068bf'
}
end
def color(idx)
"##{idx.to_s(16).rjust(6, '0')}"
end
end

27
spec/migrations/20240528112758_queue_resync_basic_epic_fields_to_work_item_spec.rb Normal file
View File

@ -0,0 +1,27 @@
# frozen_string_literal: true
require 'spec_helper'
require_migration!
RSpec.describe QueueResyncBasicEpicFieldsToWorkItem, feature_category: :team_planning do
let!(:batched_migration) { described_class::MIGRATION }
it 'schedules a new batched migration' do
reversible_migration do |migration|
migration.before -> {
expect(batched_migration).not_to have_scheduled_batched_migration
}
migration.after -> {
expect(batched_migration).to have_scheduled_batched_migration(
table_name: :epics,
column_name: :id,
job_arguments: [nil],
interval: described_class::DELAY_INTERVAL,
batch_size: described_class::BATCH_SIZE,
sub_batch_size: described_class::SUB_BATCH_SIZE
)
}
end
end
end