diff --git a/GITALY_SERVER_VERSION b/GITALY_SERVER_VERSION index 17d8b9d5258..ffee22f3696 100644 --- a/GITALY_SERVER_VERSION +++ b/GITALY_SERVER_VERSION @@ -1 +1 @@ -3bbb3fdc9a3c5294e2bf2b3f5a06b7aa059ca2d5 +c3e5dc8bf1d451e09e0e207358bd5df346ccf6df diff --git a/GITLAB_KAS_VERSION b/GITLAB_KAS_VERSION index 69a3f4e0846..ec83f5c5beb 100644 --- a/GITLAB_KAS_VERSION +++ b/GITLAB_KAS_VERSION @@ -1 +1 @@ -8197a694087583b69b30c12f22eac6a9ed2b20eb +v17.1.0-rc11 diff --git a/app/assets/javascripts/ci/catalog/components/shared/ci_verification_badge.vue b/app/assets/javascripts/ci/catalog/components/shared/ci_verification_badge.vue index fbfdb0c5ac5..9b82007476a 100644 --- a/app/assets/javascripts/ci/catalog/components/shared/ci_verification_badge.vue +++ b/app/assets/javascripts/ci/catalog/components/shared/ci_verification_badge.vue @@ -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 { - {{ $options.i18n.verificationLevelPopoverLink }} + {{ popoverLink }} diff --git a/app/assets/javascripts/ci/catalog/constants.js b/app/assets/javascripts/ci/catalog/constants.js index 552818c352b..b8184e0b6c6 100644 --- a/app/assets/javascripts/ci/catalog/constants.js +++ b/app/assets/javascripts/ci/catalog/constants.js @@ -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, + }, }; diff --git a/db/docs/batched_background_migrations/resync_basic_epic_fields_to_work_item.yml b/db/docs/batched_background_migrations/resync_basic_epic_fields_to_work_item.yml new file mode 100644 index 00000000000..aa5c402bba4 --- /dev/null +++ b/db/docs/batched_background_migrations/resync_basic_epic_fields_to_work_item.yml @@ -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' diff --git a/db/post_migrate/20240528112758_queue_resync_basic_epic_fields_to_work_item.rb b/db/post_migrate/20240528112758_queue_resync_basic_epic_fields_to_work_item.rb new file mode 100644 index 00000000000..a5e57bae8cc --- /dev/null +++ b/db/post_migrate/20240528112758_queue_resync_basic_epic_fields_to_work_item.rb @@ -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 diff --git a/db/schema_migrations/20240528112758 b/db/schema_migrations/20240528112758 new file mode 100644 index 00000000000..47348999b8c --- /dev/null +++ b/db/schema_migrations/20240528112758 @@ -0,0 +1 @@ +146e57586d358c69e882ef639469730f2035538ee01425ba8932046cee0e2986 \ No newline at end of file diff --git a/doc/.vale/gitlab/RelativeLinksDoubleSlashes.yml b/doc/.vale/gitlab/RelativeLinksDoubleSlashes.yml index 6a94c7f927a..5b22363aa5e 100644 --- a/doc/.vale/gitlab/RelativeLinksDoubleSlashes.yml +++ b/doc/.vale/gitlab/RelativeLinksDoubleSlashes.yml @@ -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\/)' diff --git a/doc/administration/auth/ldap/ldap_synchronization.md b/doc/administration/auth/ldap/ldap_synchronization.md index fefedfc033e..8f23dc0d5da 100644 --- a/doc/administration/auth/ldap/ldap_synchronization.md +++ b/doc/administration/auth/ldap/ldap_synchronization.md @@ -19,7 +19,7 @@ You can change when synchronization occurs. ## User sync -> - Preventing LDAP user's profile name synchronization [introduced]() 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. diff --git a/doc/api/api_resources.md b/doc/api/api_resources.md index 8f5ce1bde5d..f35bbd02cae 100644 --- a/doc/api/api_resources.md +++ b/doc/api/api_resources.md @@ -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` | diff --git a/doc/api/commits.md b/doc/api/commits.md index fb3cf916d4a..4d0796336e3 100644 --- a/doc/api/commits.md +++ b/doc/api/commits.md @@ -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 diff --git a/doc/architecture/blueprints/cells/infrastructure/diff-between-dedicated.md b/doc/architecture/blueprints/cells/infrastructure/diff-between-dedicated.md index 64f1d0023d3..20bafbf6d85 100644 --- a/doc/architecture/blueprints/cells/infrastructure/diff-between-dedicated.md +++ b/doc/architecture/blueprints/cells/infrastructure/diff-between-dedicated.md @@ -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](] (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: diff --git a/doc/architecture/blueprints/container_registry_metadata_database/index.md b/doc/architecture/blueprints/container_registry_metadata_database/index.md index 0496ab7bd45..d0331129022 100644 --- a/doc/architecture/blueprints/container_registry_metadata_database/index.md +++ b/doc/architecture/blueprints/container_registry_metadata_database/index.md @@ -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. diff --git a/doc/architecture/blueprints/gitaly_handle_upload_pack_in_http2_server/index.md b/doc/architecture/blueprints/gitaly_handle_upload_pack_in_http2_server/index.md index 897f9f97365..99f941a106c 100644 --- a/doc/architecture/blueprints/gitaly_handle_upload_pack_in_http2_server/index.md +++ b/doc/architecture/blueprints/gitaly_handle_upload_pack_in_http2_server/index.md @@ -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` diff --git a/doc/architecture/blueprints/gitlab_events_platform/index.md b/doc/architecture/blueprints/gitlab_events_platform/index.md index 303430e558d..6298d6e4f64 100644 --- a/doc/architecture/blueprints/gitlab_events_platform/index.md +++ b/doc/architecture/blueprints/gitlab_events_platform/index.md @@ -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 diff --git a/doc/architecture/blueprints/runway/index.md b/doc/architecture/blueprints/runway/index.md index 2313d953335..e7275330293 100644 --- a/doc/architecture/blueprints/runway/index.md +++ b/doc/architecture/blueprints/runway/index.md @@ -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 diff --git a/doc/development/ai_architecture.md b/doc/development/ai_architecture.md index 545cebef8eb..e19320d7e2c 100644 --- a/doc/development/ai_architecture.md +++ b/doc/development/ai_architecture.md @@ -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). diff --git a/doc/development/ai_features/duo_chat.md b/doc/development/ai_features/duo_chat.md index d855a0c589c..81e65a39f22 100644 --- a/doc/development/ai_features/duo_chat.md +++ b/doc/development/ai_features/duo_chat.md @@ -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`](). +in the project [`GitLab-org/ai-powered/ai-framework/qa-evaluation`](https://gitlab.com/gitlab-org/ai-powered/ai-framework/qa-evaluation). ## GraphQL Subscription diff --git a/doc/development/ai_features/glossary.md b/doc/development/ai_features/glossary.md index df7082be2fa..7edbb61ca50 100644 --- a/doc/development/ai_features/glossary.md +++ b/doc/development/ai_features/glossary.md @@ -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. diff --git a/doc/development/application_limits.md b/doc/development/application_limits.md index 55280e6fae6..700cad259e0 100644 --- a/doc/development/application_limits.md +++ b/doc/development/application_limits.md @@ -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. diff --git a/doc/development/cascading_settings.md b/doc/development/cascading_settings.md index a4e6021da48..adadeed2e24 100644 --- a/doc/development/cascading_settings.md +++ b/doc/development/cascading_settings.md @@ -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 diff --git a/doc/development/cloud_connector/index.md b/doc/development/cloud_connector/index.md index c45b4a9f4dc..3ef63e72a54 100644 --- a/doc/development/cloud_connector/index.md +++ b/doc/development/cloud_connector/index.md @@ -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) diff --git a/doc/development/contributing/first_contribution/contribute-gdk.md b/doc/development/contributing/first_contribution/contribute-gdk.md index 146ee9bbd38..8e011fac60c 100644 --- a/doc/development/contributing/first_contribution/contribute-gdk.md +++ b/doc/development/contributing/first_contribution/contribute-gdk.md @@ -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) diff --git a/doc/development/contributing/first_contribution/contribute-web-ide.md b/doc/development/contributing/first_contribution/contribute-web-ide.md index 6bec99ab64a..0af9856e7f6 100644 --- a/doc/development/contributing/first_contribution/contribute-web-ide.md +++ b/doc/development/contributing/first_contribution/contribute-web-ide.md @@ -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"`. diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index 43d92f04cf7..2bbd349fbff 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -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). diff --git a/doc/development/database/migrations_for_multiple_databases.md b/doc/development/database/migrations_for_multiple_databases.md index 97b519e407f..44228b22233 100644 --- a/doc/development/database/migrations_for_multiple_databases.md +++ b/doc/development/database/migrations_for_multiple_databases.md @@ -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 ``` diff --git a/doc/development/documentation/experiment_beta.md b/doc/development/documentation/experiment_beta.md index 776b25ba67c..b7bbac100e2 100644 --- a/doc/development/documentation/experiment_beta.md +++ b/doc/development/documentation/experiment_beta.md @@ -28,7 +28,7 @@ For example: DETAILS: **Status:** Experiment -> - [Introduced](link) in GitLab 15.10. This feature is an [experiment](/policy/experiment-beta-support.md). +> - [Introduced](https://issue-link) in GitLab 15.10. This feature is an [experiment](/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](/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: diff --git a/doc/development/documentation/feature_flags.md b/doc/development/documentation/feature_flags.md index 8cbb0670395..7dbb23b6cbe 100644 --- a/doc/development/documentation/feature_flags.md +++ b/doc/development/documentation/feature_flags.md @@ -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. ``` diff --git a/doc/development/documentation/restful_api_styleguide.md b/doc/development/documentation/restful_api_styleguide.md index 52b5a617f0b..6117a623dd8 100644 --- a/doc/development/documentation/restful_api_styleguide.md +++ b/doc/development/documentation/restful_api_styleguide.md @@ -106,7 +106,7 @@ for the section. For example: ```markdown ### Edit a widget -> - `widget_message` [introduced]() 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]() 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]() 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, diff --git a/doc/development/documentation/site_architecture/folder_structure.md b/doc/development/documentation/site_architecture/folder_structure.md index f7ddf30f3d4..09e06c4aedc 100644 --- a/doc/development/documentation/site_architecture/folder_structure.md +++ b/doc/development/documentation/site_architecture/folder_structure.md @@ -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 diff --git a/doc/development/documentation/styleguide/availability_details.md b/doc/development/documentation/styleguide/availability_details.md index 09c433e7820..1ea4da3fabd 100644 --- a/doc/development/documentation/styleguide/availability_details.md +++ b/doc/development/documentation/styleguide/availability_details.md @@ -21,7 +21,7 @@ DETAILS: **Offering:** GitLab.com, Self-managed, GitLab Dedicated **Status:** Experiment -> - [Introduced]() in GitLab 16.3. +> - [Introduced](https://link-to-issue) in GitLab 16.3. > - Updated in GitLab 16.4. ``` diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md index 895508ee8da..351425a26be 100644 --- a/doc/development/documentation/styleguide/index.md +++ b/doc/development/documentation/styleguide/index.md @@ -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 -For an overview, see [Video Title](link-to-video). +For an overview, see [Video Title](https://link-to-video). ``` @@ -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). ``` @@ -2003,8 +2003,8 @@ DETAILS: **Tier:** Premium, Ultimate **Offering:** Self-managed - - Information specific to Geo. - - ... +- Information specific to Geo. +- ... ## X.Y.0 diff --git a/doc/development/documentation/styleguide/word_list.md b/doc/development/documentation/styleguide/word_list.md index 5776ce37a6a..5e3d65a07cf 100644 --- a/doc/development/documentation/styleguide/word_list.md +++ b/doc/development/documentation/styleguide/word_list.md @@ -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). diff --git a/doc/development/documentation/topic_types/get_started.md b/doc/development/documentation/topic_types/get_started.md index 60f03e4a5b8..9d418aa6c90 100644 --- a/doc/development/documentation/topic_types/get_started.md +++ b/doc/development/documentation/topic_types/get_started.md @@ -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 diff --git a/doc/development/documentation/topic_types/index.md b/doc/development/documentation/topic_types/index.md index da7dd50b94c..3d03b07538b 100644 --- a/doc/development/documentation/topic_types/index.md +++ b/doc/development/documentation/topic_types/index.md @@ -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) ``` diff --git a/doc/development/documentation/topic_types/task.md b/doc/development/documentation/topic_types/task.md index 2130a28c56c..c0ae98ce484 100644 --- a/doc/development/documentation/topic_types/task.md +++ b/doc/development/documentation/topic_types/task.md @@ -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 diff --git a/doc/development/documentation/versions.md b/doc/development/documentation/versions.md index 256d79ca7e6..96a75afbf99 100644 --- a/doc/development/documentation/versions.md +++ b/doc/development/documentation/versions.md @@ -37,7 +37,7 @@ For example: ```markdown ## Feature name -> - [Introduced]() 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]() in GitLab 13.1. -> - Creating an issue from an issue board [introduced]() 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]() in GitLab 13.1. -> - Notifications for expiring tokens [introduced]() 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]() in GitLab 15.1. -> - Merged results pipelines [added]() to the [Registration Features Program]() 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]() from GitLab Ultimate to GitLab Premium in 11.8. -> - [Moved]() 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]() as an [experiment](../../policy/experiment-beta-support.md) in GitLab 15.7. -> - [Changed]() 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]() 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]() in GitLab 14.8 - and is planned for removal in 15.4. Use [feature X]() 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]() in GitLab 14.8 - and is planned for removal in 15.4. Use [feature X]() 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. ``` @@ -216,9 +216,9 @@ To remove a page: **Tier:** Premium, Ultimate **Offering:** GitLab.com, Self-managed, GitLab Dedicated - This feature was [deprecated]() in GitLab X.Y - and [removed]() in X.Y. - Use [feature X]() 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]() in GitLab X.Y - and [removed]() in X.Y. - Use [feature X]() 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. ``` @@ -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 ](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 ](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. diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md index 47e81328525..9dbf7b3676c 100644 --- a/doc/development/documentation/workflow.md +++ b/doc/development/documentation/workflow.md @@ -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 diff --git a/doc/development/experiment_guide/experiment_rollout.md b/doc/development/experiment_guide/experiment_rollout.md index 3dc2bba5915..b24b50ab406 100644 --- a/doc/development/experiment_guide/experiment_rollout.md +++ b/doc/development/experiment_guide/experiment_rollout.md @@ -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: diff --git a/doc/development/fe_guide/customizable_dashboards.md b/doc/development/fe_guide/customizable_dashboards.md index d38260b0131..e4f552f8d73 100644 --- a/doc/development/fe_guide/customizable_dashboards.md +++ b/doc/development/fe_guide/customizable_dashboards.md @@ -312,3 +312,26 @@ export default { ``` + +## 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 +``` diff --git a/doc/development/fe_guide/diagrams_net_integration.md b/doc/development/fe_guide/diagrams_net_integration.md index 388c7642914..073570d5942 100644 --- a/doc/development/fe_guide/diagrams_net_integration.md +++ b/doc/development/fe_guide/diagrams_net_integration.md @@ -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 diff --git a/doc/development/fe_guide/graphql.md b/doc/development/fe_guide/graphql.md index 258b4afe89e..538890fb3e8 100644 --- a/doc/development/fe_guide/graphql.md +++ b/doc/development/fe_guide/graphql.md @@ -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**. diff --git a/doc/development/fe_guide/merge_request_widget_extensions.md b/doc/development/fe_guide/merge_request_widget_extensions.md index ad77e90efc8..fe065866acc 100644 --- a/doc/development/fe_guide/merge_request_widget_extensions.md +++ b/doc/development/fe_guide/merge_request_widget_extensions.md @@ -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 diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index d3e2ede01c1..28d82c4eeeb 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -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. diff --git a/doc/development/gems.md b/doc/development/gems.md index 3b07d33e2ec..825abf01029 100644 --- a/doc/development/gems.md +++ b/doc/development/gems.md @@ -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/` 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 diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md index 1fdd5a74132..4badd766f14 100644 --- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md +++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md @@ -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). diff --git a/doc/development/image_scaling.md b/doc/development/image_scaling.md index 05792bfd5a3..01dca815be8 100644 --- a/doc/development/image_scaling.md +++ b/doc/development/image_scaling.md @@ -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 diff --git a/doc/development/integrations/secure_partner_integration.md b/doc/development/integrations/secure_partner_integration.md index e8bc3665246..425038ecb45 100644 --- a/doc/development/integrations/secure_partner_integration.md +++ b/doc/development/integrations/secure_partner_integration.md @@ -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 diff --git a/doc/development/internal_analytics/metrics/metrics_lifecycle.md b/doc/development/internal_analytics/metrics/metrics_lifecycle.md index e3b45e3e710..146768391cb 100644 --- a/doc/development/internal_analytics/metrics/metrics_lifecycle.md +++ b/doc/development/internal_analytics/metrics/metrics_lifecycle.md @@ -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: diff --git a/doc/development/logging.md b/doc/development/logging.md index 70942840d08..c19f6562277 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -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 diff --git a/doc/development/pages/index.md b/doc/development/pages/index.md index 53685c899a0..53229686563 100644 --- a/doc/development/pages/index.md +++ b/doc/development/pages/index.md @@ -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: diff --git a/doc/development/reference_processing.md b/doc/development/reference_processing.md index 044c1b01b30..a993e9c18fa 100644 --- a/doc/development/reference_processing.md +++ b/doc/development/reference_processing.md @@ -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 diff --git a/doc/development/sec/analyzer_development_guide.md b/doc/development/sec/analyzer_development_guide.md index 879a6d084b0..6f1d6f209cb 100644 --- a/doc/development/sec/analyzer_development_guide.md +++ b/doc/development/sec/analyzer_development_guide.md @@ -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 diff --git a/doc/development/sec/index.md b/doc/development/sec/index.md index 9e8486b26fa..2e7c0573231 100644 --- a/doc/development/sec/index.md +++ b/doc/development/sec/index.md @@ -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 diff --git a/doc/development/sec/security_report_ingestion_overview.md b/doc/development/sec/security_report_ingestion_overview.md index f307f5b3b9a..d959370154c 100644 --- a/doc/development/sec/security_report_ingestion_overview.md +++ b/doc/development/sec/security_report_ingestion_overview.md @@ -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. diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md index 5b6805266ce..4665b6b7e88 100644 --- a/doc/development/secure_coding_guidelines.md +++ b/doc/development/secure_coding_guidelines.md @@ -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. diff --git a/doc/development/sidekiq/index.md b/doc/development/sidekiq/index.md index 83cafdc6b02..3cbd427df5a 100644 --- a/doc/development/sidekiq/index.md +++ b/doc/development/sidekiq/index.md @@ -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 diff --git a/doc/development/software_design.md b/doc/development/software_design.md index e9919ccf9c8..dc809811144 100644 --- a/doc/development/software_design.md +++ b/doc/development/software_design.md @@ -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 diff --git a/doc/development/spam_protection_and_captcha/exploratory_testing.md b/doc/development/spam_protection_and_captcha/exploratory_testing.md index 71cf1ef814f..7d798bb927e 100644 --- a/doc/development/spam_protection_and_captcha/exploratory_testing.md +++ b/doc/development/spam_protection_and_captcha/exploratory_testing.md @@ -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). - - #### Initial request This initial request fails because no CAPTCHA response is provided. diff --git a/doc/development/spam_protection_and_captcha/web_ui.md b/doc/development/spam_protection_and_captcha/web_ui.md index f6e417a6647..976d100ddfd 100644 --- a/doc/development/spam_protection_and_captcha/web_ui.md +++ b/doc/development/spam_protection_and_captcha/web_ui.md @@ -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! diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md index 85752a7e6e8..281bebc7e1f 100644 --- a/doc/development/testing_guide/end_to_end/best_practices.md +++ b/doc/development/testing_guide/end_to_end/best_practices.md @@ -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 diff --git a/doc/development/testing_guide/end_to_end/test_pipelines.md b/doc/development/testing_guide/end_to_end/test_pipelines.md index 28cf2ae6e16..987a1e403b8 100644 --- a/doc/development/testing_guide/end_to_end/test_pipelines.md +++ b/doc/development/testing_guide/end_to_end/test_pipelines.md @@ -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 diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md index 01237630c5a..c69616848a6 100644 --- a/doc/development/testing_guide/testing_levels.md +++ b/doc/development/testing_guide/testing_levels.md @@ -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. diff --git a/doc/development/work_items.md b/doc/development/work_items.md index 9d6618442da..b94004cb768 100644 --- a/doc/development/work_items.md +++ b/doc/development/work_items.md @@ -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 diff --git a/doc/development/workhorse/index.md b/doc/development/workhorse/index.md index 48c82ca39e8..ec8938a726e 100644 --- a/doc/development/workhorse/index.md +++ b/doc/development/workhorse/index.md @@ -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. - - diff --git a/doc/integration/index.md b/doc/integration/index.md index e152386550f..2de016bbd55 100644 --- a/doc/integration/index.md +++ b/doc/integration/index.md @@ -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 diff --git a/doc/integration/partner_marketplace.md b/doc/integration/partner_marketplace.md index 582c80204f2..ef6eb8bd22e 100644 --- a/doc/integration/partner_marketplace.md +++ b/doc/integration/partner_marketplace.md @@ -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 diff --git a/doc/topics/release_your_application.md b/doc/topics/release_your_application.md index 2de3c38c81a..b59cb5b1b93 100644 --- a/doc/topics/release_your_application.md +++ b/doc/topics/release_your_application.md @@ -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. diff --git a/doc/user/application_security/api_security/index.md b/doc/user/application_security/api_security/index.md index fb42f26bb8d..c1144c5032f 100644 --- a/doc/user/application_security/api_security/index.md +++ b/doc/user/application_security/api_security/index.md @@ -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. diff --git a/doc/user/application_security/api_security_testing/checks/json_injection_check.md b/doc/user/application_security/api_security_testing/checks/json_injection_check.md index e03a635b614..ad6b2b6bf8e 100644 --- a/doc/user/application_security/api_security_testing/checks/json_injection_check.md +++ b/doc/user/application_security/api_security_testing/checks/json_injection_check.md @@ -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) diff --git a/doc/user/application_security/dast/browser_based_4_to_5_migration_guide.md b/doc/user/application_security/dast/browser_based_4_to_5_migration_guide.md index 3a07ca6721f..aba3406ce9c 100644 --- a/doc/user/application_security/dast/browser_based_4_to_5_migration_guide.md +++ b/doc/user/application_security/dast/browser_based_4_to_5_migration_guide.md @@ -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 | |:--------------------------------------------|:-------------------|:----------------------------------------------| diff --git a/doc/user/application_security/dast/proxy_based_to_browser_based_migration_guide.md b/doc/user/application_security/dast/proxy_based_to_browser_based_migration_guide.md index 41664f99332..112aff65b77 100644 --- a/doc/user/application_security/dast/proxy_based_to_browser_based_migration_guide.md +++ b/doc/user/application_security/dast/proxy_based_to_browser_based_migration_guide.md @@ -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 | |:-------------------------------------|:-------------------------|:-----------------------------------------------------------------------------------------| diff --git a/doc/user/application_security/dependency_list/index.md b/doc/user/application_security/dependency_list/index.md index 35698534aad..6ad8f732770 100644 --- a/doc/user/application_security/dependency_list/index.md +++ b/doc/user/application_security/dependency_list/index.md @@ -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 diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md index e2185a044fb..32197d17476 100644 --- a/doc/user/application_security/vulnerability_report/index.md +++ b/doc/user/application_security/vulnerability_report/index.md @@ -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 diff --git a/doc/user/infrastructure/iac/terraform_template_recipes.md b/doc/user/infrastructure/iac/terraform_template_recipes.md index ba09b6ff00c..651998fa5a4 100644 --- a/doc/user/infrastructure/iac/terraform_template_recipes.md +++ b/doc/user/infrastructure/iac/terraform_template_recipes.md @@ -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. diff --git a/doc/user/project/merge_requests/approvals/settings.md b/doc/user/project/merge_requests/approvals/settings.md index d25ca7354f0..ad100f4c07a 100644 --- a/doc/user/project/merge_requests/approvals/settings.md +++ b/doc/user/project/merge_requests/approvals/settings.md @@ -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 diff --git a/doc/user/project/repository/push_rules.md b/doc/user/project/repository/push_rules.md index 8566b972b28..852cd281df7 100644 --- a/doc/user/project/repository/push_rules.md +++ b/doc/user/project/repository/push_rules.md @@ -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. diff --git a/doc/user/rich_text_editor.md b/doc/user/rich_text_editor.md index 70d86cf4af8..e55a54c2230 100644 --- a/doc/user/rich_text_editor.md +++ b/doc/user/rich_text_editor.md @@ -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 | | ```rb + Enter
```js + Enter | Code block | | `* List item`, or
`- List item`, or
`+ List item` | Unordered list | diff --git a/lib/gitlab/background_migration/backfill_epic_basic_fields_to_work_item_record.rb b/lib/gitlab/background_migration/backfill_epic_basic_fields_to_work_item_record.rb index 342f3e59a44..e2c7b63680e 100644 --- a/lib/gitlab/background_migration/backfill_epic_basic_fields_to_work_item_record.rb +++ b/lib/gitlab/background_migration/backfill_epic_basic_fields_to_work_item_record.rb @@ -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 diff --git a/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item.rb b/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item.rb new file mode 100644 index 00000000000..20beba5c3c2 --- /dev/null +++ b/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item.rb @@ -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 diff --git a/locale/gitlab.pot b/locale/gitlab.pot index 38036fbdc7a..0aecf29d8b9 100644 --- a/locale/gitlab.pot +++ b/locale/gitlab.pot @@ -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 "" diff --git a/qa/Gemfile b/qa/Gemfile index bae40a01a53..8bc70d275ac 100644 --- a/qa/Gemfile +++ b/qa/Gemfile @@ -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 diff --git a/qa/Gemfile.lock b/qa/Gemfile.lock index 906de7a3a15..f15142103ec 100644 --- a/qa/Gemfile.lock +++ b/qa/Gemfile.lock @@ -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) diff --git a/qa/qa/specs/features/browser_ui/3_create/source_editor/source_editor_toolbar_spec.rb b/qa/qa/specs/features/browser_ui/3_create/source_editor/source_editor_toolbar_spec.rb index 73885763df1..9558d15ab14 100644 --- a/qa/qa/specs/features/browser_ui/3_create/source_editor/source_editor_toolbar_spec.rb +++ b/qa/qa/specs/features/browser_ui/3_create/source_editor/source_editor_toolbar_spec.rb @@ -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 diff --git a/spec/frontend/ci/catalog/components/shared/ci_verification_badge_spec.js b/spec/frontend/ci/catalog/components/shared/ci_verification_badge_spec.js index c05a8909fde..02d3e24606c 100644 --- a/spec/frontend/ci/catalog/components/shared/ci_verification_badge_spec.js +++ b/spec/frontend/ci/catalog/components/shared/ci_verification_badge_spec.js @@ -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 }); }); diff --git a/spec/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item_spec.rb b/spec/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item_spec.rb new file mode 100644 index 00000000000..26d4b6c2a36 --- /dev/null +++ b/spec/lib/gitlab/background_migration/resync_basic_epic_fields_to_work_item_spec.rb @@ -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 diff --git a/spec/migrations/20240528112758_queue_resync_basic_epic_fields_to_work_item_spec.rb b/spec/migrations/20240528112758_queue_resync_basic_epic_fields_to_work_item_spec.rb new file mode 100644 index 00000000000..92c05c4fd9e --- /dev/null +++ b/spec/migrations/20240528112758_queue_resync_basic_epic_fields_to_work_item_spec.rb @@ -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