diff --git a/.gitlab/ci/release-environments/main.gitlab-ci.yml b/.gitlab/ci/release-environments/main.gitlab-ci.yml index d88f1d4d1e9..731de957221 100644 --- a/.gitlab/ci/release-environments/main.gitlab-ci.yml +++ b/.gitlab/ci/release-environments/main.gitlab-ci.yml @@ -57,7 +57,11 @@ release-environments-notification-start: release-environments-deploy: stage: deploy - extends: .inherit_variables + inherit: + variables: false + variables: + VERSIONS: "${VERSIONS}" + ENVIRONMENT: "${ENVIRONMENT}" trigger: project: gitlab-com/gl-infra/release-environments branch: main diff --git a/.rubocop_todo/style/redundant_interpolation.yml b/.rubocop_todo/style/redundant_interpolation.yml index c934d8660d1..e8d6648a55d 100644 --- a/.rubocop_todo/style/redundant_interpolation.yml +++ b/.rubocop_todo/style/redundant_interpolation.yml @@ -15,19 +15,4 @@ Style/RedundantInterpolation: - 'lib/gitlab/repository_cache.rb' - 'lib/gitlab/repository_cache_adapter.rb' - 'lib/gitlab/repository_hash_cache.rb' - - 'lib/gitlab/repository_set_cache.rb' - - 'lib/gitlab/usage_data_counters/search_counter.rb' - - 'lib/kramdown/converter/commonmark.rb' - - 'lib/tasks/gettext.rake' - - 'lib/tasks/gitlab/seed/group_seed.rake' - - 'qa/qa/ee/page/component/secure_report.rb' - - 'qa/qa/ee/page/project/issue/show.rb' - - 'qa/qa/ee/page/project/secure/vulnerability_details.rb' - - 'qa/qa/resource/events/base.rb' - - 'qa/qa/service/praefect_manager.rb' - - 'qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb' - - 'qa/qa/specs/features/ee/browser_ui/3_create/repository/project_templates_spec.rb' - - 'qa/qa/specs/features/ee/browser_ui/4_verify/parent_child_pipelines_dependent_relationship_spec.rb' - - 'qa/qa/tools/generate_perf_testdata.rb' - - 'scripts/perf/gc/print_gc_stats.rb' - - 'scripts/qa/testcases-check' + diff --git a/Gemfile b/Gemfile index defd2096c27..e8e56628136 100644 --- a/Gemfile +++ b/Gemfile @@ -555,7 +555,7 @@ group :test do # Moved in `test` because https://gitlab.com/gitlab-org/gitlab/-/issues/217527 gem 'derailed_benchmarks', require: false # rubocop:todo Gemfile/MissingFeatureCategory - gem 'gitlab_quality-test_tooling', '~> 1.23.0', require: false, feature_category: :tooling + gem 'gitlab_quality-test_tooling', '~> 1.24.0', require: false, feature_category: :tooling end gem 'octokit', '~> 8.1', feature_category: :importers diff --git a/Gemfile.checksum b/Gemfile.checksum index c2c71e8a7a8..7bd6fdf0516 100644 --- a/Gemfile.checksum +++ b/Gemfile.checksum @@ -228,7 +228,7 @@ {"name":"gitlab-styles","version":"11.0.0","platform":"ruby","checksum":"0dd8ec066ce9955ac51d3616c6bfded30f75bb526f39ff392ece6f43d5b9406b"}, {"name":"gitlab_chronic_duration","version":"0.12.0","platform":"ruby","checksum":"0d766944d415b5c831f176871ee8625783fc0c5bfbef2d79a3a616f207ffc16d"}, {"name":"gitlab_omniauth-ldap","version":"2.2.0","platform":"ruby","checksum":"bb4d20acb3b123ed654a8f6a47d3fac673ece7ed0b6992edb92dca14bad2838c"}, -{"name":"gitlab_quality-test_tooling","version":"1.23.0","platform":"ruby","checksum":"96af4e12d8b253d29b24a961a10e2a472c459fb24fa06a5ed97cb5ae4ffdec5d"}, +{"name":"gitlab_quality-test_tooling","version":"1.24.0","platform":"ruby","checksum":"52b8f536943818a633ba9b86fb4a4308ec92013f30007f0371b474e217032fa3"}, {"name":"globalid","version":"1.1.0","platform":"ruby","checksum":"b337e1746f0c8cb0a6c918234b03a1ddeb4966206ce288fbb57779f59b2d154f"}, {"name":"gon","version":"6.4.0","platform":"ruby","checksum":"e3a618d659392890f1aa7db420f17c75fd7d35aeb5f8fe003697d02c4b88d2f0"}, {"name":"google-apis-androidpublisher_v3","version":"0.34.0","platform":"ruby","checksum":"d7e1d7dd92f79c498fe2082222a1740d788e022e660c135564b3fd299cab5425"}, diff --git a/Gemfile.lock b/Gemfile.lock index fad73baad48..ce5b798b226 100644 --- a/Gemfile.lock +++ b/Gemfile.lock @@ -737,7 +737,7 @@ GEM omniauth (>= 1.3, < 3) pyu-ruby-sasl (>= 0.0.3.3, < 0.1) rubyntlm (~> 0.5) - gitlab_quality-test_tooling (1.23.0) + gitlab_quality-test_tooling (1.24.0) activesupport (>= 6.1, < 7.2) amatch (~> 0.4.1) gitlab (~> 4.19) @@ -2027,7 +2027,7 @@ DEPENDENCIES gitlab-utils! gitlab_chronic_duration (~> 0.12) gitlab_omniauth-ldap (~> 2.2.0) - gitlab_quality-test_tooling (~> 1.23.0) + gitlab_quality-test_tooling (~> 1.24.0) gon (~> 6.4.0) google-apis-androidpublisher_v3 (~> 0.34.0) google-apis-cloudbilling_v1 (~> 0.21.0) diff --git a/app/assets/javascripts/profile/components/graphql/get_user_achievements.query.graphql b/app/assets/javascripts/profile/components/graphql/get_user_achievements.query.graphql index dbb4b0bce5e..e60f383ad1c 100644 --- a/app/assets/javascripts/profile/components/graphql/get_user_achievements.query.graphql +++ b/app/assets/javascripts/profile/components/graphql/get_user_achievements.query.graphql @@ -13,7 +13,6 @@ query getUserAchievements($id: UserID!) { namespace { id fullPath - achievementsPath } } } diff --git a/app/assets/javascripts/profile/components/user_achievements.vue b/app/assets/javascripts/profile/components/user_achievements.vue index 50ca3c45b41..6451c18c463 100644 --- a/app/assets/javascripts/profile/components/user_achievements.vue +++ b/app/assets/javascripts/profile/components/user_achievements.vue @@ -5,7 +5,6 @@ import { convertToGraphQLId } from '~/graphql_shared/utils'; import { s__ } from '~/locale'; import { TYPENAME_USER } from '~/graphql_shared/constants'; import timeagoMixin from '~/vue_shared/mixins/timeago'; -import { joinPaths } from '~/lib/utils/url_utility'; import getUserAchievements from './graphql/get_user_achievements.query.graphql'; export const MAX_VISIBLE_ACHIEVEMENTS = 7; @@ -54,7 +53,7 @@ export default { description, namespace: namespace && { fullPath: namespace.fullPath, - webUrl: joinPaths(this.rootUrl, namespace.achievementsPath), + webUrl: this.rootUrl + namespace.fullPath, }, count, }; diff --git a/app/models/ci/bridge.rb b/app/models/ci/bridge.rb index fce3e054d04..7bd626ee260 100644 --- a/app/models/ci/bridge.rb +++ b/app/models/ci/bridge.rb @@ -36,10 +36,6 @@ module Ci end end - event :canceling do - transition CANCELABLE_STATUSES.map(&:to_sym) => :canceling - end - event :pending do transition all => :pending end @@ -55,6 +51,14 @@ module Ci event :actionize do transition created: :manual end + + event :start_cancel do + transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual] => :canceling + end + + event :finish_cancel do + transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual, :canceling] => :canceled + end end def retryable? @@ -83,7 +87,7 @@ module Ci when 'success' success! when 'canceled' - cancel! + finish_cancel! when 'failed', 'skipped' drop! else diff --git a/app/models/ci/pipeline.rb b/app/models/ci/pipeline.rb index 77a0526d630..f76690b32a8 100644 --- a/app/models/ci/pipeline.rb +++ b/app/models/ci/pipeline.rb @@ -228,7 +228,7 @@ module Ci transition any => :success end - event :canceling do + event :start_cancel do transition any - [:canceling, :canceled] => :canceling end @@ -883,7 +883,7 @@ module Ci when 'running' then run when 'success' then succeed when 'failed' then drop - when 'canceling' then canceling + when 'canceling' then start_cancel when 'canceled' then cancel when 'skipped' then skip when 'manual' then block diff --git a/app/models/ci/stage.rb b/app/models/ci/stage.rb index 4e2dd7cc666..202f8fb17a1 100644 --- a/app/models/ci/stage.rb +++ b/app/models/ci/stage.rb @@ -120,7 +120,7 @@ module Ci transition any - [:success] => :success end - event :canceling do + event :start_cancel do transition any - [:canceling, :canceled] => :canceling end @@ -149,7 +149,7 @@ module Ci when 'running' then run when 'success' then succeed when 'failed' then drop - when 'canceling' then canceling + when 'canceling' then start_cancel when 'canceled' then cancel when 'manual' then block when 'scheduled' then delay diff --git a/app/models/commit_status.rb b/app/models/commit_status.rb index a590661fabc..bc79ffdffad 100644 --- a/app/models/commit_status.rb +++ b/app/models/commit_status.rb @@ -176,7 +176,7 @@ class CommitStatus < Ci::ApplicationRecord event :cancel do transition running: :canceling, if: :supports_canceling? - transition [:created, :waiting_for_resource, :preparing, :waiting_for_callback, :pending, :manual, :scheduled, :running] => :canceled + transition CANCELABLE_STATUSES.map(&:to_sym) + [:manual] => :canceled end before_transition [:created, :waiting_for_resource, :preparing, :skipped, :manual, :scheduled] => :pending do |commit_status| diff --git a/app/models/deployment.rb b/app/models/deployment.rb index c781c8ea075..ae5f72529f0 100644 --- a/app/models/deployment.rb +++ b/app/models/deployment.rb @@ -461,6 +461,8 @@ class Deployment < ApplicationRecord succeed! when 'failed' drop! + when 'canceling' + # no-op when 'canceled' cancel! when 'skipped' diff --git a/doc/administration/gitaly/bundle_uri.md b/doc/administration/gitaly/bundle_uri.md new file mode 100644 index 00000000000..0b302341b43 --- /dev/null +++ b/doc/administration/gitaly/bundle_uri.md @@ -0,0 +1,278 @@ +--- +stage: Systems +group: Gitaly +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +--- + +# Bundle URI + +DETAILS: +**Status:** Experiment + +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/8939) in GitLab 17.0 [with a flag](../../administration/feature_flags.md) named `gitaly_bundle_uri`. Disabled by default. + +FLAG: +On self-managed GitLab, by default this feature is not available. +To make it available, an administrator can [enable the feature flag](../feature_flags.md) +named `gitaly_bundle_uri`. +On GitLab.com and GitLab Dedicated, this feature is not available. This feature +is not ready for production use. + +Gitaly supports Git [bundle URIs](https://git-scm.com/docs/bundle-uri). Bundle +URIs are locations where Git can download one or more bundles to bootstrap the +object database before fetching the remaining objects from a remote. Bundle URI +is built in to the Git protocol. + +Using Bundle URI can: + +- Speed up clones and fetches for users with a poor network connection to the + GitLab server. The bundles can be stored on a CDN, making them available + around the world. +- Reduce the load on servers that run CI/CD jobs. If CI/CD jobs can pre-load + bundles from somewhere else, the remaining work to incrementally fetch missing + objects and references creates a lot less load on the server. + +Prerequisites: + +- The Git config [`transfer.bundleURI`](https://git-scm.com/docs/git-config#Documentation/git-config.txt-transferbundleURI) + must be enabled on Git clients. +- GitLab Runner 16.6 or later. + +- In CI/CD pipeline configuration, the + [default Git strategy](../../ci/pipelines/settings.md#choose-the-default-git-strategy) + set to `git clone`. + +## Server configuration + +You must configure where the bundles are stored. Gitaly supports the following +storage services: + +- Google Cloud Storage +- AWS S3 (or compatible) +- Azure Blob Storage +- Local file storage (**not recommended**) + +### Configure Azure Blob storage + +How you configure Azure Blob storage for Bundle URI depends on the type of +installation you have. For self-compiled installations, you must set the +`AZURE_STORAGE_ACCOUNT` and `AZURE_STORAGE_KEY` environment variables outside of +GitLab. + +::Tabs + +:::TabTitle Linux package (Omnibus) + +Edit `/etc/gitlab/gitlab.rb` and configure the `bundle_uri.go_cloud_url`: + +```ruby +gitaly['env'] = { + 'AZURE_STORAGE_ACCOUNT' => 'azure_storage_account', + 'AZURE_STORAGE_KEY' => 'azure_storage_key' # or 'AZURE_STORAGE_SAS_TOKEN' +} +gitaly['configuration'] = { + bundle_uri: { + go_cloud_url: 'azblob://gitaly-bundleuri' + } +} +``` + +:::TabTitle Self-compiled (source) + +Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`: + +```toml +[bundle_uri] +go_cloud_url = "azblob://gitaly-bundleuri" +``` + +::EndTabs + +### Configure Google Cloud storage + +Google Cloud storage (GCP) authenticates using Application Default Credentials. +Set up Application Default Credentials on each Gitaly server using either: + +- The [`gcloud auth application-default login`](https://cloud.google.com/sdk/gcloud/reference/auth/application-default/login) + command. +- The `GOOGLE_APPLICATION_CREDENTIALS` environment variable. For self-compiled + installations, set the environment variable outside of GitLab. + +For more information, see +[Application Default Credentials](https://cloud.google.com/docs/authentication/provide-credentials-adc). + +The destination bucket is configured using the `go_cloud_url` option. + +::Tabs + +:::TabTitle Linux package (Omnibus) + +Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`: + +```ruby +gitaly['env'] = { + 'GOOGLE_APPLICATION_CREDENTIALS' => '/path/to/service.json' +} +gitaly['configuration'] = { + bundle_uri: { + go_cloud_url: 'gs://gitaly-bundleuri' + } +} +``` + +:::TabTitle Self-compiled (source) + +Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`: + +```toml +[bundle_uri] +go_cloud_url = "gs://gitaly-bundle_uri" +``` + +::EndTabs + +### Configure S3 storage + +To configure S3 storage authentication: + +- If you authenticate with the AWS CLI, you can use the default AWS session. +- Otherwise, you can use the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` + environment variables. For self-compiled installations, set the environment + variables outside of GitLab. + +For more information, see +[AWS Session documentation](https://docs.aws.amazon.com/sdk-for-go/api/aws/session/). + +The destination bucket and region are configured using the `go_cloud_url` option. + +::Tabs + +:::TabTitle Linux package (Omnibus) + +Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`: + +```ruby +gitaly['env'] = { + 'AWS_ACCESS_KEY_ID' => 'aws_access_key_id', + 'AWS_SECRET_ACCESS_KEY' => 'aws_secret_access_key' +} +gitaly['configuration'] = { + bundle_uri: { + go_cloud_url: 's3://gitaly-bundle_uri?region=us-west-1' + } +} +``` + +:::TabTitle Self-compiled (source) + +Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`: + +```toml +[bundle_uri] +go_cloud_url = "s3://gitaly-bundle_uri?region=us-west-1" +``` + +::EndTabs + +#### Configure S3-compatible servers + +S3-compatible servers such as MinIO are configured similarly to S3 with the +addition of the `endpoint` parameter. + +The following parameters are supported: + +- `region`: The AWS region. +- `endpoint`: The endpoint URL. +- `disabledSSL`: A value of `true` disables SSL. +- `s3ForcePathStyle`: A value of `true` forces path-style addressing. + +::Tabs + +:::TabTitle Linux package (Omnibus) + +Edit `/etc/gitlab/gitlab.rb` and configure the `go_cloud_url`: + +```ruby +gitaly['env'] = { + 'AWS_ACCESS_KEY_ID' => 'minio_access_key_id', + 'AWS_SECRET_ACCESS_KEY' => 'minio_secret_access_key' +} +gitaly['configuration'] = { + bundle_uri: { + go_cloud_url: 's3://gitaly-bundleuri?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true' + } +} +``` + +:::TabTitle Self-compiled (source) + +Edit `/home/git/gitaly/config.toml` and configure `go_cloud_url`: + +```toml +[bundle_uri] +go_cloud_url = "s3://gitaly-bundleuri?region=minio&endpoint=my.minio.local:8080&disableSSL=true&s3ForcePathStyle=true" +``` + +::EndTabs + +## Generating bundles + +After Gitaly is properly configured, Gitaly can generate bundles, which is a +manual process. To generate a bundle for Bundle URI, run: + +```shell +sudo /opt/gitlab/embedded/bin/gitaly bundle-uri \ + --config= \ + --storage= \ + --repository= +``` + +This command generates the bundle and stores it on the configured storage service. +Gitaly does not automatically refresh the generated bundle, so when want to generate +a more recent version of a bundle, you must the run command again. + +You can schedule this command with a tool like `cron(8)`. + +## Bundle URI example + +In the following example, we demonstrate the difference between cloning +`gitlab.com/gitlab-org/gitlab.git` with and without using bundle URI. + +```shell +$ git -c transfer.bundleURI=false clone https://gitlab.com/gitlab-org/gitlab.git +Cloning into 'gitlab'... +remote: Enumerating objects: 5271177, done. +remote: Total 5271177 (delta 0), reused 0 (delta 0), pack-reused 5271177 +Receiving objects: 100% (5271177/5271177), 1.93 GiB | 32.93 MiB/s, done. +Resolving deltas: 100% (4140349/4140349), done. +Updating files: 100% (71304/71304), done. + +$ git -c transfer.bundleURI=true clone https://gitlab.com/gitlab-org/gitlab.git +Cloning into 'gitlab'... +remote: Enumerating objects: 1322255, done. +remote: Counting objects: 100% (611708/611708), done. +remote: Total 1322255 (delta 611708), reused 611708 (delta 611708), pack-reused 710547 +Receiving objects: 100% (1322255/1322255), 539.66 MiB | 22.98 MiB/s, done. +Resolving deltas: 100% (1026890/1026890), completed with 223946 local objects. +Checking objects: 100% (8388608/8388608), done. +Checking connectivity: 1381139, done. +Updating files: 100% (71304/71304), done. +``` + +In the above example: + +- When not using Bundle URI, there were 5,271,177 objects received from the + GitLab server. +- When using Bundle URL, there were 1,322,255 objects received from the GitLab + server. + +This reduction means GitLab needs to pack together fewer objects (in the above +example, roughly a quarter of the number of objects) because the client first +downloaded the bundle from the storage server. + +## Securing bundles + +The bundles are made accessible to the client using signed URLs. A signed URL is +a URL that provides limited permissions and time to make a request. To see if +your storage service supports sighed URLs, see the documentation of your storage +service. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index c443dbebc6a..caaf1691fa1 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -191,6 +191,11 @@ For more information on the other subcommands, run `gitaly --help`. When backing up or syncing repositories using tools other than GitLab, you must [prevent writes](../../administration/backup_restore/backup_gitlab.md#prevent-writes-and-copy-the-git-repository-data) while copying repository data. +### Bundle URI + +You can use Git [bundle URIs](https://git-scm.com/docs/bundle-uri) with Gitaly. +For more information, see the [Bundle URI documentation](bundle_uri.md). + ## Gitaly Cluster Git storage is provided through the Gitaly service in GitLab, and is essential to the operation of diff --git a/doc/api/projects.md b/doc/api/projects.md index d9e255cb715..b839109cde7 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -1552,7 +1552,7 @@ curl --request POST --header "PRIVATE-TOKEN: " \ | `namespace_id` | integer | No | Namespace for the new project (defaults to the current user's namespace). | | `only_allow_merge_if_all_discussions_are_resolved` | boolean | No | Set whether merge requests can only be merged when all the discussions are resolved. | | `only_allow_merge_if_all_status_checks_passed` | boolean | No | Indicates that merges of merge requests should be blocked unless all status checks have passed. Defaults to false. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/369859) in GitLab 15.5 with feature flag `only_allow_merge_if_all_status_checks_passed` disabled by default. Ultimate only. | -| `only_allow_merge_if_pipeline_succeeds` | boolean | No | Set whether merge requests can only be merged with successful pipelines. This setting is named [**Pipelines must succeed**](../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) in the project settings. | +| `only_allow_merge_if_pipeline_succeeds` | boolean | No | Set whether merge requests can only be merged with successful pipelines. This setting is named [**Pipelines must succeed**](../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) in the project settings. | | `packages_enabled` | boolean | No | Enable or disable packages repository feature. | | `pages_access_level` | string | No | One of `disabled`, `private`, `enabled`, or `public`. | | `printing_merge_request_link_enabled` | boolean | No | Show link to create/view merge request when pushing from the command line. | diff --git a/doc/ci/debugging.md b/doc/ci/debugging.md index 3d5851769d4..681141e7874 100644 --- a/doc/ci/debugging.md +++ b/doc/ci/debugging.md @@ -355,7 +355,7 @@ and error messages. ### `A CI/CD pipeline must run and be successful before merge` message -This message is shown if the [**Pipelines must succeed**](../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) +This message is shown if the [**Pipelines must succeed**](../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) setting is enabled in the project and a pipeline has not yet run successfully. This also applies if the pipeline has not been created yet, or if you are waiting for an external CI service. diff --git a/doc/ci/jobs/job_control.md b/doc/ci/jobs/job_control.md index 1e4dd4b47f3..f98f16c53e6 100644 --- a/doc/ci/jobs/job_control.md +++ b/doc/ci/jobs/job_control.md @@ -50,7 +50,7 @@ In blocking manual jobs: defined inside [`rules`](../yaml/index.md#rules). - The pipeline stops at the stage where the job is defined. To let the pipeline continue running, [run the manual job](#run-a-manual-job). -- Merge requests in projects with [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) +- Merge requests in projects with [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) enabled can't be merged with a blocked pipeline. - The pipeline shows a status of **blocked**. diff --git a/doc/ci/pipelines/merge_trains.md b/doc/ci/pipelines/merge_trains.md index f46c749d7d2..6a6aded7cc3 100644 --- a/doc/ci/pipelines/merge_trains.md +++ b/doc/ci/pipelines/merge_trains.md @@ -244,7 +244,7 @@ notes. Check the **Activity** section in the **Overview** tab for a message simi ### Cannot use auto-merge -You cannot use [auto-merge](../../user/project/merge_requests/merge_when_pipeline_succeeds.md) +You cannot use [auto-merge](../../user/project/merge_requests/auto_merge.md) (formerly **Merge when pipeline succeeds**) to skip the merge train, when merge trains are enabled. See [issue 12267](https://gitlab.com/gitlab-org/gitlab/-/issues/12267) for more information. @@ -264,7 +264,7 @@ You can: ### Unable to add to the merge train -When [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) +When [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) is enabled, but the latest pipeline failed: - The **Set to auto-merge** or **Merge** options are not available. diff --git a/doc/ci/pipelines/merged_results_pipelines.md b/doc/ci/pipelines/merged_results_pipelines.md index 111a5289879..6c2073e375f 100644 --- a/doc/ci/pipelines/merged_results_pipelines.md +++ b/doc/ci/pipelines/merged_results_pipelines.md @@ -67,6 +67,6 @@ on your GitLab instance. ### Successful merged results pipeline overrides a failed branch pipeline A failed branch pipeline is sometimes ignored when the -[**Pipelines must succeed** setting](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) +[**Pipelines must succeed** setting](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) is activated. [Issue 385841](https://gitlab.com/gitlab-org/gitlab/-/issues/385841) is open to track this. diff --git a/doc/ci/pipelines/mr_pipeline_troubleshooting.md b/doc/ci/pipelines/mr_pipeline_troubleshooting.md index e6dd9de9df5..8ba75560ade 100644 --- a/doc/ci/pipelines/mr_pipeline_troubleshooting.md +++ b/doc/ci/pipelines/mr_pipeline_troubleshooting.md @@ -35,7 +35,7 @@ It's possible to have both branch pipelines and merge request pipelines in the **Pipelines** tab of a single merge request. This might be [by configuration](../yaml/workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines), or [by accident](#two-pipelines-when-pushing-to-a-branch). -When the project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) enabled +When the project has [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) enabled and both pipelines types are present, the merge request pipelines are checked, not the branch pipelines. diff --git a/doc/ci/yaml/workflow.md b/doc/ci/yaml/workflow.md index 243d30abd96..f95c40e2411 100644 --- a/doc/ci/yaml/workflow.md +++ b/doc/ci/yaml/workflow.md @@ -19,12 +19,12 @@ for tags, but the workflow prevents tag pipelines, the job never runs. Some example `if` clauses for `workflow: rules`: -| Example rules | Details | -|------------------------------------------------------|---------| -| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run. | +| Example rules | Details | +|------------------------------------------------------|-----------------------------------------------------------| +| `if: '$CI_PIPELINE_SOURCE == "merge_request_event"'` | Control when merge request pipelines run. | | `if: '$CI_PIPELINE_SOURCE == "push"'` | Control when both branch pipelines and tag pipelines run. | -| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. | -| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. | +| `if: $CI_COMMIT_TAG` | Control when tag pipelines run. | +| `if: $CI_COMMIT_BRANCH` | Control when branch pipelines run. | See the [common `if` clauses for `rules`](../jobs/job_rules.md#common-if-clauses-with-predefined-variables) for more examples. @@ -176,7 +176,7 @@ include: If a merge request displays `Checking pipeline status.`, but the message never goes away (the "spinner" never stops spinning), it might be due to `workflow:rules`. -This issue can happen if a project has [**Pipelines must succeed**](../../user/project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge) +This issue can happen if a project has [**Pipelines must succeed**](../../user/project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge) enabled, but the `workflow:rules` prevent a pipeline from running for the merge request. For example, with this workflow, merge requests cannot be merged, because no diff --git a/doc/user/gitlab_duo_chat.md b/doc/user/gitlab_duo_chat.md index 3dd6bd6f74f..1b66b6df199 100644 --- a/doc/user/gitlab_duo_chat.md +++ b/doc/user/gitlab_duo_chat.md @@ -314,15 +314,20 @@ In GitLab 16.8, 16.9, and 16.10, on GitLab Dedicated, GitLab Duo Chat is availab ## Disable GitLab Duo Chat -To disable GitLab Duo Chat, follow the instructions for +If you have a Premium or Ultimate subscription, the **GitLab Duo Chat** button +is always displayed in the upper-right corner of the UI, and on the left sidebar under **Help**. + +You do, however, have an option for changing the availability of GitLab Duo Chat. + +### Change the data used by GitLab Duo Chat + +To limit the data that Duo Chat has access to, follow the instructions for [disabling GitLab Duo features](ai_features_enable.md). -When you disable GitLab Duo features, GitLab Duo Chat no longer uses your organization's -data when responding to questions. For example, you can no longer ask about your issues or epics. - -However, the **GitLab Duo Chat** button continues to be displayed in the upper-right corner -and on the left sidebar under **Help**, and -you can continue to ask generic questions about GitLab. +When you make this change, the button is not removed. Instead, +GitLab Duo Chat no longer uses your organization's data when responding to questions. +For example, you can no longer ask about your issues or epics. You can, however, +continue to ask generic questions about GitLab. ## Use GitLab Duo Chat in the GitLab UI diff --git a/doc/user/group/manage.md b/doc/user/group/manage.md index cdb58f5de0e..557e985fa94 100644 --- a/doc/user/group/manage.md +++ b/doc/user/group/manage.md @@ -352,7 +352,7 @@ that inherited them. You can configure all child projects in your group to require a complete and successful pipeline before merge. -See also [the project-level setting](../project/merge_requests/merge_when_pipeline_succeeds.md#require-a-successful-pipeline-for-merge). +See also [the project-level setting](../project/merge_requests/auto_merge.md#require-a-successful-pipeline-for-merge). Prerequisites: @@ -371,7 +371,7 @@ To enable this setting: You can configure [skipped pipelines](../../ci/pipelines/index.md#skip-a-pipeline) from preventing merge requests from being merged. -See also [the project-level setting](../project/merge_requests/merge_when_pipeline_succeeds.md#allow-merge-after-skipped-pipelines). +See also [the project-level setting](../project/merge_requests/auto_merge.md#allow-merge-after-skipped-pipelines). Prerequisites: diff --git a/doc/user/group/saml_sso/group_sync.md b/doc/user/group/saml_sso/group_sync.md index ef7633292ac..9328d682090 100644 --- a/doc/user/group/saml_sso/group_sync.md +++ b/doc/user/group/saml_sso/group_sync.md @@ -139,6 +139,14 @@ Microsoft has [announced](https://azure.microsoft.com/en-us/updates/azure-ad-is- Azure AD sends up to 150 groups in the groups claim. When users are members of more than 150 groups Azure AD sends a group overage claim attribute in the SAML response. Then group memberships must be obtained using the Microsoft Graph API. +The [Graph API endpoint](https://learn.microsoft.com/en-us/graph/api/user-list-transitivememberof?view=graph-rest-1.0&tabs=http#http-request) supports only a +[user object ID](https://learn.microsoft.com/en-us/partner-center/find-ids-and-domain-names#find-the-user-object-id) or +[userPrincipalName](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/plan-connect-userprincipalname#what-is-userprincipalname) +as the [configured](../../../user/group/saml_sso/index.md#azure) Unique User Identifier (Name identifier) attribute. + +When the integration processes Group Sync, only Group Links configured with +group unique identifiers (like `12345678-9abc-def0-1234-56789abcde`) are supported. + To integrate Microsoft Azure AD, you: - Configure Azure AD to enable GitLab to communicate with the Microsoft Graph API. diff --git a/doc/user/project/merge_requests/auto_merge.md b/doc/user/project/merge_requests/auto_merge.md new file mode 100644 index 00000000000..4b28272ea5e --- /dev/null +++ b/doc/user/project/merge_requests/auto_merge.md @@ -0,0 +1,188 @@ +--- +stage: Create +group: Code Review +info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments +description: "Set auto-merge on a merge request when you have reviewed its content, so it can merge without intervention when all merge checks pass." +--- + +# Auto-merge + +DETAILS: +**Tier:** Free, Premium, Ultimate +**Offering:** GitLab.com, Self-managed, GitLab Dedicated + +> - **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/409530) to **Auto-merge** in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. Enabled by default. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120922) in GitLab 16.0. Feature flag `auto_merge_labels_mr_widget` removed. +> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10874) in GitLab 16.5 [with two flags](../../../administration/feature_flags.md) named `merge_when_checks_pass` and `additional_merge_when_checks_ready`. Disabled by default. +> - [Enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/412995) the flags `merge_when_checks_pass` and `additional_merge_when_checks_ready` on GitLab.com in GitLab 17.0. + +FLAG: +The availability of this feature is controlled by a feature flag. +For more information, see the history. +This feature is available for testing, but not ready for production use. + +When the `merge_when_checks_pass` feature flag is enabled, if the content of a merge request is ready to merge, +you can select **Set to auto-merge**. The merge request auto-merges when all required checks complete successfully, and you don't need to remember to manually merge the merge request. + +After you set auto-merge, these checks must all pass before the merge request is merged: + +- All required approvals must be given. +- No other merge requests block this merge request. +- No merge conflicts exist. +- A CI/CD pipeline must complete successfully, regardless of the [project setting](#require-a-successful-pipeline-for-merge). +- All discussions are resolved. +- The merge request is not a **Draft**. +- All external status checks have passed. +- The merge request must be open. +- No denied policies exist. +- If your project + [requires merge requests to reference a Jira issue](../../../integration/jira/issues.md#require-associated-jira-issue-for-merge-requests-to-be-merged), + the merge request title or description contains a Jira issue link. + +For a full list of checks and their API equivalents, see +[Merge status](../../../api/merge_requests.md#merge-status). + +![Auto-merge is ready](img/auto_merge_ready_v16_0.png) + +## Auto-merge a merge request + +Prerequisites: + +- You must have at least the Developer role in the project. +- If your project configuration requires it, all threads in the + merge request [must be resolved](index.md#resolve-a-thread). +- The merge request must have received all required approvals. +- Merge trains are not supported. For more information, + see [issue 443395](https://gitlab.com/gitlab-org/gitlab/-/issues/443395). + +To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds` +[push option](../push_options.md). + +To do this from the GitLab user interface: + +1. On the left sidebar, select **Search or go to** and find your project. +1. Select **Code > Merge requests**. +1. Select the merge request to edit. +1. Scroll to the merge request reports section. +1. Optional. Select your desired merge options, such as **Delete source branch**, + **Squash commits**, or **Edit commit message**. +1. Select **Auto-merge**. + +If you add a new comment to the merge request after you select **Auto-merge**, +but before the pipeline completes, GitLab blocks the merge until you +resolve all existing threads. + +## Pipeline success for auto-merge + +If the pipeline succeeds, the merge request merges. If the pipeline fails, the author +can either retry any failed jobs, or push new commits to fix the failure: + +- If a retried job succeeds on the second try, the merge request merges. +- If you add new commits to the merge request, GitLab cancels the request + to ensure the new changes receive a review before merge. +- If you add new commits to the _target_ branch of the merge request, and your project + allows only fast-forward merge requests, GitLab cancels the request to prevent merge conflicts. + +For stricter control on pipeline status, you can also +[require a successful pipeline](#require-a-successful-pipeline-for-merge) before merge. + +## Cancel an auto-merge + +You can cancel auto-merge on a merge request. + +Prerequisites: + +- You must either be the author of the merge request, or a project member with + at least the Developer role. +- The merge request's pipeline must still be in progress. + +To do this: + +1. On the left sidebar, select **Search or go to** and find your project. +1. Select **Code > Merge requests**. +1. Select the merge request to edit. +1. Scroll to the merge request reports section. +1. Select **Cancel auto-merge**. + +![Status](img/cancel-mwps_v15_4.png) + +## Require a successful pipeline for merge + +You can configure your project to require a complete and successful pipeline before +merge. This configuration works for both: + +- GitLab CI/CD pipelines. +- Pipelines run from an [external CI integration](../integrations/index.md#available-integrations). + +As a result, [disabling GitLab CI/CD pipelines](../../../ci/pipelines/settings.md#disable-gitlab-cicd-pipelines) +does not disable this feature, but you can use pipelines from external +CI providers with it. + +Prerequisites: + +- Ensure your project's CI/CD configuration runs a pipeline for every merge request. +- You must have at least the Maintainer role in the project. + +To enable this setting: + +1. On the left sidebar, select **Search or go to** and find your project. +1. Select **Settings > Merge requests**. +1. Scroll to **Merge checks**, and select **Pipelines must succeed**. + This setting also prevents merge requests from merging if there is no pipeline, + which can [conflict with some rules](#merge-request-cant-merge-despite-no-failed-pipeline). +1. Select **Save**. + +If [multiple pipeline types run for the same merge request](#merge-request-can-still-be-merged-despite-a-failed-pipeline), +merge request pipelines take precedence over other pipeline types. For example, +an older but successful merge request pipeline allows a merge request to be merged, +despite a newer but failed branch pipeline. + +### Allow merge after skipped pipelines + +When you set **Pipelines must succeed** for a project, +[skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent +merge requests from merging. + +Prerequisites: + +- You must have at least the Maintainer role in the project. + +To change this behavior: + +1. On the left sidebar, select **Search or go to** and find your project. +1. Select **Settings > Merge requests**. +1. Under **Merge checks**: + - Select **Pipelines must succeed**. + - Select **Skipped pipelines are considered successful**. +1. Select **Save**. + +## Troubleshooting + +### Merge request can't merge despite no failed pipeline + +In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge), +but be unable to merge a merge request with no failed pipelines. The setting requires +the existence of a successful pipeline, not the absence of failed pipelines. If the merge request +has no pipelines at all, it is not considered to have a successful pipeline and cannot be merged. + +When you enable this setting, use [`rules`](../../../ci/yaml/index.md#rules) +or [`workflow:rules`](../../../ci/yaml/index.md#workflowrules) to ensure pipelines +run for every merge request. + +### Merge request can still be merged despite a failed pipeline + +In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge), +but still merge a merge request with a failed pipeline. + +Merge request pipelines have the highest priority for the **Pipelines must succeed** setting. +If multiple pipeline types run for the same merge request, only the merge request pipelines +are checked for success. + +Multiple pipeline types in the same merge request can be caused by: + +- A [`rules`](../../../ci/yaml/index.md#rules) configuration that causes [duplicate pipelines](../../../ci/jobs/job_rules.md#avoid-duplicate-pipelines): + one merge request pipeline and one branch pipeline. In this case, the status of the + latest merge request pipeline determines if a merge request can be merged, not the branch pipeline. +- Pipelines triggered by external tools that target the same branch as the merge request. + +In all cases, update your CI/CD configuration to prevent multiple pipeline types for the same merge request. diff --git a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md index 03d1fce0a75..141bb83bb4b 100644 --- a/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md +++ b/doc/user/project/merge_requests/merge_when_pipeline_succeeds.md @@ -1,189 +1,11 @@ --- -stage: Create -group: Code Review -info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments -description: "Set auto-merge on a merge request when you have reviewed its content, so it can merge without intervention when all merge checks pass." +redirect_to: 'auto_merge.md' +remove_date: '2024-10-02' --- -# Auto-merge +This document was moved to [another location](auto_merge.md). -DETAILS: -**Tier:** Free, Premium, Ultimate -**Offering:** GitLab.com, Self-managed, GitLab Dedicated - -> - **Merge when pipeline succeeds** and **Add to merge train when pipeline succeeds** [renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/409530) to **Auto-merge** in GitLab 16.0 [with a flag](../../../administration/feature_flags.md) named `auto_merge_labels_mr_widget`. Enabled by default. -> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120922) in GitLab 16.0. Feature flag `auto_merge_labels_mr_widget` removed. - -If the content of a merge request is ready to merge, use **Set to auto-merge** on -the merge request. You don't have to remember later to merge the work manually. If set, -a merge request auto-merges when all these conditions are met: - -- The merge request pipeline must complete successfully. -- All required approvals must be given. - -![Auto-merge is ready](img/auto_merge_ready_v16_0.png) - -The [merge when checks pass](#merge-when-checks-pass) feature, available in -GitLab 16.9 and later, adds more checks to the auto-merge process. - -## Auto-merge a merge request - -Prerequisites: - -- You must have at least the Developer role in the project. -- If the project is configured to require it, all threads in the - merge request [must be resolved](index.md#resolve-a-thread). -- The merge request must have received all required approvals. - -To do this when pushing from the command line, use the `merge_request.merge_when_pipeline_succeeds` -[push option](../push_options.md). - -To do this from the GitLab user interface: - -1. On the left sidebar, select **Search or go to** and find your project. -1. Select **Code > Merge requests**. -1. Select the merge request to edit. -1. Scroll to the merge request reports section. -1. Optional. Select your desired merge options, such as **Delete source branch**, - **Squash commits**, or **Edit commit message**. -1. Select **Auto-merge**. - -If a new comment is added to the merge request after you select **Auto-merge**, -but before the pipeline completes, GitLab blocks the merge until you -resolve all existing threads. - -### Merge when pipeline succeeds - -If the pipeline succeeds, the merge request is merged. If the pipeline fails, the -author can either retry any failed jobs, or push new commits to fix the failure: - -- If a retried job succeeds on the second try, the merge request is merged. -- If new commits are added to the merge request, GitLab cancels the request - to ensure the new changes are reviewed before merge. -- If new commits are added to the target branch of the merge request and - fast-forward only merge request is configured, GitLab cancels the request - to prevent merge conflicts. - -### Merge when checks pass - -DETAILS: -**Tier:** Free, Premium, Ultimate -**Offering:** GitLab.com, Self-managed - -> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/10874) in GitLab 16.5 [with two flags](../../../administration/feature_flags.md) named `merge_when_checks_pass` and `additional_merge_when_checks_ready`. Disabled by default. -> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/412995) in GitLab 16.9. - -FLAG: -On self-managed GitLab, by default this feature is not available. To enable the feature, -an administrator can [enable the feature flags](../../../administration/feature_flags.md) -named `merge_when_checks_pass` and `additional_merge_when_checks_ready`. -On GitLab.com, this feature is available. On GitLab Dedicated, this feature is not available. - -In GitLab 16.9 and later, **Merge when checks pass** adds more checks to the auto-merge -process. When set to auto-merge, all of these checks must pass for a merge request to merge: - -- The merge request pipeline must complete successfully, regardless of the project setting. -- All required approvals must be given. -- The merge request must not be a **Draft**. -- All discussions must be resolved. -- All blocking merge requests must be merged or closed. - -## Cancel an auto-merge - -If a merge request is set to auto-merge, you can cancel it. - -Prerequisites: - -- You must either be the author of the merge request, or a project member with - at least the Developer role. -- The merge request's pipeline must still be in progress. - -To do this: - -1. On the left sidebar, select **Search or go to** and find your project. -1. Select **Code > Merge requests**. -1. Select the merge request to edit. -1. Scroll to the merge request reports section. -1. Select **Cancel auto-merge**. - -![Status](img/cancel-mwps_v15_4.png) - -## Require a successful pipeline for merge - -You can configure your project to require a complete and successful pipeline before -merge. This configuration works for both: - -- GitLab CI/CD pipelines. -- Pipelines run from an [external CI integration](../integrations/index.md#available-integrations). - -As a result, [disabling GitLab CI/CD pipelines](../../../ci/pipelines/settings.md#disable-gitlab-cicd-pipelines) -does not disable this feature, but you can use pipelines from external -CI providers with it. - -Prerequisites: - -- Ensure CI/CD is configured to run a pipeline for every merge request. -- You must have at least the Maintainer role in the project. - -To enable this setting: - -1. On the left sidebar, select **Search or go to** and find your project. -1. Select **Settings > Merge requests**. -1. Scroll to **Merge checks**, and select **Pipelines must succeed**. - This setting also prevents merge requests from being merged if there is no pipeline, - which can [conflict with some rules](#merge-request-cannot-be-merged-despite-no-failed-pipeline). -1. Select **Save**. - -If [multiple pipeline types run for the same merge request](#merge-request-can-still-be-merged-despite-a-failed-pipeline), -merge request pipelines take precedence over other pipeline types. For example, -an older but successful merge request pipeline allows a merge request to be merged, -despite a newer but failed branch pipeline. - -### Allow merge after skipped pipelines - -When the **Pipelines must succeed** checkbox is checked, -[skipped pipelines](../../../ci/pipelines/index.md#skip-a-pipeline) prevent -merge requests from being merged. - -Prerequisites: - -- You must have at least the Maintainer role in the project. - -To change this behavior: - -1. On the left sidebar, select **Search or go to** and find your project. -1. Select **Settings > Merge requests**. -1. Under **Merge checks**: - - Select **Pipelines must succeed**. - - Select **Skipped pipelines are considered successful**. -1. Select **Save**. - -## Troubleshooting - -### Merge request cannot be merged despite no failed pipeline - -In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge), -but be unable to merge a merge request with no failed pipelines. The setting requires -the existence of a successful pipeline, not the absence of failed pipelines. If the merge request -has no pipelines at all, it is not considered to have a successful pipeline and cannot be merged. - -When the setting is enabled, use [`rules`](../../../ci/yaml/index.md#rules) or [`workflow:rules`](../../../ci/yaml/index.md#workflowrules) -to ensure pipelines run for every merge request. - -### Merge request can still be merged despite a failed pipeline - -In some cases, you can [require a successful pipeline for merge](#require-a-successful-pipeline-for-merge), -but still merge a merge request with a failed pipeline. - -Merge request pipelines have the highest priority for the **Pipelines must succeed** setting. -If multiple pipeline types run for the same merge request, only the merge request pipelines -are checked for success. - -Multiple pipeline types in the same merge request can be caused by: - -- A [`rules`](../../../ci/yaml/index.md#rules) configuration that causes [duplicate pipelines](../../../ci/jobs/job_rules.md#avoid-duplicate-pipelines): - one merge request pipeline and one branch pipeline. In this case, the status of the - latest merge request pipeline determines if a merge request can be merged, not the branch pipeline. -- Pipelines triggered by external tools that target the same branch as the merge request. - -In all cases, update your CI/CD configuration to prevent multiple pipeline types for the same merge request. + + + + diff --git a/lib/gitlab/repository_set_cache.rb b/lib/gitlab/repository_set_cache.rb index 838f44c0f9e..b77218c9697 100644 --- a/lib/gitlab/repository_set_cache.rb +++ b/lib/gitlab/repository_set_cache.rb @@ -7,7 +7,7 @@ module Gitlab def initialize(repository, extra_namespace: nil, expires_in: 2.weeks) @repository = repository - @namespace = "#{repository.full_path}" + @namespace = repository.full_path.to_s @namespace += ":#{repository.project.id}" if repository.project @namespace = "#{@namespace}:#{extra_namespace}" if extra_namespace @expires_in = expires_in diff --git a/lib/gitlab/usage_data_counters/search_counter.rb b/lib/gitlab/usage_data_counters/search_counter.rb index 46aec52b95a..31d8485042e 100644 --- a/lib/gitlab/usage_data_counters/search_counter.rb +++ b/lib/gitlab/usage_data_counters/search_counter.rb @@ -16,7 +16,7 @@ module Gitlab private def counter_key(event) - "#{event}".to_sym + event.to_s.to_sym end end end diff --git a/lib/kramdown/converter/commonmark.rb b/lib/kramdown/converter/commonmark.rb index 0055558989d..58e52f83046 100644 --- a/lib/kramdown/converter/commonmark.rb +++ b/lib/kramdown/converter/commonmark.rb @@ -34,7 +34,7 @@ module Kramdown def convert_codeblock(el, _opts) # Although tildes are supported in CommonMark, backticks are more common "```#{el.options[:lang]}\n" + - el.value.split("\n").map { |l| l.empty? ? "" : "#{l}" }.join("\n") + + el.value.split("\n").map { |l| l.empty? ? "" : l.to_s }.join("\n") + "\n```\n\n" end diff --git a/lib/tasks/gettext.rake b/lib/tasks/gettext.rake index 4bd455bdbfe..3f1deafa07b 100644 --- a/lib/tasks/gettext.rake +++ b/lib/tasks/gettext.rake @@ -101,7 +101,7 @@ namespace :gettext do puts " #{message_id}" errors.each do |error| spaces = ' ' * 4 - error = error.lines.join("#{spaces}") + error = error.lines.join(spaces.to_s) puts "#{spaces}#{error}" end end diff --git a/lib/tasks/gitlab/seed/group_seed.rake b/lib/tasks/gitlab/seed/group_seed.rake index 80cdf870c32..23467d19684 100644 --- a/lib/tasks/gitlab/seed/group_seed.rake +++ b/lib/tasks/gitlab/seed/group_seed.rake @@ -165,7 +165,7 @@ class GroupSeeder group = Group.find(group_id) label_title = FFaker::Product.brand - Labels::CreateService.new(title: label_title, color: "#{::Gitlab::Color.color_for(label_title)}").execute(group: group) + Labels::CreateService.new(title: label_title, color: ::Gitlab::Color.color_for(label_title).to_s).execute(group: group) end end end diff --git a/qa/qa/resource/events/base.rb b/qa/qa/resource/events/base.rb index f01fa871726..6a27817d0a9 100644 --- a/qa/qa/resource/events/base.rb +++ b/qa/qa/resource/events/base.rb @@ -15,7 +15,7 @@ module QA query << "target_type=#{CGI.escape(target_type)}" if target_type path = [api_get_events] path << "?#{query.join("&")}" unless query.empty? - parse_body(api_get_from("#{path.join}")) + parse_body(api_get_from(path.join.to_s)) end private diff --git a/qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb b/qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb index 78714e21a90..3476d741bb5 100644 --- a/qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb +++ b/qa/qa/specs/features/browser_ui/4_verify/pipeline/include_multiple_files_from_a_project_spec.rb @@ -44,8 +44,8 @@ module QA Page::Project::Job::Show.perform do |job| aggregate_failures 'main CI is not overridden' do - expect(job.output).not_to have_content("#{unexpected_text}") - expect(job.output).to have_content("#{expected_text}") + expect(job.output).not_to have_content(unexpected_text.to_s) + expect(job.output).to have_content(expected_text.to_s) end end end diff --git a/qa/qa/tools/generate_perf_testdata.rb b/qa/qa/tools/generate_perf_testdata.rb index 0f06fd2fbc4..3bb21e66d49 100644 --- a/qa/qa/tools/generate_perf_testdata.rb +++ b/qa/qa/tools/generate_perf_testdata.rb @@ -77,7 +77,7 @@ module QA def create_many_todos 30.times do |i| - create_a_todo_api_req("#{@group_name}%2F#{@project_name}", "#{i + 1}") + create_a_todo_api_req("#{@group_name}%2F#{@project_name}", (i + 1).to_s) end @urls[:todos_page] = ENV['GITLAB_ADDRESS'] + "/dashboard/todos" $stdout.puts "Created many todos: #{@urls[:todos_page]}" @@ -85,7 +85,7 @@ module QA def create_many_labels 30.times do |i| - create_a_label_api_req("#{@group_name}%2F#{@project_name}", "label#{i}", "#{Faker::Color.hex_color}") + create_a_label_api_req("#{@group_name}%2F#{@project_name}", "label#{i}", Faker::Color.hex_color.to_s) end @urls[:labels_page] = @urls[:project_page] + "/labels" $stdout.puts "Created many labels: #{@urls[:labels_page]}" @@ -126,7 +126,7 @@ module QA labels_list = (0..15).map { |i| "label#{i}" }.join(',') # Add description and labels - update_an_issue_api_req("#{@group_name}%2F#{@project_name}", issue_id, "#{Faker::Lorem.sentences(500).join(" ")}", labels_list) + update_an_issue_api_req("#{@group_name}%2F#{@project_name}", issue_id, Faker::Lorem.sentences(500).join(" ").to_s, labels_list) @urls[:large_issue] = @urls[:project_page] + "/issues/#{issue_id}" $stdout.puts "Created an issue with many discussions: #{@urls[:large_issue]}" end diff --git a/scripts/internal_events/monitor.rb b/scripts/internal_events/monitor.rb index 03f17ed257d..274a2ace049 100644 --- a/scripts/internal_events/monitor.rb +++ b/scripts/internal_events/monitor.rb @@ -74,7 +74,19 @@ def generate_snowplow_table @initial_max_timestamp ||= events.map { |e| e['rawEvent']['parameters']['dtm'].to_i }.max || 0 rows = [] - rows << ['Event Name', 'Collector Timestamp', 'Category', 'user_id', 'namespace_id', 'project_id', 'plan'] + rows << [ + 'Event Name', + 'Collector Timestamp', + 'Category', + 'user_id', + 'namespace_id', + 'project_id', + 'plan', + 'Label', + 'Property', + 'Value' + ] + rows << :separator events.each do |event| @@ -87,7 +99,10 @@ def generate_snowplow_table standard_context[:user_id], standard_context[:namespace_id], standard_context[:project_id], - standard_context[:plan] + standard_context[:plan], + event['event']['se_label'], + event['event']['se_property'], + event['event']['se_value'] ] row.map! { |value| red(value) } if event['rawEvent']['parameters']['dtm'].to_i > @initial_max_timestamp diff --git a/scripts/perf/gc/print_gc_stats.rb b/scripts/perf/gc/print_gc_stats.rb index a15b6f5b0e0..a72a046051c 100755 --- a/scripts/perf/gc/print_gc_stats.rb +++ b/scripts/perf/gc/print_gc_stats.rb @@ -17,7 +17,7 @@ module GC::Profiler attr_accessor :use_exclusive %i[enable disable clear].each do |method| - alias_method "#{method}_orig", "#{method}" + alias_method "#{method}_orig", method.to_s define_method(method) do if use_exclusive diff --git a/scripts/qa/testcases-check b/scripts/qa/testcases-check index fad5f620e02..6bfc3d76305 100755 --- a/scripts/qa/testcases-check +++ b/scripts/qa/testcases-check @@ -36,7 +36,7 @@ tests.each do |test| next if test['id'] =~ %r{.\/qa\/specs\/features\/sanity\/*} if test['testcase'] - testcases.push(["#{test['testcase']}", "#{test['id']} - #{test['full_description']}"]) + testcases.push([(test['testcase']).to_s, "#{test['id']} - #{test['full_description']}"]) unless TESTCASE_FORMAT =~ test['testcase'] testcase_format_errors.push( diff --git a/spec/models/ci/bridge_spec.rb b/spec/models/ci/bridge_spec.rb index 295673a8d55..202286645b1 100644 --- a/spec/models/ci/bridge_spec.rb +++ b/spec/models/ci/bridge_spec.rb @@ -122,6 +122,56 @@ RSpec.describe Ci::Bridge, feature_category: :continuous_integration do end end + describe 'state machine events' do + describe 'start_cancel!' do + valid_statuses = Ci::HasStatus::CANCELABLE_STATUSES.map(&:to_sym) + [:manual] + # Invalid statuses are statuses that are COMPLETED_STATUSES or already canceling + invalid_statuses = Ci::HasStatus::AVAILABLE_STATUSES.map(&:to_sym) - valid_statuses + + valid_statuses.each do |status| + it "transitions from #{status} to canceling" do + bridge = create(:ci_bridge, status: status) + + bridge.start_cancel! + + expect(bridge.status).to eq('canceling') + end + end + + invalid_statuses.each do |status| + it "does not transition from #{status} to canceling" do + bridge = create(:ci_bridge, status: status) + + expect { bridge.start_cancel! } + .to raise_error(StateMachines::InvalidTransition) + end + end + end + + describe 'finish_cancel!' do + valid_statuses = Ci::HasStatus::CANCELABLE_STATUSES.map(&:to_sym) + [:manual, :canceling] + invalid_statuses = Ci::HasStatus::AVAILABLE_STATUSES.map(&:to_sym) - valid_statuses + valid_statuses.each do |status| + it "transitions from #{status} to canceling" do + bridge = create(:ci_bridge, status: status) + + bridge.finish_cancel! + + expect(bridge.status).to eq('canceled') + end + end + + invalid_statuses.each do |status| + it "does not transition from #{status} to canceling" do + bridge = create(:ci_bridge, status: status) + + expect { bridge.finish_cancel! } + .to raise_error(StateMachines::InvalidTransition) + end + end + end + end + describe 'state machine transitions' do context 'when bridge points towards downstream' do %i[created manual].each do |status| diff --git a/spec/models/ci/pipeline_spec.rb b/spec/models/ci/pipeline_spec.rb index 686cd55abc0..f532477f7e5 100644 --- a/spec/models/ci/pipeline_spec.rb +++ b/spec/models/ci/pipeline_spec.rb @@ -1495,9 +1495,9 @@ RSpec.describe Ci::Pipeline, :mailer, factory_default: :keep, feature_category: let(:build_b) { create_build('build2', queued_at: 0) } let(:build_c) { create_build('build3', queued_at: 0) } - describe '#canceling' do + describe '#start_cancel' do it 'transitions to canceling' do - expect { pipeline.canceling }.to change { pipeline.status }.from('created').to('canceling') + expect { pipeline.start_cancel }.to change { pipeline.status }.from('created').to('canceling') end end diff --git a/spec/models/ci/stage_spec.rb b/spec/models/ci/stage_spec.rb index b37748c04c3..014bd83d17d 100644 --- a/spec/models/ci/stage_spec.rb +++ b/spec/models/ci/stage_spec.rb @@ -118,13 +118,13 @@ RSpec.describe Ci::Stage, :models, feature_category: :continuous_integration do end end - describe '#canceling' do + describe '#start_cancel' do it 'transitions to canceling' do stage = create(:ci_stage, pipeline: pipeline, project: pipeline.project, status: 'running') create(:ci_build, :success, stage_id: stage.id) create(:ci_build, :running, stage_id: stage.id) - expect { stage.canceling }.to change { stage.status }.from('running').to('canceling') + expect { stage.start_cancel }.to change { stage.status }.from('running').to('canceling') end end diff --git a/spec/models/deployment_spec.rb b/spec/models/deployment_spec.rb index 9c887531d62..0643e61147f 100644 --- a/spec/models/deployment_spec.rb +++ b/spec/models/deployment_spec.rb @@ -1265,17 +1265,18 @@ RSpec.describe Deployment, feature_category: :continuous_delivery do using RSpec::Parameterized::TableSyntax where(:status, :method) do - 'running' | :run! - 'success' | :succeed! - 'failed' | :drop! - 'canceled' | :cancel! - 'skipped' | :skip! - 'blocked' | :block! + 'running' | :run! + 'success' | :succeed! + 'failed' | :drop! + 'canceling' | nil + 'canceled' | :cancel! + 'skipped' | :skip! + 'blocked' | :block! end with_them do it 'calls the correct method for the given status' do - expect(deploy).to receive(method) + expect(deploy).to receive(method) if method deploy.update_status(status) end