Add latest changes from gitlab-org/gitlab@master

11 files changed, 139 insertions, 266 deletions

diff --git a/db/post_migrate/20221028000041_remove_invalid_partial_trigram_indexes_for_issues.rb b/db/post_migrate/20221028000041_remove_invalid_partial_trigram_indexes_for_issues.rb
new file mode 100644
index 00000000000..9b46647047a
--- /dev/null
+++ b/db/post_migrate/20221028000041_remove_invalid_partial_trigram_indexes_for_issues.rb
@@ -0,0 +1,15 @@
+# frozen_string_literal: true
+
+class RemoveInvalidPartialTrigramIndexesForIssues < Gitlab::Database::Migration[2.0]
+  TITLE_INDEX_NAME = 'index_issues_on_title_trigram_non_latin'
+  DESCRIPTION_INDEX_NAME = 'index_issues_on_description_trigram_non_latin'
+
+  disable_ddl_transaction!
+
+  def up
+    remove_concurrent_index_by_name :issues, TITLE_INDEX_NAME
+    remove_concurrent_index_by_name :issues, DESCRIPTION_INDEX_NAME
+  end
+
+  def down; end
+end
diff --git a/db/post_migrate/20221028000603_prepare_partial_trigram_indexes_for_issues_attempt_3.rb b/db/post_migrate/20221028000603_prepare_partial_trigram_indexes_for_issues_attempt_3.rb
new file mode 100644
index 00000000000..199a7a22d5b
--- /dev/null
+++ b/db/post_migrate/20221028000603_prepare_partial_trigram_indexes_for_issues_attempt_3.rb
@@ -0,0 +1,25 @@
+# frozen_string_literal: true
+
+class PreparePartialTrigramIndexesForIssuesAttempt3 < Gitlab::Database::Migration[2.0]
+  TITLE_INDEX_NAME = 'index_issues_on_title_trigram_non_latin'
+  DESCRIPTION_INDEX_NAME = 'index_issues_on_description_trigram_non_latin'
+
+  def up
+    prepare_async_index :issues, :title,
+      name: TITLE_INDEX_NAME,
+      using: :gin, opclass: { description: :gin_trgm_ops },
+      where: "title NOT SIMILAR TO '[\\u0000-\\u02FF\\u1E00-\\u1EFF\\u2070-\\u218F]*' " \
+             "OR description NOT SIMILAR TO '[\\u0000-\\u02FF\\u1E00-\\u1EFF\\u2070-\\u218F]*'"
+
+    prepare_async_index :issues, :description,
+      name: DESCRIPTION_INDEX_NAME,
+      using: :gin, opclass: { description: :gin_trgm_ops },
+      where: "title NOT SIMILAR TO '[\\u0000-\\u02FF\\u1E00-\\u1EFF\\u2070-\\u218F]*' " \
+             "OR description NOT SIMILAR TO '[\\u0000-\\u02FF\\u1E00-\\u1EFF\\u2070-\\u218F]*'"
+  end
+
+  def down
+    unprepare_async_index_by_name :issues, DESCRIPTION_INDEX_NAME
+    unprepare_async_index_by_name :issues, TITLE_INDEX_NAME
+  end
+end
diff --git a/db/schema_migrations/20221028000041 b/db/schema_migrations/20221028000041
new file mode 100644
index 00000000000..4160c4d26ed
--- /dev/null
+++ b/db/schema_migrations/20221028000041
@@ -0,0 +1 @@
+b2e38680afc264fadd5fbaa7d07c95c7ba6e1fb7a32bdff267e35a7d9bde72c8
\ No newline at end of file
diff --git a/db/schema_migrations/20221028000603 b/db/schema_migrations/20221028000603
new file mode 100644
index 00000000000..0dc60ae68eb
--- /dev/null
+++ b/db/schema_migrations/20221028000603
@@ -0,0 +1 @@
+aee0c708436ae365e2469b2bb5b508dcbf6975326faa90bd1571dd400312eded
\ No newline at end of file
diff --git a/doc/administration/troubleshooting/ssl.md b/doc/administration/troubleshooting/ssl.md
index 245ff9f4982..bf8e6b45fde 100644
--- a/doc/administration/troubleshooting/ssl.md
+++ b/doc/administration/troubleshooting/ssl.md
@@ -1,263 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-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
+redirect_to: 'https://docs.gitlab.com/omnibus/settings/ssl/ssl_troubleshooting.html'
+remove_date: '2023-10-27'
 ---
 
-# Troubleshooting SSL **(FREE SELF)**
+This document was moved to [another location](https://docs.gitlab.com/omnibus/settings/ssl/ssl_troubleshooting.html).
 
-This page contains a list of common SSL-related errors and scenarios that you
-may encounter while working with GitLab. It should serve as an addition to the
-main SSL documentation:
-
-- [Omnibus SSL Configuration](https://docs.gitlab.com/omnibus/settings/ssl.html).
-- [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html).
-- [Configure HTTPS manually](https://docs.gitlab.com/omnibus/settings/ssl.html#configure-https-manually).
-
-## Using an internal CA certificate with GitLab
-
-After configuring a GitLab instance with an internal CA certificate, you might
-not be able to access it by using various CLI tools. You may experience the
-following issues:
-
-- `curl` fails:
-
-  ```shell
-  curl "https://gitlab.domain.tld"
-  curl: (60) SSL certificate problem: unable to get local issuer certificate
-  More details here: https://curl.haxx.se/docs/sslcerts.html
-  ```
-
-- Testing by using the [rails console](../operations/rails_console.md#starting-a-rails-console-session)
-  also fails:
-
-  ```ruby
-  uri = URI.parse("https://gitlab.domain.tld")
-  http = Net::HTTP.new(uri.host, uri.port)
-  http.use_ssl = true
-  http.verify_mode = 1
-  response = http.request(Net::HTTP::Get.new(uri.request_uri))
-  ...
-  Traceback (most recent call last):
-        1: from (irb):5
-  OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))
-  ```
-
-- The error `SSL certificate problem: unable to get local issuer certificate`
-  is displayed when setting up a [mirror](../../user/project/repository/mirror/index.md)
-  from this GitLab instance.
-- `openssl` works when specifying the path to the certificate:
-
-  ```shell
-  /opt/gitlab/embedded/bin/openssl s_client -CAfile /root/my-cert.crt -connect gitlab.domain.tld:443 -servername gitlab.domain.tld
-  ```
-
-If you have the previously described issues, add your certificate to
-`/etc/gitlab/trusted-certs`, and then run `sudo gitlab-ctl reconfigure`.
-
-## X.509 key values mismatch error
-
-After configuring your instance with a certificate bundle, NGINX may display
-the following error message:
-
-`SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch`
-
-This error message means that the server certificate and key you have provided
-don't match. You can confirm this by running the following command and then
-comparing the output:
-
-```shell
-openssl rsa -noout -modulus -in path/to/your/.key | openssl md5
-openssl x509 -noout -modulus -in path/to/your/.crt | openssl md5
-```
-
-The following is an example of an md5 output between a matching key and
-certificate. Note the matching md5 hashes:
-
-```shell
-$ openssl rsa -noout -modulus -in private.key | openssl md5
-4f49b61b25225abeb7542b29ae20e98c
-$ openssl x509 -noout -modulus -in public.crt | openssl md5
-4f49b61b25225abeb7542b29ae20e98c
-```
-
-This is an opposing output with a non-matching key and certificate which shows
-different md5 hashes:
-
-```shell
-$ openssl rsa -noout -modulus -in private.key | openssl md5
-d418865077299af27707b1d1fa83cd99
-$ openssl x509 -noout -modulus -in public.crt | openssl md5
-4f49b61b25225abeb7542b29ae20e98c
-```
-
-If the two outputs differ like the previous example, there's a mismatch between
-the certificate and key. Contact the provider of the SSL certificate for
-further support.
-
-## Using GitLab Runner with a GitLab instance configured with internal CA certificate or self-signed certificate
-
-Besides getting the errors mentioned in
-[Using an internal CA certificate with GitLab](ssl.md#using-an-internal-ca-certificate-with-gitlab),
-your CI pipelines may get stuck in `Pending` status. In the runner logs you may
-see the following error message:
-
-```shell
-Dec  6 02:43:17 runner-host01 gitlab-runner[15131]: #033[0;33mWARNING: Checking for jobs... failed
-#033[0;m  #033[0;33mrunner#033[0;m=Bfkz1fyb #033[0;33mstatus#033[0;m=couldn't execute POST against
-https://gitlab.domain.tld/api/v4/jobs/request: Post https://gitlab.domain.tld/api/v4/jobs/request:
-x509: certificate signed by unknown authority
-```
-
-Follow the details in [Self-signed certificates or custom Certification Authorities for GitLab Runner](https://docs.gitlab.com/runner/configuration/tls-self-signed.html).
-
-## Mirroring a remote GitLab repository that uses a self-signed SSL certificate
-
-When configuring a local GitLab instance to [mirror a repository](../../user/project/repository/mirror/index.md)
-from a remote GitLab instance that uses a self-signed certificate, you may see
-the `SSL certificate problem: self signed certificate` error message in the
-user interface.
-
-The cause of the issue can be confirmed by checking if:
-
-- `curl` fails:
-
-  ```shell
-  $ curl "https://gitlab.domain.tld"
-  curl: (60) SSL certificate problem: self signed certificate
-  More details here: https://curl.haxx.se/docs/sslcerts.html
-  ```
-
-- Testing by using the Rails console also fails:
-
-  ```ruby
-  uri = URI.parse("https://gitlab.domain.tld")
-  http = Net::HTTP.new(uri.host, uri.port)
-  http.use_ssl = true
-  http.verify_mode = 1
-  response = http.request(Net::HTTP::Get.new(uri.request_uri))
-  ...
-  Traceback (most recent call last):
-        1: from (irb):5
-  OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate))
-  ```
-
-To fix this problem:
-
-- Add the self-signed certificate from the remote GitLab instance to the
-  `/etc/gitlab/trusted-certs` directory on the local GitLab instance, and then
-  run `sudo gitlab-ctl reconfigure` as per the instructions for
-  [installing custom public certificates](https://docs.gitlab.com/omnibus/settings/ssl.html#install-custom-public-certificates).
-- If your local GitLab instance was installed using the Helm Charts, you can
-  [add your self-signed certificate to your GitLab instance](https://docs.gitlab.com/runner/install/kubernetes.html#providing-a-custom-certificate-for-accessing-gitlab).
-
-You may also get another error message when trying to mirror a repository from
-a remote GitLab instance that uses a self-signed certificate:
-
-```shell
-2:Fetching remote upstream failed: fatal: unable to access &amp;#39;https://gitlab.domain.tld/root/test-repo/&amp;#39;:
-SSL: unable to obtain common name from peer certificate
-```
-
-In this case, the problem can be related to the certificate itself:
-
-1. Validate that your self-signed certificate isn't missing a common name. If it
-   is, regenerate a valid certificate
-1. Add the certificate to `/etc/gitlab/trusted-certs`.
-1. Run `sudo gitlab-ctl reconfigure`.
-
-## Unable to perform Git operations due to an internal or self-signed certificate
-
-If your GitLab instance is using a self-signed certificate, or if the
-certificate is signed by an internal certificate authority (CA), you might
-experience the following errors when attempting to perform Git operations:
-
-```shell
-$ git clone https://gitlab.domain.tld/group/project.git
-Cloning into 'project'...
-fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': SSL certificate problem: self signed certificate
-```
-
-```shell
-$ git clone https://gitlab.domain.tld/group/project.git
-Cloning into 'project'...
-fatal: unable to access 'https://gitlab.domain.tld/group/project.git/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
-```
-
-To fix this problem:
-
-- If possible, use SSH remotes for all Git operations. This is considered more
-  secure and convenient to use.
-- If you must use HTTPS remotes, you can try the following:
-  - Copy the self-signed certificate or the internal root CA certificate to a
-    local directory (for example, `~/.ssl`) and configure Git to trust your
-    certificate:
-
-    ```shell
-    git config --global http.sslCAInfo ~/.ssl/gitlab.domain.tld.crt
-    ```
-
-  - Disable SSL verification in your Git client. This is intended as a
-    temporary measure, as it could be considered a security risk.
-
-    ```shell
-    git config --global http.sslVerify false
-    ```
-
-## SSL_connect wrong version number
-
-A misconfiguration may result in:
-
-- `gitlab-rails/exceptions_json.log` entries containing:
-
-  ```plaintext
-  "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
-  "exception.class":"Excon::Error::Socket","exception.message":"SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)",
-  ```
-
-- `gitlab-workhorse/current` containing:
-
-  ```plaintext
-  http: server gave HTTP response to HTTPS client
-  http: server gave HTTP response to HTTPS client
-  ```
-
-- `gitlab-rails/sidekiq.log` or `sidekiq/current` containing:
-
-  ```plaintext
-  message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)
-  message: SSL_connect returned=1 errno=0 state=error: wrong version number (OpenSSL::SSL::SSLError)
-  ```
-
-Some of these errors come from the Excon Ruby gem, and could be generated in
-circumstances where GitLab is configured to initiate an HTTPS session to a
-remote server that is serving only HTTP.
-
-One scenario is that you're using [object storage](../object_storage.md), which
-isn't served under HTTPS. GitLab is misconfigured and attempts a TLS handshake,
-but the object storage responds with plain HTTP.
-
-## `schannel: SEC_E_UNTRUSTED_ROOT`
-
-If you're on Windows and get the following error:
-
-```plaintext
-Fatal: unable to access 'https://gitlab.domain.tld/group/project.git': schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted."
-```
-
-You must specify that Git should use OpenSSL:
-
-```shell
-git config --system http.sslbackend openssl
-```
-
-Alternatively, you can ignore SSL verification by running:
-
-WARNING:
-Proceed with caution when [ignoring SSL](https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpsslVerify)
-due to the potential security issues associated with disabling this option at global level. Use this option _only_ when troubleshooting, and reinstate SSL verification immediately after.
-
-```shell
-git config --global http.sslVerify false
-```
+<!-- This redirect file can be deleted after <2023-01-25>. -->
+<!-- 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/sec/index.md b/doc/development/sec/index.md
index f988cbc595a..fc13c960451 100644
--- a/doc/development/sec/index.md
+++ b/doc/development/sec/index.md
@@ -64,6 +64,11 @@ After the data is available as a Report Artifact it can be processed by the GitL
 
 Depending on the context, the security reports may be stored either in the database or stay as Report Artifacts for on-demand access.
 
+#### Security report ingestion overview
+
+For details on how GitLab processes the reports generated by the scanners, see
+[Security report ingestion overview](security_report_ingestion_overview.md).
+
 ## CI/CD template development
 
 While CI/CD templates are the responsibility of the Verify section, many are critical to the Sec Section's feature usage.
diff --git a/doc/development/sec/security_report_ingestion_overview.md b/doc/development/sec/security_report_ingestion_overview.md
new file mode 100644
index 00000000000..11389f388b3
--- /dev/null
+++ b/doc/development/sec/security_report_ingestion_overview.md
@@ -0,0 +1,74 @@
+---
+stage: Secure
+group: Threat Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: concepts
+---
+
+# Security report ingestion overview
+
+## Definitions
+
+- **Vulnerability Finding** – an instance of `Vulnerabilities::Finding` class. This class was previously called `Vulnerabilities::Occurrence`; after renaming the class, we kept the associated table name `vulnerability_occurrences` due to the effort involved in renaming large tables.
+- **Vulnerability** – an instance of `Vulnerability` class. They are created based on information available in `Vulnerabilities::Finding` class. Every `Vulnerability` **must have** a corresponding `Vulnerabilities::Finding` object to be valid, however this is not enforced at the database level.
+- **Security Finding** – an instance of `Security::Finding` class. They store **partial** finding data to improve performance of the pipeline security report. We are working on extending this class to store almost all required information so we can stop relying on job artifacts.
+- **Feedback** – an instance of `Vulnerabilities::Feedback` class. They are created to keep track of users' interactions with Vulnerability Findings before they are promoted to a Vulnerability. We are in the process of removing this model via [Deprecate and remove Vulnerabilities::Feedback epic](https://gitlab.com/groups/gitlab-org/-/epics/5629).
+- **Issue Link** – an instance of `Vulnerabilities::IssueLink` class. They are used to link `Vulnerability` objects to `Issue` objects.
+
+## Vulnerability creation from security reports
+
+Assumptions:
+
+- Project uses GitLab CI
+- Project uses [security scanning tools](../../user/application_security)
+- No Vulnerabilities are present in the database
+- All pipelines perform security scans
+
+1. Code is pushed to a branch that's **not** the default branch.
+1. GitLab CI runs a new pipeline for that branch.
+1. Pipeline status transitions to any of [`::Ci::Pipeline.completed_statuses`](https://gitlab.com/gitlab-org/gitlab/-/blob/354261b2fe4fc5b86d1408467beadd90e466ce0a/app/models/concerns/ci/has_status.rb#L12).
+1. `Security::StoreScansWorker` is called and it schedules `Security::StoreScansService`.
+1. `Security::StoreScansService` calls `Security::StoreGroupedScansService`.
+1. `Security::StoreGroupedScansService` calls `Security::StoreScanService`.
+1. `Security::StoreScanService` calls `Security::StoreFindingsMetadataService`.
+1. At this point we have `Security::Finding` objects **only**.
+
+At this point, the following things can happen to the `Security::Finding`:
+
+- Dismissal
+- Issue creation
+- Promotion to a Vulnerability
+
+If the pipeline ran on the default branch then the following, additional steps are done:
+
+1. `Security::StoreScansService` gets called and schedules `Security::StoreSecurityReportsWorker`.
+1. `Security::StoreSecurityReportsWorker` executes `Security::Ingestion::IngestReportsService`.
+1. `Security::Ingestion::IngestReportsService` takes all reports from a given Pipeline and calls `Security::Ingestion::IngestReportService` and then calls `Security::Ingestion::MarkAsResolvedService`.
+1. `Security::Ingestion::IngestReportService` calls `Security::Ingestion::IngestReportSliceService` which executes a number of tasks for a report slice.
+
+### Dismissal
+
+If you select `Dismiss vulnerability`, a Feedback is created. You can also dismiss it with a comment.
+
+#### After Feedback removal
+
+If there is only a Security Finding, a Vulnerability Finding and a Vulnerability get created. At the same time we create a `Vulnerabilities::StateTransition` record to indicate the Vulnerability was dismissed.
+
+### Issue creation
+
+If you select `Create issue`, a Vulnerabilities::Feedback record is created as well. The Feedback has a different `feedback_type` and an `issue_id` that’s not `NULL`.
+
+NOTE:
+Vulnerabilities::Feedback are in the process of being [deprecated](https://gitlab.com/groups/gitlab-org/-/epics/5629). This will later create a `Vulnerabilities::IssueLink` record.
+
+#### After Feedback removal
+
+If there's only a Security Finding, a Vulnerability Finding and a Vulnerability gets created. At the same time, we create an Issue and a Issue Link.
+
+## Promotion to a Vulnerability
+
+If the branch with a Security Finding gets merged into the default branch, all Security Findings get promoted into Vulnerabilities. Promotion is the process of creating Vulnerability Findings and Vulnerability records from those Security Findings.
+
+If there's a dismissal Feedback present for that Security Finding, the created Vulnerability is marked as dismissed.
+
+If there's an issue Feedback present for that Security Finding, we also create an Issue Link for that Vulnerability.
diff --git a/doc/subscriptions/gitlab_com/index.md b/doc/subscriptions/gitlab_com/index.md
index e338bad2ee9..2ba365a237f 100644
--- a/doc/subscriptions/gitlab_com/index.md
+++ b/doc/subscriptions/gitlab_com/index.md
@@ -392,3 +392,8 @@ If your credit card is declined when purchasing a GitLab subscription, possible
 
 Check with your financial institution to confirm if any of these reasons apply. If they don't
 apply, contact [GitLab Support](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=360000071293).
+
+### Unable to link subcription to namespace
+
+If you cannot link a subscription to your namespace, ensure that you have the Owner role
+for that namespace.
diff --git a/qa/Gemfile b/qa/Gemfile
index 77507e2b0b0..d71de41f89e 100644
--- a/qa/Gemfile
+++ b/qa/Gemfile
@@ -2,7 +2,7 @@
 
 source 'https://rubygems.org'
 
-gem 'gitlab-qa', '~> 8', '>= 8.9.0', require: 'gitlab/qa'
+gem 'gitlab-qa', '~> 8', '>= 8.10.0', require: 'gitlab/qa'
 gem 'activesupport', '~> 6.1.4.7' # This should stay in sync with the root's Gemfile
 gem 'allure-rspec', '~> 2.18.0'
 gem 'capybara', '~> 3.37.1'
diff --git a/qa/Gemfile.lock b/qa/Gemfile.lock
index f8a857e67ec..9e52677d3bf 100644
--- a/qa/Gemfile.lock
+++ b/qa/Gemfile.lock
@@ -100,14 +100,13 @@ GEM
     gitlab (4.18.0)
       httparty (~> 0.18)
       terminal-table (>= 1.5.1)
-    gitlab-qa (8.9.0)
+    gitlab-qa (8.10.0)
       activesupport (~> 6.1)
       gitlab (~> 4.18.0)
       http (~> 5.0)
       nokogiri (~> 1.10)
       rainbow (>= 3, < 4)
       table_print (= 1.5.7)
-      toxiproxy (~> 2.0.2)
       zeitwerk (>= 2, < 3)
     google-apis-compute_v1 (0.51.0)
       google-apis-core (>= 0.7.2, < 2.a)
@@ -269,7 +268,6 @@ GEM
     terminal-table (3.0.2)
       unicode-display_width (>= 1.1.1, < 3)
     timecop (0.9.5)
-    toxiproxy (2.0.2)
     trailblazer-option (0.1.2)
     tzinfo (2.0.5)
       concurrent-ruby (~> 1.0)
@@ -314,7 +312,7 @@ DEPENDENCIES
   faraday-retry (~> 2.0)
   fog-core (= 2.1.0)
   fog-google (~> 1.19)
-  gitlab-qa (~> 8, >= 8.9.0)
+  gitlab-qa (~> 8, >= 8.10.0)
   influxdb-client (~> 2.8)
   knapsack (~> 4.0)
   nokogiri (~> 1.13, >= 1.13.9)
diff --git a/spec/services/git/base_hooks_service_spec.rb b/spec/services/git/base_hooks_service_spec.rb
index 9c59b2d1c0b..e10cc7f6859 100644
--- a/spec/services/git/base_hooks_service_spec.rb
+++ b/spec/services/git/base_hooks_service_spec.rb
@@ -6,8 +6,9 @@ RSpec.describe Git::BaseHooksService do
   include RepoHelpers
   include GitHelpers
 
-  let(:user) { create(:user) }
-  let(:project) { create(:project, :repository) }
+  let_it_be(:user) { create(:user) }
+  let_it_be(:project) { create(:project, :repository) }
+
   let(:oldrev) { Gitlab::Git::BLANK_SHA }
   let(:newrev) { "8a2a6eb295bb170b34c24c76c49ed0e9b2eaf34b" } # gitlab-test: git rev-parse refs/tags/v1.1.0
   let(:ref) { 'refs/tags/v1.1.0' }