diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-26 12:10:42 +0300 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2023-01-26 12:10:42 +0300 |
| commit | db950c5706cdf47f7ccc2e02a4ffd691432ac5dc (patch) | |
| tree | fdceeac88d490aae384eecc636964d7f03be9c24 | |
| parent | 7cd527ffd9cfef1c872faa5377eaccc3df6ef067 (diff) | |
Add latest changes from gitlab-org/gitlab@master
39 files changed, 545 insertions, 428 deletions
diff --git a/app/helpers/tooling/visual_review_helper.rb b/app/helpers/tooling/visual_review_helper.rb index cd3b8be5aac..47afae49759 100644 --- a/app/helpers/tooling/visual_review_helper.rb +++ b/app/helpers/tooling/visual_review_helper.rb @@ -22,5 +22,9 @@ module Tooling 'id': 'review-app-toolbar-script', 'src': 'https://gitlab.com/assets/webpack/visual_review_toolbar.js' } end + + def review_apps_enabled? + Gitlab::Utils.to_boolean(ENV['REVIEW_APPS_ENABLED'], default: false) + end end end diff --git a/app/models/concerns/sha_attribute.rb b/app/models/concerns/sha_attribute.rb index 701d2fda5c5..35c48c15fb2 100644 --- a/app/models/concerns/sha_attribute.rb +++ b/app/models/concerns/sha_attribute.rb @@ -22,7 +22,7 @@ module ShaAttribute class_methods do def sha_attribute(name) - return if ENV['STATIC_VERIFICATION'] + return if Gitlab::Environment.static_verification? sha_attribute_fields << name @@ -34,7 +34,7 @@ module ShaAttribute end def sha256_attribute(name) - return if ENV['STATIC_VERIFICATION'] + return if Gitlab::Environment.static_verification? sha256_attribute_fields << name diff --git a/app/models/concerns/x509_serial_number_attribute.rb b/app/models/concerns/x509_serial_number_attribute.rb index 9dc53859ac0..b65736b7924 100644 --- a/app/models/concerns/x509_serial_number_attribute.rb +++ b/app/models/concerns/x509_serial_number_attribute.rb @@ -5,7 +5,7 @@ module X509SerialNumberAttribute class_methods do def x509_serial_number_attribute(name) - return if ENV['STATIC_VERIFICATION'] + return if Gitlab::Environment.static_verification? validate_binary_column_exists!(name) unless Rails.env.production? diff --git a/app/views/layouts/application.html.haml b/app/views/layouts/application.html.haml index fa79219df4a..53e88d95893 100644 --- a/app/views/layouts/application.html.haml +++ b/app/views/layouts/application.html.haml @@ -8,7 +8,7 @@ %body{ class: body_classes, data: body_data } = render "layouts/init_auto_complete" if @gfm_form = render "layouts/init_client_detection_flags" - = render "layouts/visual_review" if ENV['REVIEW_APPS_ENABLED'] + = render "layouts/visual_review" if review_apps_enabled? = render 'peek/bar' = header_message diff --git a/config/metrics/counts_28d/20230112174745_i_testing_active_user_monthly.yml b/config/metrics/counts_28d/20230112174745_i_testing_active_user_monthly.yml new file mode 100644 index 00000000000..8f73011a6ed --- /dev/null +++ b/config/metrics/counts_28d/20230112174745_i_testing_active_user_monthly.yml @@ -0,0 +1,29 @@ +--- +data_category: optional +key_path: redis_hll_counters.testing.i_testing_active_user_monthly +description: Count of monthly active users for pipeline insights features +product_section: ops +product_stage: verify +product_group: pipeline_insights +product_category: testing +value_type: number +status: active +milestone: "15.9" +introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108629 +time_frame: 28d +instrumentation_class: AggregatedMetric +data_source: redis_hll +options: + aggregate: + operator: OR + attribute: user_id + events: + - 'i_testing_test_report_uploaded' + - 'i_testing_coverage_report_uploaded' +distribution: +- ce +- ee +tier: +- free +- premium +- ultimate diff --git a/config/metrics/counts_7d/20230112174745_i_testing_active_user_weekly.yml b/config/metrics/counts_7d/20230112174745_i_testing_active_user_weekly.yml new file mode 100644 index 00000000000..d1c553601e6 --- /dev/null +++ b/config/metrics/counts_7d/20230112174745_i_testing_active_user_weekly.yml @@ -0,0 +1,29 @@ +--- +data_category: optional +key_path: redis_hll_counters.testing.i_testing_active_user_weekly +description: Count of weekly active users for pipeline insights features +product_section: ops +product_stage: verify +product_group: pipeline_insights +product_category: testing +value_type: number +status: active +milestone: "15.9" +introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108629 +time_frame: 7d +instrumentation_class: AggregatedMetric +data_source: redis_hll +options: + aggregate: + operator: OR + attribute: user_id + events: + - 'i_testing_test_report_uploaded' + - 'i_testing_coverage_report_uploaded' +distribution: +- ce +- ee +tier: +- free +- premium +- ultimate diff --git a/db/post_migrate/20230112141236_schedule_vulnerabilities_feedback_migration2.rb b/db/post_migrate/20230112141236_schedule_vulnerabilities_feedback_migration2.rb new file mode 100644 index 00000000000..08ceea1022c --- /dev/null +++ b/db/post_migrate/20230112141236_schedule_vulnerabilities_feedback_migration2.rb @@ -0,0 +1,36 @@ +# frozen_string_literal: true + +class ScheduleVulnerabilitiesFeedbackMigration2 < Gitlab::Database::Migration[2.1] + MIGRATION = 'MigrateVulnerabilitiesFeedbackToVulnerabilitiesStateTransition' + TABLE_NAME = :vulnerability_feedback + BATCH_COLUMN = :id + DELAY_INTERVAL = 5.minutes + BATCH_SIZE = 250 + MAX_BATCH_SIZE = 250 + SUB_BATCH_SIZE = 50 + + disable_ddl_transaction! + + restrict_gitlab_migration gitlab_schema: :gitlab_main + + def up + queue_batched_background_migration( + MIGRATION, + TABLE_NAME, + BATCH_COLUMN, + job_interval: DELAY_INTERVAL, + batch_size: BATCH_SIZE, + max_batch_size: MAX_BATCH_SIZE, + sub_batch_size: SUB_BATCH_SIZE + ) + end + + def down + delete_batched_background_migration( + MIGRATION, + TABLE_NAME, + BATCH_COLUMN, + [] + ) + end +end diff --git a/db/schema_migrations/20230112141236 b/db/schema_migrations/20230112141236 new file mode 100644 index 00000000000..6f22c27eb01 --- /dev/null +++ b/db/schema_migrations/20230112141236 @@ -0,0 +1 @@ +d313ee9c99032255e491c1d2113d4ab07c4619287b5bceeb64ee08235f88f434
\ No newline at end of file diff --git a/doc/api/group_level_variables.md b/doc/api/group_level_variables.md index d25d5ac8007..4037a778d7f 100644 --- a/doc/api/group_level_variables.md +++ b/doc/api/group_level_variables.md @@ -92,7 +92,7 @@ POST /groups/:id/variables | `variable_type` | string | no | The type of a variable. Available types are: `env_var` (default) and `file` | | `protected` | boolean | no | Whether the variable is protected | | `masked` | boolean | no | Whether the variable is masked | -| `raw` | boolean | no | Whether the variable is expandable | +| `raw` | boolean | no | Whether the variable is treated as a raw string. Default: `false`. When `true`, variables in the value are not [expanded](../ci/variables/index.md#prevent-cicd-variable-expansion). | | `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/environments/index.md#limit-the-environment-scope-of-a-cicd-variable) of a variable | ```shell @@ -128,7 +128,7 @@ PUT /groups/:id/variables/:key | `variable_type` | string | no | The type of a variable. Available types are: `env_var` (default) and `file` | | `protected` | boolean | no | Whether the variable is protected | | `masked` | boolean | no | Whether the variable is masked | -| `raw` | boolean | no | Whether the variable is expandable | +| `raw` | boolean | no | Whether the variable is treated as a raw string. Default: `false`. When `true`, variables in the value are not [expanded](../ci/variables/index.md#prevent-cicd-variable-expansion). | | `environment_scope` **(PREMIUM)** | string | no | The [environment scope](../ci/environments/index.md#limit-the-environment-scope-of-a-cicd-variable) of a variable | ```shell diff --git a/doc/api/project_level_variables.md b/doc/api/project_level_variables.md index 02e64c3f7f9..92ca2849e8e 100644 --- a/doc/api/project_level_variables.md +++ b/doc/api/project_level_variables.md @@ -95,7 +95,7 @@ POST /projects/:id/variables | `variable_type` | string | no | The type of a variable. Available types are: `env_var` (default) and `file` | | `protected` | boolean | no | Whether the variable is protected. Default: `false` | | `masked` | boolean | no | Whether the variable is masked. Default: `false` | -| `raw` | boolean | no | Whether the variable is expandable. Default: `false` | +| `raw` | boolean | no | Whether the variable is treated as a raw string. Default: `false`. When `true`, variables in the value are not [expanded](../ci/variables/index.md#prevent-cicd-variable-expansion). | | `environment_scope` | string | no | The `environment_scope` of the variable. Default: `*` | ```shell @@ -132,7 +132,7 @@ PUT /projects/:id/variables/:key | `variable_type` | string | no | The type of a variable. Available types are: `env_var` (default) and `file` | | `protected` | boolean | no | Whether the variable is protected | | `masked` | boolean | no | Whether the variable is masked | -| `raw` | boolean | no | Whether the variable is expandable. Default: `false` | +| `raw` | boolean | no | Whether the variable is treated as a raw string. Default: `false`. When `true`, variables in the value are not [expanded](../ci/variables/index.md#prevent-cicd-variable-expansion). | | `environment_scope` | string | no | The `environment_scope` of the variable | | `filter` | hash | no | Available filters: `[environment_scope]`. See the [`filter` parameter details](#the-filter-parameter). | diff --git a/doc/api/repositories.md b/doc/api/repositories.md index 82423f35095..ac54902f9f4 100644 --- a/doc/api/repositories.md +++ b/doc/api/repositories.md @@ -316,11 +316,15 @@ of commits, GitLab generates a changelog for all commits that use a particular a new Markdown-formatted section to a changelog file in the Git repository of the project. The output format can be customized. +For user-facing documentation, see [Changelogs](../user/project/changelog.md). + ```plaintext POST /projects/:id/repository/changelog ``` -Supported attributes: +### Supported attributes + +Changelogs support these attributes: | Attribute | Type | Required | Description | | :-------- | :------- | :--------- | :---------- | @@ -403,319 +407,6 @@ To store the results in a different file, use the `file` parameter: curl --request POST --header "PRIVATE-TOKEN: token" --data "version=1.0.0&file=NEWS" "https://gitlab.com/api/v4/projects/42/repository/changelog" ``` -### How it works - -Changelogs are generated based on commit titles. Commits are only included if -they contain a specific Git trailer. GitLab uses the value of this trailer to -categorize the changes. - -GitLab uses Git trailers, because Git trailers are -supported by Git out of the box. We use commits as input, as this is the only -source of data every project uses. In addition, commits can be retrieved when -operating on a mirror. This is important for GitLab itself, because during a security -release we might need to include changes from both public projects and private -security mirrors. - -Changelogs are generated by taking the title of the commits to include and using -these as the changelog entries. You can enrich entries with additional data, -such as a link to the merge request or details about the commit author. You can -[customize the format of a changelog](#customize-the-changelog-output) section with a template. - -Trailers can be manually added while editing a commit message. To include a commit -using the default trailer of `Changelog` and categorize it as a feature, the -trailer could be added to a commit message like so: - -```plaintext -<Commit message subject> - -<Commit message description> - -Changelog: feature -``` - -### Reverted commits - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55537) in GitLab 13.10. - -When generating a changelog for a range, GitLab ignores commits both added and -reverted in that range. Revert commits themselves _are_ included if they use the -Git trailer used for generating changelogs. - -Imagine the following scenario: you have three commits: A, B, and C. To generate -changelogs, you use the default trailer `Changelog`. Both A and B use this -trailer. Commit C is a commit that reverts commit B. When generating a changelog -for this range, GitLab only includes commit A. - -Revert commits are detected by looking for commits where the message contains -the pattern `This reverts commit SHA`, where `SHA` is the SHA of the commit that -is reverted. - -If a revert commit includes the trailer used for generating changelogs -(`Changelog` in the above example), the revert commit itself _is_ included. - -### Customize the changelog output - -The output is customized using a YAML configuration file stored in your -project's Git repository. This default configuration file path is -`.gitlab/changelog_config.yml`. - -You can set the following variables in this file: - -- `date_format`: the date format to use in the title of the newly added - changelog data. This uses regular `strftime` formatting. -- `template`: a custom template to use for generating the changelog data. -- `categories`: a hash that maps raw category names to the names to use in the - changelog. -- `include_groups`: a list of group full paths containing users whose - contributions should be credited regardless of project membership. The user - generating the changelog must have access to each group or the members will - not be credited. - -Using the default settings, generating a changelog results in a section along -the lines of the following: - -```markdown -## 1.0.0 (2021-01-05) - -### Features (4 changes) - -- [Feature 1](gitlab-org/gitlab@123abc) by @alice ([merge request](gitlab-org/gitlab!123)) -- [Feature 2](gitlab-org/gitlab@456abc) ([merge request](gitlab-org/gitlab!456)) -- [Feature 3](gitlab-org/gitlab@234abc) by @steve -- [Feature 4](gitlab-org/gitlab@456) -``` - -Each section starts with a title that contains the version and release date. -While the format of the date can be customized, the rest of the title can't be -changed. When adding a new section, GitLab parses these titles to determine -where in the file the new section should be placed. GitLab sorts sections -according to their versions, not their dates. - -Each section can have categories, each with their -corresponding changes. In the above example, "Features" is one such category. -You can customize the format of these sections. - -The section names are derived from the values of the Git trailer used to include -or exclude commits. - -For example, if the trailer to use is called `Changelog`, -and its value is `feature`, then the commit is grouped in the `feature` -category. The names of these raw values might differ from what you want to -show in a changelog, you can remap them. Let's say we use the `Changelog` -trailer and developers use the following values: `feature`, `bug`, and -`performance`. - -You can remap these using the following YAML configuration file: - -```yaml ---- -categories: - feature: Features - bug: Bug fixes - performance: Performance improvements -``` - -When generating the changelog data, the category titles are then `### Features`, -`### Bug fixes`, and `### Performance improvements`. - -### Custom templates - -The category sections are generated using a template. The default template is as -follows: - -```plaintext -{% if categories %} -{% each categories %} -### {{ title }} ({% if single_change %}1 change{% else %}{{ count }} changes{% end %}) - -{% each entries %} -- [{{ title }}]({{ commit.reference }})\ -{% if author.credit %} by {{ author.reference }}{% end %}\ -{% if merge_request %} ([merge request]({{ merge_request.reference }})){% end %} - -{% end %} - -{% end %} -{% else %} -No changes. -{% end %} -``` - -The `{% ... %}` tags are for statements, and `{{ ... }}` is used for printing -data. Statements must be terminated using a `{% end %}` tag. Both the `if` and -`each` statements require a single argument. - -For example, if we have a variable `valid`, and we want to display "yes" -when this value is true, and display "nope" otherwise. We can do so as follows: - -```plaintext -{% if valid %} -yes -{% else %} -nope -{% end %} -``` - -The use of `else` is optional. A value is considered true when it's a non-empty -value or boolean `true`. Empty arrays and hashes are considered false. - -Looping is done using `each`, and variables inside a loop are scoped to it. -Referring to the current value in a loop is done using the variable tag `{{ it -}}`. Other variables read their value from the current loop value. Take -this template for example: - -```plaintext -{% each users %} -{{name}} -{% end %} -``` - -Assuming `users` is an array of objects, each with a `name` field, this would -then print the name of every user. - -Using variable tags, you can access nested objects. For example, `{{ -users.0.name }}` prints the name of the first user in the `users` variable. - -If a line ends in a backslash, the next newline is ignored. This allows you to -wrap code across multiple lines, without introducing unnecessary newlines in the -Markdown output. - -Tags that use `{%` and `%}` (known as expression tags) consume the newline that -directly follows them, if any. This means that this: - -```plaintext ---- -{% if foo %} -bar -{% end %} ---- -``` - -Compiles into this: - -```plaintext ---- -bar ---- -``` - -Instead of this: - -```plaintext ---- - -bar - ---- -``` - -You can specify a custom template in your configuration like so: - -```yaml ---- -template: | - {% if categories %} - {% each categories %} - ### {{ title }} - - {% each entries %} - - [{{ title }}]({{ commit.reference }})\ - {% if author.credit %} by {{ author.reference }}{% end %} - - {% end %} - - {% end %} - {% else %} - No changes. - {% end %} -``` - -When specifying the template you should use `template: |` and not -`template: >`, as the latter doesn't preserve newlines in the template. - -### Template data - -At the top level, the following variable is available: - -- `categories`: an array of objects, one for every changelog category. - -In a category, the following variables are available: - -- `count`: the number of entries in this category. -- `entries`: the entries that belong to this category. -- `single_change`: a boolean that indicates if there is only one change (`true`), - or multiple changes (`false`). -- `title`: the title of the category (after it has been remapped). - -In an entry, the following variables are available (here `foo.bar` means that -`bar` is a sub-field of `foo`): - -- `author.contributor`: a boolean set to `true` when the author is not a project - member, otherwise `false`. -- `author.credit`: a boolean set to `true` when `author.contributor` is `true` or - when `include_groups` is configured, and the author is a member of one of the - groups. -- `author.reference`: a reference to the commit author (for example, `@alice`). -- `commit.reference`: a reference to the commit, for example, - `gitlab-org/gitlab@0a4cdd86ab31748ba6dac0f69a8653f206e5cfc7`. -- `commit.trailers`: an object containing all the Git trailers that were present - in the commit body. -- `merge_request.reference`: a reference to the merge request that first - introduced the change (for example, `gitlab-org/gitlab!50063`). -- `title`: the title of the changelog entry (this is the commit title). - -The `author` and `merge_request` objects might not be present if the data -couldn't be determined. For example, when a commit is created without a -corresponding merge request, no merge request is displayed. - -### Customize the tag format when extracting versions - -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56889) in GitLab 13.11. - -GitLab uses a regular expression (using the -[re2](https://github.com/google/re2/) engine and syntax) to extract a semantic -version from tag names. The default regular expression is: - -```plaintext -^v?(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<pre>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<meta>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ -``` - -This regular expression is based on the official -[semantic versioning](https://semver.org/) regular expression, and also includes -support for tag names that start with the letter `v`. - -If your project uses a different format for tags, you can specify a different -regular expression. The regular expression used _must_ produce the following -capture groups. If any of these capture groups are missing, the tag is ignored: - -- `major` -- `minor` -- `patch` - -The following capture groups are optional: - -- `pre`: If set, the tag is ignored. Ignoring `pre` tags ensures release candidate - tags and other pre-release tags are not considered when determining the range of - commits to generate a changelog for. -- `meta`: Optional. Specifies build metadata. - -Using this information, GitLab builds a map of Git tags and their release -versions. It then determines what the latest tag is, based on the version -extracted from each tag. - -To specify a custom regular expression, use the `tag_regex` setting in your -changelog configuration YAML file. For example, this pattern matches tag names -such as `version-1.2.3` but not `version-1.2`. - -```yaml ---- -tag_regex: '^version-(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)$' -``` - -To test if your regular expression is working, you can use websites such as -[regex101](https://regex101.com/). If the regular expression syntax is invalid, -an error is produced when generating a changelog. - ## Generate changelog data > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345934) in GitLab 14.6. @@ -752,3 +443,8 @@ Example Response: "notes": "## 1.0.0 (2021-11-17)\n\n### feature (2 changes)\n\n- [Title 2](namespace13/project13@ad608eb642124f5b3944ac0ac772fecaf570a6bf) ([merge request](namespace13/project13!2))\n- [Title 1](namespace13/project13@3c6b80ff7034fa0d585314e1571cc780596ce3c8) ([merge request](namespace13/project13!1))\n" } ``` + +## Related topics + +- User documentation for [changelogs](../user/project/changelog.md) +- Developer documentation for [changelog entries](../development/changelog.md) in GitLab. diff --git a/doc/development/adding_service_component.md b/doc/development/adding_service_component.md index 9b6171be9fa..314065ffc10 100644 --- a/doc/development/adding_service_component.md +++ b/doc/development/adding_service_component.md @@ -10,7 +10,7 @@ The GitLab product is made up of several service components that run as independ ## Integration phases -The following outline re-uses the [maturity metric](https://about.gitlab.com/direction/maturity/) naming as an example of the various phases of integrating a component. These are only loosely coupled to a components actual maturity, and are intended as a guide for implementation order (for example, a component does not need to be enabled by default to be Lovable, and being enabled by default does not on its own cause a component to be Lovable). +The following outline re-uses the [maturity metric](https://about.gitlab.com/direction/maturity/) naming as an example of the various phases of integrating a component. These phases are only loosely coupled to a components actual maturity, and are intended as a guide for implementation order. For example, a component does not need to be enabled by default to be Lovable. Being enabled by default does not on its own cause a component to be Lovable. - Proposed - [Proposing a new component](#proposing-a-new-component) @@ -37,7 +37,8 @@ The general steps for getting any GitLab feature from proposal to release can be ## Integrating a new service with GitLab -Adding a new service follows the same [merge request workflow](contributing/merge_request_workflow.md) as other contributions, and must meet the same [completion criteria](contributing/merge_request_workflow.md#definition-of-done) and in addition needs to cover the following: +Adding a new service follows the same [merge request workflow](contributing/merge_request_workflow.md) as other contributions, and must meet the same [completion criteria](contributing/merge_request_workflow.md#definition-of-done). +In addition, it needs to cover the following: - The [architecture component list](architecture.md#component-list) has been updated to include the service. - Features provided by the component have been accepted into the [GitLab Product Direction](https://about.gitlab.com/direction/). @@ -87,10 +88,10 @@ In addition, any system dependencies used in Omnibus packages or the Cloud Nativ ## Release management -If the service component needs to be updated or released with the monthly GitLab release, then the component should be added to the [release tools automation](https://gitlab.com/gitlab-org/release-tools). This project is maintained by the [Delivery group](https://about.gitlab.com/handbook/engineering/infrastructure/team/delivery/). +If the service component needs to be updated or released with the monthly GitLab release, then it should be added to the [release tools automation](https://gitlab.com/gitlab-org/release-tools). This project is maintained by the [Delivery group](https://about.gitlab.com/handbook/engineering/infrastructure/team/delivery/). -There are different levels of automation available to include a component in GitLab releases. The requirements and process for including a component in a release at these different levels are detailed in the [release documentation](https://gitlab.com/gitlab-org/release/docs/-/tree/master/components). +Different levels of automation are available to include a component in GitLab monthly releases. The requirements and process for including a component in a release at these different levels are detailed in the [release documentation](https://gitlab.com/gitlab-org/release/docs/-/tree/master/components). A list of the projects with releases managed by release tools can be found in the [release tools project directory](https://gitlab.com/gitlab-org/release-tools/-/tree/master/lib/release_tools/project). -For example, during the monthly GitLab release, the desired version of Gitaly, GitLab Workhorse and GitLab Shell need to be synchronized through the various release pipelines. +For example, the desired version of Gitaly, GitLab Workhorse, and GitLab Shell need to be synchronized through the various release pipelines. diff --git a/doc/development/development_processes.md b/doc/development/development_processes.md index e1df3b55d06..c5d60d18419 100644 --- a/doc/development/development_processes.md +++ b/doc/development/development_processes.md @@ -18,7 +18,7 @@ Must-reads: - [Database review guidelines](database_review.md) for reviewing database-related changes and complex SQL queries, and having them reviewed - [Secure coding guidelines](secure_coding_guidelines.md) -- [Pipelines for the GitLab project](pipelines.md) +- [Pipelines for the GitLab project](pipelines/index.md) Complementary reads: diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md index 8a5a993d913..fd511b05770 100644 --- a/doc/development/documentation/index.md +++ b/doc/development/documentation/index.md @@ -37,7 +37,7 @@ Documentation issues and merge requests are part of their respective repositorie ### Branch naming -The [CI pipeline for the main GitLab project](../pipelines.md) is configured to automatically +The [CI pipeline for the main GitLab project](../pipelines/index.md) is configured to automatically run only the jobs that match the type of contribution. If your contribution contains **only** documentation changes, then only documentation-related jobs run, and the pipeline completes much faster than a code contribution. diff --git a/doc/development/feature_development.md b/doc/development/feature_development.md index eb9d01b0d1d..141b24161b4 100644 --- a/doc/development/feature_development.md +++ b/doc/development/feature_development.md @@ -22,7 +22,7 @@ Consult these topics for information on contributing to specific GitLab features - [Software design guides](software_design.md) - [GitLab EventStore](event_store.md) to publish/subscribe to domain events - [GitLab utilities](utilities.md) -- [Newlines style guide](newlines_styleguide.md) +- [Newlines style guide](backend/ruby_style_guide.md#newlines-style-guide) - [Logging](logging.md) - [Dealing with email/mailers](emails.md) - [Kubernetes integration guidelines](kubernetes.md) diff --git a/doc/development/newlines_styleguide.md b/doc/development/newlines_styleguide.md deleted file mode 100644 index 014affa3e04..00000000000 --- a/doc/development/newlines_styleguide.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -redirect_to: 'backend/ruby_style_guide.md#newlines-style-guide' -remove_date: '2022-12-15' ---- - -This document was moved to [another location](backend/ruby_style_guide.md#newlines-style-guide). - -<!-- This redirect file can be deleted after 2022-12-15. --> -<!-- Redirects that point to other docs in the same project expire in three months. --> -<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md deleted file mode 100644 index a4e06e98d14..00000000000 --- a/doc/development/pipelines.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -redirect_to: 'pipelines/index.md' -remove_date: '2023-01-20' ---- - -This document was moved to [another location](pipelines/index.md). - -<!-- This redirect file can be deleted after <2023-01-20>. --> -<!-- Redirects that point to other docs in the same project expire in three months. --> -<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> diff --git a/doc/topics/application_development_platform/index.md b/doc/topics/application_development_platform/index.md deleted file mode 100644 index 524ba2aaf6d..00000000000 --- a/doc/topics/application_development_platform/index.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -redirect_to: '../../user/infrastructure/index.md' -remove_date: '2022-12-08' ---- - -This document was moved to [another location](../../user/infrastructure/index.md). - -<!-- This redirect file can be deleted after <2022-12-08>. --> -<!-- Redirects that point to other docs in the same project expire in three months. --> -<!-- Redirects that point to docs in a different project or site (link is not relative and starts with `https:`) expire in one year. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> diff --git a/doc/update/index.md b/doc/update/index.md index 0b7d62225a2..b1d72183582 100644 --- a/doc/update/index.md +++ b/doc/update/index.md @@ -295,7 +295,7 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap the `EnsureWorkItemTypeBackfillMigrationFinished` post-deploy migration. - GitLab 15.4.0 introduced a [batched background migration](background_migrations.md#batched-background-migrations) to [backfill `namespace_id` values on issues table](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91921). This - migration might take multiple hours or days to complete on larger GitLab instances. Please make sure the migration + migration might take multiple hours or days to complete on larger GitLab instances. Make sure the migration has completed successfully before upgrading to 15.7.0. - A database constraint is added, specifying that the `namespace_id` column on the issues table has no `NULL` values. @@ -406,7 +406,7 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706) `/etc/gitlab/gitlab.rb`, make sure `/etc/gitlab/gitlab-secrets.json` is the same on all nodes. - GitLab 15.4.0 introduced a [batched background migration](background_migrations.md#batched-background-migrations) to [backfill `namespace_id` values on issues table](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91921). This - migration might take multiple hours or days to complete on larger GitLab instances. Please make sure the migration + migration might take multiple hours or days to complete on larger GitLab instances. Make sure the migration has completed successfully before upgrading to 15.7.0 or later. ### 15.3.4 @@ -489,7 +489,7 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706) fork/exec /var/opt/gitlab/gitaly/run/gitaly-<nnnn>/gitaly-git2go-v15: permission denied ``` - To resolve this, remove the `noexec` option from the filesystem mount. An alternative is to change the Gitaly runtime directory: + To resolve this, remove the `noexec` option from the file system mount. An alternative is to change the Gitaly runtime directory: 1. Add `gitaly['runtime_dir'] = '<PATH_WITH_EXEC_PERM>'` to `/etc/gitlab/gitlab.rb` and specify a location without `noexec` set. 1. Run `sudo gitlab-ctl reconfigure`. @@ -830,7 +830,7 @@ for how to proceed. ``` NOTE: - The queued jobs can be monitored using Sidekiq's admin panel, which can be accessed at the `/admin/sidekiq` endpoint URI. + The queued jobs can be monitored using the Sidekiq admin panel, which can be accessed at the `/admin/sidekiq` endpoint URI. - Using a Rails process to run jobs synchronously: diff --git a/doc/user/admin_area/settings/sign_in_restrictions.md b/doc/user/admin_area/settings/sign_in_restrictions.md index d663238a88c..82a54787101 100644 --- a/doc/user/admin_area/settings/sign_in_restrictions.md +++ b/doc/user/admin_area/settings/sign_in_restrictions.md @@ -149,7 +149,7 @@ period in hours. > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218457) in GitLab 13.2. When enabled, GitLab notifies users of sign-ins from unknown IP addresses or devices. For more information, -see [Email notification for unknown sign-ins](../../profile/unknown_sign_in_notification.md). +see [Email notification for unknown sign-ins](../../profile/notifications.md#notifications-for-unknown-sign-ins).  diff --git a/doc/user/application_security/vulnerabilities/index.md b/doc/user/application_security/vulnerabilities/index.md index 22ef3ed8a1b..67a1257799b 100644 --- a/doc/user/application_security/vulnerabilities/index.md +++ b/doc/user/application_security/vulnerabilities/index.md @@ -213,8 +213,8 @@ Security training uses content from third-party vendors. You must have an intern The vulnerability page may include a training link relevant to the detected vulnerability if security training is enabled. The availability of training depends on whether the enabled training vendor has content matching the particular vulnerability. Training content is requested based on the [vulnerability identifiers](../../../development/integrations/secure.md#identifiers). -The identifier given to a vulnerability will vary from one vulnerability to the next. The available training -content varies between vendors. This means some vulnerabilities will display no training content. +The identifier given to a vulnerability varies from one vulnerability to the next. The available training +content varies between vendors. This means some vulnerabilities do not display training content. Vulnerabilities with a CWE are most likely to return a training result. To view the security training for a vulnerability: diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md index c62999100c1..ba5fddc9faf 100644 --- a/doc/user/packages/npm_registry/index.md +++ b/doc/user/packages/npm_registry/index.md @@ -25,7 +25,7 @@ Create a token and save it to use later in the process. ### Naming convention -Depending on how the package will be installed, you may need to adhere to the naming convention. +Depending on how the package is installed, you may need to adhere to the naming convention. You can use one of two API endpoints to install packages: @@ -36,7 +36,7 @@ If you plan to install a package through the [project level](#install-from-the-p If you plan to install a package through the [instance level](#install-from-the-instance-level), then you must name your package with a [scope](https://docs.npmjs.com/misc/scope/). Scoped packages begin with a `@` have the format of `@owner/package-name`. You can set up the scope for your package in the `.npmrc` file and by using the `publishConfig` option in the `package.json`. -- The value used for the `@scope` is the root of the project that will host the packages and not the root +- The value used for the `@scope` is the root of the project that is hosting the packages and not the root of the project with the source code of the package itself. The scope should be lowercase. - The package name can be anything you want @@ -64,7 +64,7 @@ Create or edit the `.npmrc` file in the same directory as your `package.json`. I - Replace `@scope` with the [root level group](#naming-convention) of the project you're publishing to the package to. - Replace `your_domain_name` with your domain name, for example, `gitlab.com`. - Replace `your_project_id` is your project ID, found on the project's home page. -- `"${NPM_TOKEN}"` will be associated with the token you created later in the process. +- `"${NPM_TOKEN}"` is associated with the token you created later in the process. WARNING: Never hardcode GitLab tokens (or any tokens) directly in `.npmrc` files or any other files that can @@ -125,11 +125,11 @@ You can install a package from a GitLab project or instance: ### Install from the instance level WARNING: -In order to install a package from the instance level, the package must have been published following the scoped [naming convention](#naming-convention). +To install a package from the instance level, the package must have been published following the scoped [naming convention](#naming-convention). 1. Authenticate to the Package Registry - If you would like to install a package from a private project, you will need to authenticate to the Package Registry. Skip this step if the project is not private. + If you would like to install a package from a private project, you would have to authenticate to the Package Registry. Skip this step if the project is not private. ```shell npm config set -- //your_domain_name/api/v4/packages/npm/:_authToken=your_token @@ -158,7 +158,7 @@ In order to install a package from the instance level, the package must have bee 1. Authenticate to the Package Registry - If you would like to install a package from a private project, you will need to authenticate to the Package Registry. Skip this step if the project is not private. + If you would like to install a package from a private project, you would have to authenticate to the Package Registry. Skip this step if the project is not private. ```shell npm config set -- //your_domain_name/api/v4/projects/your_project_id/packages/npm/:_authToken=your_token @@ -317,7 +317,7 @@ Make sure that your `package.json` file does not exceed `20,000` characters. ### `npm publish` returns `npm ERR! 500 Internal Server Error - PUT` -This is a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/238950) in GitLab 13.3.x and later. The error in the logs will appear as: +This is a [known issue](https://gitlab.com/gitlab-org/gitlab/-/issues/238950) in GitLab 13.3.x and later. The error in the logs appears as: ```plaintext >NoMethodError - undefined method `preferred_language' for #<Rack::Response diff --git a/doc/user/profile/unknown_sign_in_notification.md b/doc/user/profile/unknown_sign_in_notification.md deleted file mode 100644 index 3bdcd36a34e..00000000000 --- a/doc/user/profile/unknown_sign_in_notification.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -redirect_to: 'notifications.md' -remove_date: '2023-01-15' ---- - -This document was moved to [another location](notifications.md). - -<!-- This redirect file can be deleted after <2023-01-15>. --> -<!-- Redirects that point to other docs in the same project expire in three months. --> -<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. --> -<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html --> diff --git a/doc/user/project/changelog.md b/doc/user/project/changelog.md new file mode 100644 index 00000000000..a64edd053b1 --- /dev/null +++ b/doc/user/project/changelog.md @@ -0,0 +1,317 @@ +--- +stage: Create +group: Source Code +info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments" +type: reference, api +--- + +# Changelogs + +Changelogs are generated based on commit titles and Git trailers. To be included +in a changelog, a commit must contain a specific Git trailer. Changelogs are generated +from commit titles, and categorized by Git trailer type. You can enrich changelog entries +with additional data, such as a link to the merge request or details about the +commit author. Changelog formats [can be customized](#customize-the-changelog-output) with a template. + +Each section in the default changelog has a title containing the version +number and release date, like this: + +````markdown +## 1.0.0 (2021-01-05) + +### Features (4 changes) + +- [Feature 1](gitlab-org/gitlab@123abc) by @alice ([merge request](gitlab-org/gitlab!123)) +- [Feature 2](gitlab-org/gitlab@456abc) ([merge request](gitlab-org/gitlab!456)) +- [Feature 3](gitlab-org/gitlab@234abc) by @steve +- [Feature 4](gitlab-org/gitlab@456) +```` + +The date format for sections can be customized, but the rest of the title cannot. +When adding new sections, GitLab parses these titles to determine where to place +the new information in the file. GitLab sorts sections according to their versions, +not their dates. + +Each section contains changes sorted by category (like **Features**), and the format +of these sections can be changed. The section names derive from the values of the +Git trailer used to include or exclude commits. + +Commits for changelogs can be retrieved when operating on a mirror. GitLab itself +uses this feature, because security releases can include changes from both public +projects and private security mirrors. + +## Add a trailer to a Git commit + +You can add trailers manually when you write a commit message. To include a commit +using the default trailer of `Changelog` and categorize it as a feature, add the +string `Changelog: feature` to your commit message, like this: + +```plaintext +<Commit message subject> + +<Commit message description> + +Changelog: feature +``` + +## Create a changelog + +To generate changelog data based on commits in a repository, see +[Add changelog data to a changelog file](../../api/repositories.md#add-changelog-data-to-a-changelog-file) +in the API documentation. + +The changelog output is formatted in Markdown, and [you can customize it](#customize-the-changelog-output). + +### Reverted commits + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55537) in GitLab 13.10. + +To be treated as a revert commit, the commit message must contain the string +`This reverts commit <SHA>`, where `SHA` is the SHA of the commit to be reverted. + +When generating a changelog for a range, GitLab ignores commits both added and +reverted in that range. In this example, commit C reverts commit B. Because +commit C has no other trailer, only commit A is added to the changelog: + +```mermaid +graph LR + A[Commit A<br>Changelog: changed] --> B[Commit B<br>Changelog: changed] + B --> C[Commit C<br>Reverts commit B] +``` + +However, if the revert commit (commit C) _also_ contains a changelog trailer, +both commits A and C are included in the changelog: + +```mermaid +graph LR + A[Commit A<br><br>Changelog: changed] --> B[Commit B<br><br>Changelog: changed] + B --> C[Commit C<br>Reverts commit B<br>Changelog: changed] +``` + +Commit B is skipped. + +### Customize the changelog output + +To customize the changelog output, edit the changelog configuration file. The default +location for this configuration is `.gitlab/changelog_config.yml`. The file supports +these variables: + +- `date_format`: The date format, in `strftime` format, used in the title of the newly added changelog data. +- `template`: A custom template to use when generating the changelog data. +- `include_groups`: A list of group full paths containing users whose contributions + should be credited regardless of project membership. The user generating the changelog + must have access to each group for credit to be given. +- `categories`: A hash that maps raw category names to the names to use in the changelog. + To alter the names displayed in the changelog, add these lines to your configuration file + and edit them to meet your needs. This example renders the category titles as + `### Features`, `### Bug fixes`, and `### Performance improvements`: + + ```yaml + --- + categories: + feature: Features + bug: Bug fixes + performance: Performance improvements + ``` + +### Custom templates + +Category sections are generated using a template. The default template: + +```plaintext +{% if categories %} +{% each categories %} +### {{ title }} ({% if single_change %}1 change{% else %}{{ count }} changes{% end %}) + +{% each entries %} +- [{{ title }}]({{ commit.reference }})\ +{% if author.credit %} by {{ author.reference }}{% end %}\ +{% if merge_request %} ([merge request]({{ merge_request.reference }})){% end %} + +{% end %} + +{% end %} +{% else %} +No changes. +{% end %} +``` + +The `{% ... %}` tags are for statements, and `{{ ... }}` is used for printing +data. Statements must be terminated using a `{% end %}` tag. Both the `if` and +`each` statements require a single argument. + +For example, for a variable called `valid`, you can display "yes" +when this value is true, and display "nope" otherwise by doing the following: + +```plaintext +{% if valid %} +yes +{% else %} +nope +{% end %} +``` + +The use of `else` is optional. A value is considered true when it's a non-empty +value or boolean `true`. Empty arrays and hashes are considered false. + +Looping is done using `each`, and variables inside a loop are scoped to it. +Referring to the current value in a loop is done using the variable tag +`{{ it }}`. Other variables read their value from the current loop value. Take +this template for example: + +```plaintext +{% each users %} +{{name}} +{% end %} +``` + +Assuming `users` is an array of objects, each with a `name` field, this would +then print the name of every user. + +Using variable tags, you can access nested objects. For example, +`{{ users.0.name }}` prints the name of the first user in the `users` variable. + +If a line ends in a backslash, the next newline is ignored. This allows you to +wrap code across multiple lines, without introducing unnecessary newlines in the +Markdown output. + +Tags that use `{%` and `%}` (known as expression tags) consume the newline that +directly follows them, if any. This means that this: + +```plaintext +--- +{% if foo %} +bar +{% end %} +--- +``` + +Compiles into this: + +```plaintext +--- +bar +--- +``` + +Instead of this: + +```plaintext +--- + +bar + +--- +``` + +You can specify a custom template in your configuration, like this: + +```yaml +--- +template: | + {% if categories %} + {% each categories %} + ### {{ title }} + + {% each entries %} + - [{{ title }}]({{ commit.reference }})\ + {% if author.credit %} by {{ author.reference }}{% end %} + + {% end %} + + {% end %} + {% else %} + No changes. + {% end %} +``` + +When specifying the template you should use `template: |` and not +`template: >`, as the latter doesn't preserve newlines in the template. + +### Template data + +At the top level, the following variable is available: + +- `categories`: an array of objects, one for every changelog category. + +In a category, the following variables are available: + +- `count`: the number of entries in this category. +- `entries`: the entries that belong to this category. +- `single_change`: a boolean that indicates if there is only one change (`true`), + or multiple changes (`false`). +- `title`: the title of the category (after it has been remapped). + +In an entry, the following variables are available (here `foo.bar` means that +`bar` is a sub-field of `foo`): + +- `author.contributor`: a boolean set to `true` when the author is not a project + member, otherwise `false`. +- `author.credit`: a boolean set to `true` when `author.contributor` is `true` or + when `include_groups` is configured, and the author is a member of one of the + groups. +- `author.reference`: a reference to the commit author (for example, `@alice`). +- `commit.reference`: a reference to the commit, for example, + `gitlab-org/gitlab@0a4cdd86ab31748ba6dac0f69a8653f206e5cfc7`. +- `commit.trailers`: an object containing all the Git trailers that were present + in the commit body. +- `merge_request.reference`: a reference to the merge request that first + introduced the change (for example, `gitlab-org/gitlab!50063`). +- `title`: the title of the changelog entry (this is the commit title). + +The `author` and `merge_request` objects might not be present if the data +couldn't be determined. For example, when a commit is created without a +corresponding merge request, no merge request is displayed. + +### Customize the tag format when extracting versions + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56889) in GitLab 13.11. + +GitLab uses a regular expression (using the +[re2](https://github.com/google/re2/) engine and syntax) to extract a semantic +version from tag names. The default regular expression is: + +```plaintext +^v?(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<pre>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<meta>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$ +``` + +This regular expression is based on the official +[semantic versioning](https://semver.org/) regular expression, and also includes +support for tag names that start with the letter `v`. + +If your project uses a different format for tags, you can specify a different +regular expression. The regular expression used _must_ produce the following +capture groups. If any of these capture groups are missing, the tag is ignored: + +- `major` +- `minor` +- `patch` + +The following capture groups are optional: + +- `pre`: If set, the tag is ignored. Ignoring `pre` tags ensures release candidate + tags and other pre-release tags are not considered when determining the range of + commits to generate a changelog for. +- `meta`: Optional. Specifies build metadata. + +Using this information, GitLab builds a map of Git tags and their release +versions. It then determines what the latest tag is, based on the version +extracted from each tag. + +To specify a custom regular expression, use the `tag_regex` setting in your +changelog configuration YAML file. For example, this pattern matches tag names +such as `version-1.2.3` but not `version-1.2`. + +```yaml +--- +tag_regex: '^version-(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)$' +``` + +To test if your regular expression is working, you can use websites such as +[regex101](https://regex101.com/). If the regular expression syntax is invalid, +an error is produced when generating a changelog. + +## Related topics + +- [Changelog-related endpoints](../../api/repositories.md) in the Repositories API. +- Developer documentation for [changelog entries](../../development/changelog.md) in GitLab. diff --git a/doc/user/project/import/phabricator.md b/doc/user/project/import/phabricator.md index 09e7543bc4a..8a2dbba1343 100644 --- a/doc/user/project/import/phabricator.md +++ b/doc/user/project/import/phabricator.md @@ -36,7 +36,7 @@ Only the following basic fields are imported: The assignee and author of a user are deducted from a Task's owner and author: If a user with the same username has access to the namespace -of the project being imported into, then the user will be linked. +of the project being imported into, then the user is linked. ## Enable this feature diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index cc4682f2d9d..3d971af5c2a 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -289,7 +289,7 @@ To view the table: 1. Each [failing webhook](#failing-webhooks) has a badge listing it as: - **Failed to connect** if it is misconfigured, and needs manual intervention to re-enable it. - - **Fails to connect** if it is temporarily disabled and will retry later. + - **Fails to connect** if it is temporarily disabled and is retrying later.  @@ -336,9 +336,9 @@ GitLab expects a response in [10 seconds](../../../user/gitlab_com/index.md#othe > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365535) in GitLab 15.7. Feature flag `webhooks_failed_callout` removed. If a webhook is failing, a banner displays at the top of the edit page explaining -why it is disabled, and when it will be automatically re-enabled. For example: +why it is disabled, and when it is automatically re-enabled. For example: - + In the case of a failed webhook, an error banner is displayed: diff --git a/doc/user/project/merge_requests/commit_templates.md b/doc/user/project/merge_requests/commit_templates.md index a14d8bddd24..f8c24e4067b 100644 --- a/doc/user/project/merge_requests/commit_templates.md +++ b/doc/user/project/merge_requests/commit_templates.md @@ -89,7 +89,7 @@ Commit message templates support these variables: | `%{approved_by}` | Line-separated list of the merge request approvers in a `Approved-by` Git commit trailer format. | `Approved-by: Sidney Jones <sjones@example.com>` <br> `Approved-by: Zhang Wei <zwei@example.com>` | | `%{merged_by}` | User who merged the merge request. | `Alex Garcia <agarcia@example.com>` | | `%{co_authored_by}` | Names and emails of commit authors in a `Co-authored-by` Git commit trailer format. Limited to authors of 100 most recent commits in merge request. | `Co-authored-by: Zane Doe <zdoe@example.com>` <br> `Co-authored-by: Blake Smith <bsmith@example.com>` | -| `%{all_commits}` | Messages from all commits in the merge request. Limited to 100 most recent commits. Skips commit bodies exceeding 100KiB and merge commit messages. | `* Feature introduced` <br><br> `This commit implements feature` <br> `Changelog:added` <br><br> `* Bug fixed` <br><br> `* Documentation improved` <br><br>`This commit introduced better docs.`| +| `%{all_commits}` | Messages from all commits in the merge request. Limited to 100 most recent commits. Skips commit bodies exceeding 100 KiB and merge commit messages. | `* Feature introduced` <br><br> `This commit implements feature` <br> `Changelog:added` <br><br> `* Bug fixed` <br><br> `* Documentation improved` <br><br>`This commit introduced better docs.`| Any line containing only an empty variable is removed. If the line to be removed is both preceded and followed by an empty line, the preceding empty line is also removed. diff --git a/doc/user/project/service_desk.md b/doc/user/project/service_desk.md index 14f82c7c68c..cbc64fe2368 100644 --- a/doc/user/project/service_desk.md +++ b/doc/user/project/service_desk.md @@ -67,7 +67,7 @@ one from the selector menu to append it to all Service Desk issues. To enable Service Desk in your project: 1. (GitLab self-managed only) [Set up incoming email](../../administration/incoming_email.md#set-it-up) for the GitLab instance. - We recommend using [email sub-addressing](../../administration/incoming_email.md#email-sub-addressing), + You should use [email sub-addressing](../../administration/incoming_email.md#email-sub-addressing), but you can also use [catch-all mailboxes](../../administration/incoming_email.md#catch-all-mailbox). 1. In a project, in the left sidebar, go to **Settings > General** and expand the **Service Desk** section. 1. Enable the **Activate Service Desk** toggle. This reveals a unique email address to email issues @@ -154,7 +154,7 @@ You can set description templates at various levels: - A specific [group or subgroup](description_templates.md#set-group-level-description-templates). - A specific [project](description_templates.md#set-a-default-template-for-merge-requests-and-issues). -The templates are inherited. For example, in a project, you can also access templates set for the instance or the project's parent groups. +The templates are inherited. For example, in a project, you can also access templates set for the instance, or the project's parent groups. To use a custom description template with Service Desk: @@ -266,7 +266,7 @@ The configuration options are the same as for configuring > - Alternative Azure deployments [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/5978) in GitLab 14.9. Service Desk can be configured to read Microsoft Exchange Online mailboxes with the Microsoft -Graph API instead of IMAP. Follow the [documentation in the incoming email section for setting up an OAuth2 application for Microsoft Graph](../../administration/incoming_email.md#microsoft-graph). +Graph API instead of IMAP. Follow the [documentation in the incoming email section for setting up an OAuth 2.0 application for Microsoft Graph](../../administration/incoming_email.md#microsoft-graph). - Example for Omnibus GitLab installations: diff --git a/doc/user/read_only_namespaces.md b/doc/user/read_only_namespaces.md index 345a3a87189..63d7f18f70c 100644 --- a/doc/user/read_only_namespaces.md +++ b/doc/user/read_only_namespaces.md @@ -19,7 +19,7 @@ information, see [Restricted actions](#restricted-actions). ## Remove the read-only state -To restore a namespace to its normal state, you can: +To restore a namespace to its standard state, you can: - For exceeded free user limits: - [Reduce the number of members](free_user_limit.md#manage-members-in-your-namespace) in your namespace. diff --git a/doc/user/search/index.md b/doc/user/search/index.md index 9536f7fe40a..e5b802eed4f 100644 --- a/doc/user/search/index.md +++ b/doc/user/search/index.md @@ -113,7 +113,7 @@ You can filter issues and merge requests by specific terms included in titles or issues for `included in titles` is same as `included titles` - Search is limited to 4096 characters and 64 terms per query. - When searching issues, partial matches are not allowed. For example: searching for `play` will - not return issues that have the word `display`. But variations of words will still match, so searching + not return issues that have the word `display`. But variations of words match, so searching for `displays` also returns issues that have the word `display`. ## Retrieve search results as feed diff --git a/lib/backup/manager.rb b/lib/backup/manager.rb index a7dddcf8619..ba4a26ba714 100644 --- a/lib/backup/manager.rb +++ b/lib/backup/manager.rb @@ -183,8 +183,8 @@ module Backup end def build_repositories_task - max_concurrency = ENV['GITLAB_BACKUP_MAX_CONCURRENCY'].presence - max_storage_concurrency = ENV['GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY'].presence + max_concurrency = ENV['GITLAB_BACKUP_MAX_CONCURRENCY'].presence&.to_i + max_storage_concurrency = ENV['GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY'].presence&.to_i strategy = Backup::GitalyBackup.new(progress, incremental: incremental?, max_parallelism: max_concurrency, storage_parallelism: max_storage_concurrency) Repositories.new(progress, diff --git a/lib/gitlab/environment.rb b/lib/gitlab/environment.rb index b1a9603d3a5..86094727df5 100644 --- a/lib/gitlab/environment.rb +++ b/lib/gitlab/environment.rb @@ -5,5 +5,18 @@ module Gitlab def self.hostname @hostname ||= ENV['HOSTNAME'] || Socket.gethostname end + + # Check whether codebase is going through static verification + # in order to skip executing parts of the codebase + # + # @return [Boolean] Is the code going through static verification? + def self.static_verification? + static_verification = Gitlab::Utils.to_boolean(ENV['STATIC_VERIFICATION'], default: false) + env_production = ENV['RAILS_ENV'] == 'production' + + warn '[WARNING] Static Verification bypass is enabled in Production.' if static_verification && env_production + + static_verification + end end end diff --git a/lib/gitlab/patch/prependable.rb b/lib/gitlab/patch/prependable.rb index b974c0b2c7f..7619fc317a1 100644 --- a/lib/gitlab/patch/prependable.rb +++ b/lib/gitlab/patch/prependable.rb @@ -8,6 +8,7 @@ # 2. Allow `prepended do; end` work like `included do; end` # If we don't need anything above, we don't need this patch nor the concern! +require_dependency 'gitlab/environment' # rubocop:disable Gitlab/ModuleWithInstanceVariables module Gitlab module Patch @@ -51,7 +52,7 @@ module Gitlab end # Hack to resolve https://gitlab.com/gitlab-org/gitlab/-/issues/23932 - extend class_methods_module if ENV['STATIC_VERIFICATION'] + extend class_methods_module if Gitlab::Environment.static_verification? end def prepended(base = nil, &block) diff --git a/lib/gitlab/utils/delegator_override.rb b/lib/gitlab/utils/delegator_override.rb index 15ba29d3916..3478931b170 100644 --- a/lib/gitlab/utils/delegator_override.rb +++ b/lib/gitlab/utils/delegator_override.rb @@ -6,7 +6,7 @@ module Gitlab # accidentally override important logic on the fabricated object. module DelegatorOverride def delegator_target(target_class) - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? unless self < ::SimpleDelegator raise ArgumentError, "'#{self}' is not a subclass of 'SimpleDelegator' class." @@ -16,14 +16,14 @@ module Gitlab end def delegator_override(*names) - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? raise TypeError unless names.all? { |n| n.is_a?(Symbol) } DelegatorOverride.validator(self).add_allowlist(names) end def delegator_override_with(mod) - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? raise TypeError unless mod.is_a?(Module) DelegatorOverride.validator(self).add_allowlist(mod.instance_methods) diff --git a/lib/gitlab/utils/override.rb b/lib/gitlab/utils/override.rb index f83ebba7c3f..7f43e25e50d 100644 --- a/lib/gitlab/utils/override.rb +++ b/lib/gitlab/utils/override.rb @@ -1,6 +1,7 @@ # frozen_string_literal: true require_dependency 'gitlab/utils' +require_dependency 'gitlab/environment' module Gitlab module Utils @@ -117,7 +118,7 @@ module Gitlab # This would make sure we're overriding something. See: # https://gitlab.com/gitlab-org/gitlab/issues/1819 def override(method_name) - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? Override.extensions[self] ||= Extension.new(self) Override.extensions[self].add_method_name(method_name) @@ -126,7 +127,7 @@ module Gitlab def method_added(method_name) super - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? return unless Override.extensions[self]&.verify_override?(method_name) method_arity = instance_method(method_name).arity @@ -163,7 +164,7 @@ module Gitlab end def queue_verification(base, verify: false) - return unless ENV['STATIC_VERIFICATION'] + return unless Gitlab::Environment.static_verification? # We could check for Class in `override` # This could be `nil` if `override` was never called. diff --git a/spec/lib/gitlab/logger_spec.rb b/spec/lib/gitlab/logger_spec.rb index ed22af8355f..9f11f3ac629 100644 --- a/spec/lib/gitlab/logger_spec.rb +++ b/spec/lib/gitlab/logger_spec.rb @@ -2,7 +2,7 @@ require 'spec_helper' -RSpec.describe Gitlab::Logger do +RSpec.describe Gitlab::Logger, feature_category: :logging do describe '.build' do before do allow(described_class).to receive(:file_name_noext).and_return('log') @@ -25,40 +25,28 @@ RSpec.describe Gitlab::Logger do using RSpec::Parameterized::TableSyntax where(:env_value, :resulting_level) do - 0 | described_class::DEBUG - :debug | described_class::DEBUG 'debug' | described_class::DEBUG 'DEBUG' | described_class::DEBUG 'DeBuG' | described_class::DEBUG - 1 | described_class::INFO - :info | described_class::INFO 'info' | described_class::INFO 'INFO' | described_class::INFO 'InFo' | described_class::INFO - 2 | described_class::WARN - :warn | described_class::WARN 'warn' | described_class::WARN 'WARN' | described_class::WARN 'WaRn' | described_class::WARN - 3 | described_class::ERROR - :error | described_class::ERROR 'error' | described_class::ERROR 'ERROR' | described_class::ERROR 'ErRoR' | described_class::ERROR - 4 | described_class::FATAL - :fatal | described_class::FATAL 'fatal' | described_class::FATAL 'FATAL' | described_class::FATAL 'FaTaL' | described_class::FATAL - 5 | described_class::UNKNOWN - :unknown | described_class::UNKNOWN 'unknown' | described_class::UNKNOWN 'UNKNOWN' | described_class::UNKNOWN 'UnKnOwN' | described_class::UNKNOWN end with_them do - it 'builds logger if valid log level' do + it 'builds logger if valid log level is provided' do stub_env('GITLAB_LOG_LEVEL', env_value) expect(subject.level).to eq(resulting_level) @@ -69,15 +57,15 @@ RSpec.describe Gitlab::Logger do describe '.log_level' do context 'if GITLAB_LOG_LEVEL is set' do before do - stub_env('GITLAB_LOG_LEVEL', described_class::ERROR) + stub_env('GITLAB_LOG_LEVEL', 'error') end - it 'returns value of GITLAB_LOG_LEVEL' do - expect(described_class.log_level).to eq(described_class::ERROR) + it 'returns value defined by GITLAB_LOG_LEVEL' do + expect(described_class.log_level).to eq('error') end it 'ignores fallback' do - expect(described_class.log_level(fallback: described_class::FATAL)).to eq(described_class::ERROR) + expect(described_class.log_level(fallback: described_class::FATAL)).to eq('error') end end diff --git a/spec/migrations/20230112141236_schedule_vulnerabilities_feedback_migration2_spec.rb b/spec/migrations/20230112141236_schedule_vulnerabilities_feedback_migration2_spec.rb new file mode 100644 index 00000000000..0e0f08fea0e --- /dev/null +++ b/spec/migrations/20230112141236_schedule_vulnerabilities_feedback_migration2_spec.rb @@ -0,0 +1,31 @@ +# frozen_string_literal: true + +require 'spec_helper' +require_migration! + +RSpec.describe ScheduleVulnerabilitiesFeedbackMigration2, feature_category: :vulnerability_management do + let(:migration) { described_class::MIGRATION } + + describe '#up' do + it 'schedules background jobs for each batch of Vulnerabilities::Feedback' do + migrate! + + expect(migration).to have_scheduled_batched_migration( + table_name: :vulnerability_feedback, + column_name: :id, + interval: described_class::DELAY_INTERVAL, + batch_size: described_class::BATCH_SIZE, + max_batch_size: described_class::MAX_BATCH_SIZE + ) + end + end + + describe '#down' do + it 'deletes all batched migration records' do + migrate! + schema_migrate_down! + + expect(migration).not_to have_scheduled_batched_migration + end + end +end diff --git a/spec/support/helpers/stub_env.rb b/spec/support/helpers/stub_env.rb index 5f344f8fb52..afa501d6279 100644 --- a/spec/support/helpers/stub_env.rb +++ b/spec/support/helpers/stub_env.rb @@ -2,13 +2,23 @@ # Inspired by https://github.com/ljkbennett/stub_env/blob/master/lib/stub_env/helpers.rb module StubENV + # Stub ENV variables + # + # You can provide either a key and value as separate params or both in a Hash format + # + # Keys and values will always be converted to String, to comply with how ENV behaves + # + # @param key_or_hash [String, Hash<String,String>] + # @param value [String] def stub_env(key_or_hash, value = nil) init_stub unless env_stubbed? if key_or_hash.is_a? Hash - key_or_hash.each { |k, v| add_stubbed_value(k, v) } + key_or_hash.each do |key, value| + add_stubbed_value(key, ensure_env_type(value)) + end else - add_stubbed_value key_or_hash, value + add_stubbed_value key_or_hash, ensure_env_type(value) end end @@ -35,4 +45,8 @@ module StubENV allow(ENV).to receive(:fetch).and_call_original add_stubbed_value(STUBBED_KEY, true) end + + def ensure_env_type(value) + value.nil? ? value : value.to_s + end end diff --git a/spec/tasks/gitlab/backup_rake_spec.rb b/spec/tasks/gitlab/backup_rake_spec.rb index 4aa6edf4789..c0196c09e3c 100644 --- a/spec/tasks/gitlab/backup_rake_spec.rb +++ b/spec/tasks/gitlab/backup_rake_spec.rb @@ -2,7 +2,7 @@ require 'rake_helper' -RSpec.describe 'gitlab:app namespace rake task', :delete, feature_category: :backup_restore do +RSpec.describe 'gitlab:backup namespace rake tasks', :delete, feature_category: :backup_restore do let(:enable_registry) { true } let(:backup_restore_pid_path) { "#{Rails.application.root}/tmp/backup_restore.pid" } let(:backup_tasks) { %w[db repo uploads builds artifacts pages lfs terraform_state registry packages] } |