Relax gitlab-common dependency

.browserslistrc

@@ -1,15 +0,0 @@
-#
-# This list of browsers is a conservative definition, based on
-# https://docs.gitlab.com/ee/install/requirements.html#supported-web-browsers
-# with the following reasoning:
-#
-# - We should support the latest ESR of Firefox: 91, because it used quite a lot.
-# - We use Edge/Chrome >= 92 because they are about as old as the Firefox ESR
-# - Safari 14.1 because it is the current minor version of the previous major version
-#
-# See also this epic: https://gitlab.com/groups/gitlab-org/-/epics/3957
-#
-chrome >= 92
-edge >= 92
-firefox >= 91
-safari >= 14.1

.codeclimate.yml

@@ -1,6 +1,5 @@
 ---
-version: "2"
-plugins:
+engines:
   bundler-audit:
     enabled: true
   duplication:
@@ -9,22 +8,33 @@ plugins:
       languages:
         - ruby
         - javascript
-  rubocop:
-    enabled: false
-exclude_patterns:
-  - "{ee/,jh/,}config/"
-  - "{ee/,jh/,}db/"
-  - "**/log/"
-  - "**/node_modules/"
-  - "**/spec/"
-  - "**/tmp/"
-  - "**/vendor/"
+ratings:
+  paths:
+    - Gemfile.lock
+    - "**.erb"
+    - "**.haml"
+    - "**.rb"
+    - "**.rhtml"
+    - "**.slim"
+    - "**.inc"
+    - "**.js"
+    - "**.jsx"
+    - "**.module"
+exclude_paths:
+  - config/
+  - db/
+  - features/
+  - node_modules/
+  - spec/
+  - vendor/
   - .yarn-cache/
-  - backups/
+  - tmp/
   - builds/
   - coverage/
-  - file_hooks/
-  - plugins/
   - public/
   - shared/
   - webpack-report/
+  - log/
+  - backups/
+  - coverage-javascript/
+  - plugins/

.csscomb.json

@@ -0,0 +1,20 @@
+{
+  "exclude": [
+    "app/assets/stylesheets/framework/tw_bootstrap_variables.scss",
+    "app/assets/stylesheets/framework/fonts.scss"
+  ],
+  "always-semicolon": true,
+  "color-case": "lower",
+  "block-indent": "  ",
+  "color-shorthand": false,
+  "element-case": "lower",
+  "space-before-colon": "",
+  "space-after-colon": " ",
+  "space-before-combinator": " ",
+  "space-after-combinator": " ",
+  "space-between-declarations": "\n",
+  "space-before-opening-brace": " ",
+  "space-after-opening-brace": "\n",
+  "space-before-closing-brace": "\n",
+  "unitless-zero": true
+}

.dockerignore

@@ -1,11 +1,11 @@
 # `build_from_dir` can't find Dockerfile when `.dockerignore` is "*"
 # See https://github.com/swipely/docker-api/issues/484
-# Ignore all folders except the following files we need to build the QA image:
+# Ignore all folders except qa/, config/initializers and the root of lib/ since
+# the files we need to build the QA image are in these folders.
+# Following are the files we need:
 # - ./config/initializers/0_inject_enterprise_edition_module.rb
-# - ./config/feature_flags
-# - ./ee/config/feature_flags
 # - ./ee/app/models/license.rb
-# - ./lib/gitlab_edition.rb
+# - ./lib/gitlab.rb
 # - ./lib/gitlab/utils.rb
 # - ./qa/
 # - ./INSTALLATION_TYPE
@@ -28,9 +28,7 @@
 /docker/
 /ee/bin/
 /ee/changelogs/
-/ee/config/events/
-/ee/config/metrics/
-/ee/config/routes/
+/ee/config/
 /ee/db/
 /ee/fixtures/
 /ee/lib/
@@ -49,6 +47,7 @@
 /lib/registry/
 /lib/policy/
 /lib/feature/
+/lib/flowdock/
 /lib/generators/
 /lib/gitaly/
 /lib/api/

.editorconfig

@@ -1,34 +0,0 @@
-# top-most EditorConfig file
-root = true
-
-# Unix-style newlines with a newline ending every file
-[*]
-end_of_line = lf
-trim_trailing_whitespace = true
-insert_final_newline = true
-
-[*.{js,json,vue,scss,rb,haml,yml}]
-indent_size = 2
-
-[*.{js,json,vue,scss,rb,haml,yml,md}]
-indent_style = space
-charset = utf-8
-
-[*.{md,markdown,js.snap}]
-trim_trailing_whitespace = false
-
-[doc/**/*.md]
-trim_trailing_whitespace = true
-
-[*.rb]
-max_line_length = 120
-
-# Don't apply editorconfig rules to vendor/ resources
-[vendor/**]
-charset = unset
-end_of_line = unset
-indent_size = unset
-indent_style = unset
-insert_final_newline = unset
-trim_trailing_whitespace = unset
-max_line_length = unset

.eslintignore

@@ -1,13 +1,14 @@
 /app/assets/javascripts/locale/**/app.js
+/config/
 /builds/
 /coverage/
 /coverage-frontend/
+/coverage-javascript/
 /node_modules/
 /public/
+/scripts/
 /tmp/
 /vendor/
-/sitespeed-result/
-/fixtures/**/*.graphql
-# Storybook build artifacts
-/storybook/public
-spec/fixtures/**/*.graphql
+jest.config.js
+karma.config.js
+webpack.config.js

.eslintrc.yml

@@ -1,10 +1,8 @@
 extends:
-  - plugin:@gitlab/default
-  - plugin:@gitlab/i18n
+  - '@gitlab'
+  - plugin:promise/recommended
   - plugin:no-jquery/slim
   - plugin:no-jquery/deprecated-3.4
-  - plugin:no-unsanitized/DOM
-  - ./tooling/eslint-config/conditionally_ignore.js
 globals:
   __webpack_public_path__: true
   gl: false
@@ -12,194 +10,53 @@ globals:
   localStorage: false
   IS_EE: false
 plugins:
+  - import
+  - "@gitlab/i18n"
+  - "@gitlab/vue-i18n"
   - no-jquery
 settings:
   import/resolver:
     webpack:
       config: './config/webpack.config.js'
 rules:
+  "@gitlab/i18n/no-non-i18n-strings": error
+  "@gitlab/vue-i18n/no-bare-strings": error
+  "@gitlab/vue-i18n/no-bare-attribute-strings": error
   import/no-commonjs: error
-  import/no-default-export: off
   no-underscore-dangle:
     - error
     - allow:
         - __
         - _links
-  import/no-unresolved:
-    - error
-    - ignore:
-        # In FOSS, these import paths are rewritten using
-        # NormalModuleReplacementPlugin, which import/no-unresolved doesn't
-        # consider. See
-        # https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89831.
-        - '^(ee|jh)_component/'
   # Disabled for now, to make the airbnb-base 12.1.0 -> 13.1.0 update smoother
   no-else-return:
     - error
     - allowElseIf: true
+  import/no-unresolved:
+    - error
+    - ignore:
+        # https://gitlab.com/gitlab-org/gitlab/issues/38226
+        - '^ee_component/'
+  import/no-useless-path-segments: off
+  import/order: off
   lines-between-class-members: off
+  # Disabled for now, to make the plugin-vue 4.5 -> 5.0 update smoother
+  vue/no-confusing-v-for-v-if: error
+  vue/no-unused-components: off
+  vue/no-use-v-if-with-v-for: off
+  vue/no-v-html: off
+  vue/use-v-on-exact: off
+  no-jquery/no-animate: off
   # all offenses of no-jquery/no-animate-toggle are false positives ( $toast.show() )
   no-jquery/no-animate-toggle: off
   no-jquery/no-event-shorthand: off
+  no-jquery/no-fade: off
   no-jquery/no-serialize: error
+  no-jquery/no-sizzle: off
   promise/always-return: off
   promise/no-callback-in-promise: off
-  '@gitlab/no-global-event-off': error
-  '@gitlab/vue-no-new-non-primitive-in-template':
-    - error
-    - allowNames:
-        - 'class(es)?$'
-        - '^style$'
-        - '^to$'
-        - '^$'
-        - '^variables$'
-        - 'attrs?$'
-  no-param-reassign:
-    - error
-    - props: true
-      ignorePropertyModificationsFor:
-        - acc
-        - accumulator
-        - el
-        - element
-        - state
-      ignorePropertyModificationsForRegex:
-        - '^draft'
-  import/order:
-    - error
-    - groups:
-        - builtin
-        - external
-        - internal
-        - parent
-        - sibling
-        - index
-      pathGroups:
-        - pattern: '@sentry/browser'
-          group: external
-        - pattern: ~/**
-          group: internal
-        - pattern: emojis/**
-          group: internal
-        - pattern: '{ee_,jh_,}empty_states/**'
-          group: internal
-        - pattern: '{ee_,jh_,}icons/**'
-          group: internal
-        - pattern: '{ee_,jh_,}images/**'
-          group: internal
-        - pattern: vendor/**
-          group: internal
-        - pattern: shared_queries/**
-          group: internal
-        - pattern: '{ee_,}spec/**'
-          group: internal
-        - pattern: '{ee_,jh_,}jest/**'
-          group: internal
-        - pattern: '{ee_,jh_,any_}else_ce/**'
-          group: internal
-        - pattern: ee/**
-          group: internal
-        - pattern: '{ee_,jh_,}component/**'
-          group: internal
-        - pattern: jh_else_ee/**
-          group: internal
-        - pattern: jh/**
-          group: internal
-        - pattern: '{test_,}helpers/**'
-          group: internal
-        - pattern: test_fixtures/**
-          group: internal
-      alphabetize:
-        order: ignore
-  'no-restricted-syntax':
-    - error
-    - selector: ImportSpecifier[imported.name='GlSkeletonLoading']
-      message: 'Migrate to GlSkeletonLoader, or import GlDeprecatedSkeletonLoading.'
-    - selector: ImportSpecifier[imported.name='GlSafeHtmlDirective']
-      message: 'Use directive at ~/vue_shared/directives/safe_html.js instead.'
-  no-restricted-imports:
-    - error
-    - paths:
-        - name: mousetrap
-          message: 'Import { Mousetrap } from ~/lib/mousetrap instead.'
-  # See https://gitlab.com/gitlab-org/gitlab/-/issues/360551
-  vue/multi-word-component-names: off
-  unicorn/prefer-dom-node-dataset:
-    - error
-  no-unsanitized/method:
-    - error
-    - escape:
-        methods: 'sanitize'
-  no-unsanitized/property:
-    - error
-    - escape:
-        methods: 'sanitize'
 overrides:
-  - files:
-      - '{,ee/,jh/}spec/frontend*/**/*'
-    rules:
-      '@gitlab/require-i18n-strings': off
-      '@gitlab/no-runtime-template-compiler': off
-      'require-await': error
-      'import/no-dynamic-require': off
-      'no-import-assign': off
-      'no-restricted-syntax':
-        - error
-        - selector: CallExpression[callee.object.name=/(wrapper|vm)/][callee.property.name="setData"]
-          message: 'Avoid using "setData" on VTU wrapper'
-        - selector: MemberExpression[object.type!='ThisExpression'][property.type='Identifier'][property.name='$nextTick']
-          message: 'Using $nextTick from a component instance is discouraged. Import nextTick directly from the Vue package.'
-        - selector: Identifier[name='setImmediate']
-          message: 'Prefer explicit waitForPromises (or equivalent), or jest.runAllTimers (or equivalent) to vague setImmediate calls.'
-        - selector: ImportSpecifier[imported.name='GlSkeletonLoading']
-          message: 'Migrate to GlSkeletonLoader, or import GlDeprecatedSkeletonLoading.'
-        - selector: CallExpression[arguments.length=1][arguments.0.type='Literal'] CallExpression[callee.property.name='toBe'] CallExpression[callee.property.name='attributes'][arguments.length=1][arguments.0.value='disabled']
-          message: Avoid asserting disabled attribute exact value, because Vue.js 2 and Vue.js 3 renders it differently. Use toBeDefined / toBeUndefined instead
-      no-unsanitized/method: off
-      no-unsanitized/property: off
-  - files:
-      - 'config/**/*'
-      - 'scripts/**/*'
-      - '*.config.js'
-      - '*.config.*.js'
-      - 'jest_resolver.js'
-      - storybook/config/*.js
-    rules:
-      '@gitlab/require-i18n-strings': off
-      import/no-extraneous-dependencies: off
-      import/no-commonjs: off
-      import/no-nodejs-modules: off
-      filenames/match-regex: off
-      no-console: off
-  - files:
-      - '*.stories.js'
-    rules:
-      filenames/match-regex: off
-      '@gitlab/require-i18n-strings': off
-  - files:
-      - '*.graphql'
-    plugins:
-      - '@graphql-eslint'
-    parserOptions:
-      parser: '@graphql-eslint/eslint-plugin'
-      operations: '{,ee/,jh/}app/**/*.graphql'
-      schema: './tmp/tests/graphql/gitlab_schema_apollo.graphql'
-    rules:
-      filenames/match-regex: off
-      spaced-comment: off
-      # TODO: We need a way to include this rule + support ee_else_ce fragments
-      #'@graphql-eslint/unique-fragment-name': error
-      # TODO: Uncomment these rules when then `schema` is available
-      #'@graphql-eslint/fragments-on-composite-type': error
-      #'@graphql-eslint/known-argument-names': error
-      #'@graphql-eslint/known-type-names': error
-      '@graphql-eslint/no-anonymous-operations': error
-      '@graphql-eslint/unique-operation-name': error
-      '@graphql-eslint/require-id-when-available': error
-      '@graphql-eslint/no-unused-variables': error
-      '@graphql-eslint/no-unused-fragments': error
-      '@graphql-eslint/no-duplicate-fields': error
-  - files:
-      - '{,ee/}spec/contracts/consumer/**/*'
-    rules:
-      '@gitlab/require-i18n-strings': off
+  files:
+    - '**/spec/**/*'
+  rules:
+    "@gitlab/i18n/no-non-i18n-strings": off

.git-blame-ignore-revs

@@ -1,130 +0,0 @@
-# This file contains revisions to be ignored by git blame.
-# These revisions are expected to be formatting-only changes.
-#
-# Calling `git blame --ignore-revs-file .git-blame-ignore-revs` will
-# tell git blame to ignore changes made by these revisions when assigning
-# assigning blame, as if the change never happened.
-#
-# You can enable this as a default for your local repository by running
-# `git config blame.ignoreRevsFile .git-blame-ignore-revs`
-# This will probably be automatically picked by your IDE
-# (VSCode+GitLens and JetBrains products are confirmed to this)
-#
-# Important: if you are switching to the branch without this file,
-# `git blame` will fail with an error
-#
-# Guidelines:
-# - Only large automated refactorings are expected to be included in this file.
-#   Do not add new revision just because it feels unimportant
-# - When adding sinle revision use inline comment to link relevant issue/MR
-#   Example:
-##   d4a8b7307acc2dc8a8833ccfa65426ad28b3ffc9 # https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/60
-# - When adding multiple revisions precede each addition (this could be multiple revisions) with a link to
-#   line with word START and link to relevant issue/MR/epic and conclude with line END and link to the
-#   same issue/MR/epic
-#   Example:
-#   # START https://gitlab.com/gitlab-org/issues/12345
-#   6f0bd2d8a1e6cd2e794cd39976e9756e0c85ac66
-#   d53974df11dbc22cbea9dc7dcbc9896c25979a27
-#   ... <rest of the list>
-#   # END https://gitlab.com/gitlab-org/issues/12345
-# - Please append new lines to the end of the file, no matter of real chronological
-#   order of revisions
-# - Since this is using hashes for reformatting it might be a good idea to update
-#   this file in separate MR when relevant changes already landed in master. By
-#   utilizing this manner you will be safe from random rebase/squash issues
-# - Only put full 40-character hashes on this list
-
-# START https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/60
-f2d28d7ab8525944fda634241a780006594fbe1a
-94cfbb0ce38e893edda33ebc069bfa616a08a961
-b69f448f0685ad96edc474f75a17e0278a6d6011
-52907ac20c3af337544bdf18023730b9ada4b157
-d4a8b7307acc2dc8a8833ccfa65426ad28b3ffc9
-468cb9f0a4b88bf686f3e78250834f7c9d31ff76
-a536349d1d219f0b79a7a711d37dd1c705e49128
-6f0bd2d8a1e6cd2e794cd39976e9756e0c85ac66
-d53974df11dbc22cbea9dc7dcbc9896c25979a27
-818537524d13469cbc7ac5cb89263378b4cddca4
-bcbbcb2e708868099301ad5039badfba2128d47b
-a4c662da544b38b7e593eb79f24b24c5cb2f205e
-9aa1f6207a91a76940b34c921ce89894fcd74a06
-66da09846a17435f332296f73af44919ff2cfb52
-216f795bab0e8fbf6023f22f6e54cc07514a04ec
-e820c22892d207e138bdff717100e5240f8ffd94
-2f8dbd483242575f9ceca0a2947c9b21e5ab59a0
-e7d50054818ada29751539f548ef72f46deca8bb
-00827a74cf3bfef985ed6046fb2d42f29cbb19ac
-333bad893e98068053c888f6b020632f1c6f472e
-85af3689eea96b4d9131d80d8c5c8936de520074
-325fb305ea395a7f44ae1eea0a3e77e46e10c2b6
-e37a6d7aa61039734025474ce901f2907283e239
-dff561fa8c50e9b96aec9800b6b88ad6c7a2777b
-19b0ba7265cfb154505f74b6856e73662829af2e
-7c1fa749efcd59e81b565d6803285f6bd4bcefaf
-5c23cb94c5d1aed2a4b02b7c1f3e5a53a0aa4760
-c35cc92c80969e7c87bbcda7db6cbd04f6719589
-280a79c0ec4c1383e49480f3028f5b2025a2a76b
-e94556e9f9a145374bf26feb5e1823dae8a4004d
-b6a8d9baf700dbb3f780b27d9a9820c9cb7a346c
-9180eaee4d58a9e91c5f960148290b5271ba870c
-0fdc1fc0380056836dff7aba9be3b1e4b531daea
-157e117fcb530436561e3fb8faba6f751dc19e91
-7cfe360c9e5460a595dfe729e81cf404c1106638
-e3aca8c8f8488c55a199fc28595709b393f5040b
-3b1593f2d53b735299381ad0878959cbc2fc9923
-39bb37cc0d18f620006d85dfdff7b9a54077708e
-cdc1a4a8eec43e6a3df05403af8d05ab6ea7a213
-87ad67fef574cd102887f3dde98917f3b2bbcab8
-99bff4450248457ba877dec0388241625fb0144b
-d1b6d05c08e0730463084acd1a387cd9d6acea8b
-557c22a8242d1d7ccf2228b9b3156e2aa0dd05aa
-7f4e951ce8073b50a245ebe216a8961c88846cfa
-7dae714f23f423ff362d73e0d16da7b3a6cd721f
-cfb368284545a4bd1e759cfe9e3e3bde54a1ec6f
-aa653d5a380d88493050b22d84df36ae6df2cddd
-96ed4677c602e8f9c83b28fbc0d802aa26527ab8
-72c11eb5a15735dc52dcd893e9112a10444d46e4
-b48e14b89b94a1a87affabd09bc603a67fc6bb01
-d46581c1fbcef34cfdd85c6c542fb4ac1b974861
-ef02363c9cd41a9ce41443661efed1c0399c5551
-075a78b319466aff9e94149c41c286544af91782
-9f4b4de2df17268732ae198d5f48c9b99d071a35
-0a8f575e365804239d29b45562ca6594b9da59e9
-c04bd24738b1775b963bba3f78b48007fccce37e
-1173c801ea53c9d814fdf27d878f73a1702eb4e9
-a2f5e7395004c255ecaadef30d7a6b5bf453d372
-80f1ea7e3f11063a4f15bdd4a2e4a1ca7f770d87
-0e6e345f3b4dcb7b51403bcd096e6d3d294743f4
-06ee932e0844fa4cc91c15d5ca581de262d7bedd
-b3ece842f7c05230f77055ad11e3c4a07c34e1e9
-5ebea3a48831351169e0a312e9d6985b31c9975b
-02fad0bc640f5f91c748d692c01d6221c9b03b6e
-16d4df3c7130b5a0995fdc685b272bef65ff84d5
-281cc7306ab92d2e053d0bb2d79e4f3646b980f6
-1877bf550016eac9ecac53ec498ec83bdd24339c
-7e9741c59d1e3612017925a7b7cf0946bbdd6eca
-b282f7dda6d7e93fcb0f000db8aa6634ac8d1b88
-81e82875704ffb35842534433216e797c41f89c3
-4914a729d17efbe250ac2cab2153f72caef3a7b7
-792e349390327fa11721e2f744cafec3b05f51f4
-8869ce0866823b229a863e435aa108c5d4fcf448
-a223014afe14686a4e18a826fd0bac9bdaaf969b
-482d756cf69e3f0dd5997ea0e58d35c0eb694e35
-4700ac1d1da533cfefd50bd640db77a12c458fda
-21fa9ca4832cfb57f791ff057e7c5987349aa964
-8b24c8d64d9328e0884725a2075a4a21faa76842
-86ce5406c3b60757f40d4c434b5ce7dfc602a643
-da4eea76b3cc1d68d4bfd2705bb86e904d1b54bc
-8ac8a1f21a21840b53175e9f4a423b9ffa083f71
-ed189d0e9925eb08f3eb444176fad2614a3a4f83
-6e183d5016afc50e60892c7f1cf79035619c2deb
-9b1d8b4c2897792be067e33442ebf3ce0961a5d0
-57da632154bfc193224d5a290b9c2b6cbd7fa0ad
-1e3190b0049ba1b502918dc018681808b9203803
-0e334037bf0f93ff6f7bc922c48fa97556f39808
-07f5bc94bd983e77361c9a5020f8f229da3a465a
-888002a62696ba66d8eb49f1dfe83a5a49bdf421
-c152d51445d9d9dd7c2c328ca8c407fa5438d16b
-26b68c70df73289210aa600fa3c1fe45f05afee4
-# END https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/60

.gitattributes

@@ -1,4 +1,3 @@
 VERSION merge=ours
 Dangerfile gitlab-language=ruby
-*.rb diff=ruby
-workhorse/testdata/*.pdf -filter -diff -merge
+*.pdf filter=lfs diff=lfs merge=lfs -text

.gitignore

@@ -3,26 +3,22 @@
 *.mo
 *.edit.po
 *.rej
-.dir-locals.el
 .DS_Store
 .bundle
 .chef
 .directory
-.eslintcache
 /.envrc
 eslint-report.html
 /.gitlab_shell_secret
 .idea
-.nova
 /.vscode/*
 /.rbenv-version
 .rbx/
 /.ruby-gemset
 /.ruby-version
-/.tool-versions
 /.rvmrc
-/.secret
 .sass-cache/
+/.secret
 /.vagrant
 /.yarn-cache
 /.byebug_history
@@ -33,59 +29,51 @@ eslint-report.html
 /app/assets/javascripts/locale/**/app.js
 /backups/*
 /config/aws.yml
-/config/cable.yml
 /config/database*.yml
 /config/gitlab.yml
 /config/gitlab_ci.yml
-/config/Gitlab.gitlab-license
+/config/initializers/rack_attack.rb
 /config/initializers/smtp_settings.rb
 /config/initializers/relative_url.rb
 /config/resque.yml
-/config/redis.*.yml
-/config/redis.yml
+/config/redis.cache.yml
+/config/redis.queues.yml
+/config/redis.shared_state.yml
 /config/unicorn.rb
 /config/puma.rb
 /config/secrets.yml
 /config/sidekiq.yml
 /config/registry.key
 /coverage/*
+/coverage-javascript/
 /db/*.sqlite3
 /db/*.sqlite3-journal
 /db/data.yml
 /doc/code/*
 /dump.rdb
 /jsconfig.json
-/lefthook-local.yml
 /log/*.log*
-/node_modules
+/node_modules/
 /nohup.out
 /public/assets/
 /public/uploads.*
 /public/uploads/
-/public/sitemap.xml
-/public/sitemap.xml.gz
 /shared/artifacts/
 /spec/examples.txt
 /rails_best_practices_output.html
 /tags
 /vendor/bundle/*
-/vendor/package_metadata_db/
+/vendor/gitaly-ruby
 /builds*
 /.gitlab_workhorse_secret
 /.gitlab_pages_secret
-/.gitlab_kas_secret
-/.gitlab_suggested_reviewers_secret
 /webpack-report/
-/crystalball/
-/test_results/
-/deprecations/
 /knapsack/
-/query_recorder/
 /rspec_flaky/
-/rspec/
 /locale/**/LC_MESSAGES
 /locale/**/*.time_stamp
 /.rspec
+/.gitlab_pages_secret
 /.gitlab_smime_key
 /.gitlab_smime_cert
 package-lock.json
@@ -93,14 +81,7 @@ package-lock.json
 /coverage-frontend/
 jsdoc/
 **/tmp/rubocop_cache/**
+.overcommit.yml
 .projections.json
 /qa/.rakeTasks
 webpack-dev-server.json
-/.nvimrc
-.solargraph.yml
-ee/changelogs/unreleased-ee
-/sitespeed-result
-tags.lock
-tags.temp
-.stylelintcache
-.solargraph.yml

.gitlab-ci.yml

@@ -1,206 +1,48 @@
+image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-9.6-graphicsmagick-1.3.33"
+
 stages:
   - sync
-  - preflight
   - prepare
-  - build-images
-  - fixtures
-  - lint
+  - quick-test
   - test
   - post-test
+  - review-prepare
   - review
   - qa
   - post-qa
+  - notification
   - pages
-  - notify
-  - release-environments
-
-# always use `gitlab-org` runners, however
-# in cases where jobs require Docker-in-Docker, the job
-# definition must be extended with `.use-docker-in-docker`
-default:
-  image: $DEFAULT_CI_IMAGE
-  tags:
-    - gitlab-org
-  # All jobs are interruptible by default
-  interruptible: true
-  # Default job timeout set to 90m https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10520
-  timeout: 90m
-
-.default-ruby-variables: &default-ruby-variables
-  RUBY_VERSION: "3.0"
-  OMNIBUS_GITLAB_RUBY3_BUILD: "true"
-  OMNIBUS_GITLAB_CACHE_EDITION: "GITLAB_RUBY3"
-
-.backcompat-ruby-variables: &backcompat-ruby-variables
-  RUBY_VERSION: "2.7"
-  OMNIBUS_GITLAB_RUBY2_BUILD: "true"
-  OMNIBUS_GITLAB_CACHE_EDITION: "GITLAB_RUBY2"
-
-.default-branch-pipeline-failure-variables: &default-branch-pipeline-failure-variables
-  CREATE_ISSUES_FOR_FAILING_TESTS: "true"
-
-workflow:
-  name: '$PIPELINE_NAME'
-  rules:
-    # If `$FORCE_GITLAB_CI` is set, create a pipeline.
-    - if: '$FORCE_GITLAB_CI'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION forced pipeline'
-    # As part of the process of creating RCs automatically, we update stable
-    # branches with the changes of the most recent production deployment. The
-    # merge requests used for this merge a branch release-tools/X into a stable
-    # branch. For these merge requests we don't want to run any pipelines, as
-    # they serve no purpose and will run anyway when the changes are merged.
-    - if: '$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^release-tools\/\d+\.\d+\.\d+-rc\d+$/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^[\d-]+-stable(-ee)?$/ && $CI_PROJECT_PATH == "gitlab-org/gitlab"'
-      when: never
-    # For merge requests running exclusively in Ruby 2.7
-    - if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby2/'
-      variables:
-        <<: *backcompat-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_MERGE_REQUEST_EVENT_TYPE MR pipeline'
-        NO_SOURCEMAPS: 'true'
-    - if: '$CI_MERGE_REQUEST_LABELS =~ /Community contribution/'
-      variables:
-        <<: *default-ruby-variables
-        GITLAB_DEPENDENCY_PROXY_ADDRESS: ""
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_MERGE_REQUEST_EVENT_TYPE MR pipeline (community contribution)'
-        NO_SOURCEMAPS: 'true'
-    # For (detached) merge request pipelines.
-    - if: '$CI_MERGE_REQUEST_IID'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_MERGE_REQUEST_EVENT_TYPE MR pipeline'
-        NO_SOURCEMAPS: 'true'
-    # For the scheduled pipelines, we set specific variables.
-    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "schedule"'
-      variables:
-        <<: *default-ruby-variables
-        <<: *default-branch-pipeline-failure-variables
-        CRYSTALBALL: "true"
-        PIPELINE_NAME: 'Scheduled Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
-    # Run pipelines for ruby2 branch
-    - if: '$CI_COMMIT_BRANCH == "ruby2" && $CI_PIPELINE_SOURCE == "schedule"'
-      variables:
-        <<: *backcompat-ruby-variables
-        PIPELINE_NAME: 'Scheduled Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
-    # This work around https://gitlab.com/gitlab-org/gitlab/-/issues/332411 whichs prevents usage of dependency proxy
-    # when pipeline is triggered by a project access token.
-    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $GITLAB_USER_LOGIN =~ /project_\d+_bot\d*/'
-      variables:
-        <<: *default-ruby-variables
-        <<: *default-branch-pipeline-failure-variables
-        GITLAB_DEPENDENCY_PROXY_ADDRESS: ""
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline (triggered by a project token)'
-    # For `$CI_DEFAULT_BRANCH` branch, create a pipeline (this includes on schedules, pushes, merges, etc.).
-    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
-      variables:
-        <<: *default-ruby-variables
-        <<: *default-branch-pipeline-failure-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
-    # For tags, create a pipeline.
-    - if: '$CI_COMMIT_TAG'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_TAG tag pipeline'
-    # If `$GITLAB_INTERNAL` isn't set, don't create a pipeline.
-    - if: '$GITLAB_INTERNAL == null'
-      when: never
-    # For stable, auto-deploy, and security branches, create a pipeline.
-    - if: '$CI_COMMIT_BRANCH =~ /^[\d-]+-stable(-ee)?$/'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
-    - if: '$CI_COMMIT_BRANCH =~ /^\d+-\d+-auto-deploy-\d+$/'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
-    - if: '$CI_COMMIT_BRANCH =~ /^security\//'
-      variables:
-        <<: *default-ruby-variables
-        PIPELINE_NAME: 'Ruby $RUBY_VERSION $CI_COMMIT_BRANCH branch pipeline'
 
 variables:
-  PG_VERSION: "13"
-  DEFAULT_CI_IMAGE: "${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}.patched-golang-${GO_VERSION}-rust-${RUST_VERSION}-node-16.14-postgresql-${PG_VERSION}:rubygems-${RUBYGEMS_VERSION}-git-2.36-lfs-2.9-chrome-${CHROME_VERSION}-yarn-1.22-graphicsmagick-1.3.36"
-  # We set $GITLAB_DEPENDENCY_PROXY to another variable (since it's set at the group level and has higher precedence than .gitlab-ci.yml)
-  # so that we can override $GITLAB_DEPENDENCY_PROXY_ADDRESS in workflow rules.
-  GITLAB_DEPENDENCY_PROXY_ADDRESS: "${GITLAB_DEPENDENCY_PROXY}"
   RAILS_ENV: "test"
   NODE_ENV: "test"
-  BUNDLE_WITHOUT: "production:development"
-  BUNDLE_INSTALL_FLAGS: "--jobs=$(nproc) --retry=3"
-  BUNDLE_FROZEN: "true"
-  # we override the max_old_space_size to prevent OOM errors
-  NODE_OPTIONS: --max_old_space_size=4096
+  SIMPLECOV: "true"
   GIT_DEPTH: "20"
-  # 'GIT_STRATEGY: clone' optimizes the pack-objects cache hit ratio
-  GIT_STRATEGY: "clone"
   GIT_SUBMODULE_STRATEGY: "none"
   GET_SOURCES_ATTEMPTS: "3"
-  DEBIAN_VERSION: "bullseye"
-  UBI_VERSION: "8.6"
-  CHROME_VERSION: "109"
-  DOCKER_VERSION: "23.0.1"
-  RUBY_VERSION: "2.7"
-  RUBYGEMS_VERSION: "3.4"
-  GO_VERSION: "1.19"
-  RUST_VERSION: "1.65"
-
-  FLAKY_RSPEC_SUITE_REPORT_PATH: rspec/flaky/report-suite.json
-  FRONTEND_FIXTURES_MAPPING_PATH: crystalball/frontend_fixtures_mapping.json
-  GITLAB_WORKHORSE_FOLDER: "gitlab-workhorse"
-  JUNIT_RESULT_FILE: rspec/junit_rspec.xml
-  JUNIT_RETRY_FILE: rspec/junit_rspec-retry.xml
   KNAPSACK_RSPEC_SUITE_REPORT_PATH: knapsack/report-master.json
-  RSPEC_CHANGED_FILES_PATH: rspec/changed_files.txt
-  RSPEC_FOSS_IMPACT_PIPELINE_TEMPLATE_YML: .gitlab/ci/rails/rspec-foss-impact.gitlab-ci.yml.erb
-  RSPEC_PREDICTIVE_PIPELINE_TEMPLATE_YML: .gitlab/ci/rails/rspec-predictive.gitlab-ci.yml.erb
-  RSPEC_LAST_RUN_RESULTS_FILE: rspec/rspec_last_run_results.txt
-  RSPEC_MATCHING_JS_FILES_PATH: rspec/js_matching_files.txt
-  RSPEC_VIEWS_INCLUDING_PARTIALS_PATH: rspec/views_including_partials.txt
-  RSPEC_MATCHING_TESTS_PATH: rspec/matching_tests.txt
-  RSPEC_MATCHING_TESTS_FOSS_PATH: rspec/matching_tests-foss.txt
-  RSPEC_MATCHING_TESTS_EE_PATH: rspec/matching_tests-ee.txt
-  RSPEC_PACKED_TESTS_MAPPING_PATH: crystalball/packed-mapping.json
-  RSPEC_PROFILING_FOLDER_PATH: rspec/profiling
-  RSPEC_TESTS_MAPPING_PATH: crystalball/mapping.json
-  RSPEC_FAST_QUARANTINE_LOCAL_PATH: rspec/fast_quarantine-gitlab.txt
-  TMP_TEST_FOLDER: "${CI_PROJECT_DIR}/tmp/tests"
-  TMP_TEST_GITLAB_WORKHORSE_PATH: "${TMP_TEST_FOLDER}/${GITLAB_WORKHORSE_FOLDER}"
-
+  FLAKY_RSPEC_SUITE_REPORT_PATH: rspec_flaky/report-suite.json
+  BUILD_ASSETS_IMAGE: "false"
   ES_JAVA_OPTS: "-Xms256m -Xmx256m"
   ELASTIC_URL: "http://elastic:changeme@elasticsearch:9200"
-  BUNDLER_CHECKSUM_VERIFICATION_OPT_IN: "1"
-  CACHE_CLASSES: "true"
-  CHECK_PRECOMPILED_ASSETS: "true"
-  FF_USE_FASTZIP: "true"
-  RETRY_FAILED_TESTS_IN_NEW_PROCESS: "true"
-  # Run with decomposed databases by default
-  DECOMPOSED_DB: "true"
 
-  DOCS_REVIEW_APPS_DOMAIN: "docs.gitlab-review.app"
-  DOCS_GITLAB_REPO_SUFFIX: "ee"
-
-  REVIEW_APPS_IMAGE: "${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/ruby-3.0:gcloud-383-kubectl-1.23-helm-3.5"
-  REVIEW_APPS_DOMAIN: "gitlab-review.app"
-  REVIEW_APPS_GCP_PROJECT: "gitlab-review-apps"
-  REVIEW_APPS_GCP_REGION: "us-central1"
-
-  CACHE_ASSETS_AS_PACKAGE: "true"
-  BUILD_ASSETS_IMAGE: "true"  # Set it to "false" to disable assets image building, used in `build-assets-image`
-  SIMPLECOV: "true"
-
-  REGISTRY_HOST: "registry.gitlab.com"
-  REGISTRY_GROUP: "gitlab-org"
-
-  # Disable useless network connections when installing some NPM packages.
-  # See https://gitlab.com/gitlab-com/gl-security/engineering-and-research/inventory/-/issues/827#note_1203181407
-  DISABLE_OPENCOLLECTIVE: "true"
-
-  # This is set at the gitlab-org level, but we set it here for forks
-  DANGER_DO_NOT_POST_INVALID_DANGERFILE_ERROR: "1"
+after_script:
+  - date
 
 include:
-  - local: .gitlab/ci/*.gitlab-ci.yml
-  - remote: 'https://gitlab.com/gitlab-org/frontend/untamper-my-lockfile/-/raw/main/templates/merge_request_pipelines.yml'
+  - local: .gitlab/ci/cache-repo.gitlab-ci.yml
+  - local: .gitlab/ci/cng.gitlab-ci.yml
+  - local: .gitlab/ci/docs.gitlab-ci.yml
+  - local: .gitlab/ci/frontend.gitlab-ci.yml
+  - local: .gitlab/ci/global.gitlab-ci.yml
+  - local: .gitlab/ci/memory.gitlab-ci.yml
+  - local: .gitlab/ci/notifications.gitlab-ci.yml
+  - local: .gitlab/ci/pages.gitlab-ci.yml
+  - local: .gitlab/ci/qa.gitlab-ci.yml
+  - local: .gitlab/ci/reports.gitlab-ci.yml
+  - local: .gitlab/ci/rails.gitlab-ci.yml
+  - local: .gitlab/ci/review.gitlab-ci.yml
+  - local: .gitlab/ci/setup.gitlab-ci.yml
+  - local: .gitlab/ci/test-metadata.gitlab-ci.yml
+  - local: .gitlab/ci/yaml.gitlab-ci.yml
+  - local: .gitlab/ci/releases.gitlab-ci.yml

.gitlab/agents/review-apps/config.yaml

@@ -1 +0,0 @@
-# This empty file is used for agent-based integration with Kubernetes

.gitlab/changelog_config.yml

@@ -1,45 +0,0 @@
----
-# Settings for generating changelogs using the GitLab API. See
-# https://docs.gitlab.com/ee/api/repositories.html#generate-changelog-data for
-# more information.
-categories:
-  added: Added
-  fixed: Fixed
-  changed: Changed
-  deprecated: Deprecated
-  removed: Removed
-  security: Security
-  performance: Performance
-  other: Other
-include_groups:
-  - gitlab-org/gitlab-core-team/community-members
-template: |
-  {% 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 commit.trailers.MR %}\
-   ([merge request]({{ commit.trailers.MR }}))\
-  {% else %}\
-  {% if merge_request %}\
-   ([merge request]({{ merge_request.reference }}))\
-  {% end %}\
-  {% end %}\
-  {% if commit.trailers.EE %}\
-   **GitLab Enterprise Edition**\
-  {% end %}
-
-  {% end %}
-
-  {% end %}
-  {% else %}
-  No changes.
-  {% end %}
-# The tag format for gitlab-org/gitlab is vX.Y.Z(-rcX)-ee. The -ee prefix would
-# be treated as a pre-release identifier, which can result in the wrong tag
-# being used as the starting point of a changelog commit range. The custom regex
-# here is used to ensure we find the correct tag.
-tag_regex: '^v(?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)-ee$'

.gitlab/ci/_skip.yml

@@ -1,11 +0,0 @@
-# no-op pipeline template for skipping whole child pipeline execution
-
-no-op:
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}alpine:latest
-  stage: test
-  variables:
-    GIT_STRATEGY: none
-  script:
-    - echo "${SKIP_MESSAGE:-no-op run, nothing will be executed!}"
-  rules:
-    - when: always

.gitlab/ci/as-if-jh.gitlab-ci.yml

@@ -1,106 +0,0 @@
-.as-if-jh-sandbox-variables:
-  variables:
-    AS_IF_JH_BRANCH: "as-if-jh/${CI_COMMIT_REF_NAME}"
-    SANDBOX_REPOSITORY: "https://dummy:${AS_IF_JH_TOKEN}@gitlab.com/gitlab-org-sandbox/gitlab-jh-validation.git"
-
-.shared-as-if-jh:
-  extends:
-    - .as-if-jh-sandbox-variables
-  variables:
-    GITLAB_JH_MIRROR_PROJECT: "33019816"
-    JH_FILES_TO_COMMIT: "jh package.json yarn.lock"
-
-add-jh-files:
-  extends:
-    - .shared-as-if-jh
-    - .as-if-jh:rules:prepare-as-if-jh
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}
-  stage: prepare
-  before_script:
-    - source ./scripts/utils.sh
-    - source ./scripts/setup/as-if-jh.sh
-    - install_gitlab_gem
-  script:
-    - prepare_jh_branch
-    - download_jh_path ${JH_FILES_TO_COMMIT}
-    - echoinfo "Changes after downloading JiHu files:"
-    - git diff
-    - git status
-  artifacts:
-    expire_in: 2d
-    paths:
-      # This should match JH_FILES_TO_COMMIT
-      - jh/
-      - package.json
-      - yarn.lock
-
-prepare-as-if-jh-branch:
-  extends:
-    - .shared-as-if-jh
-    - .as-if-jh:rules:prepare-as-if-jh
-  stage: prepare
-  needs:
-    - add-jh-files
-  variables:
-    # We can't apply --filter=tree:0 for runner to set up the repository,
-    # so instead we tell runner to not clone anything, and we set up the
-    # repository by ourselves.
-    GIT_STRATEGY: "none"
-  before_script:
-    - git clone --filter=tree:0 "${CI_REPOSITORY_URL}" gitlab
-    # We should checkout before moving/changing files
-    - cd gitlab
-    - git checkout -b "${AS_IF_JH_BRANCH}" "${CI_COMMIT_SHA}"
-    - cd ..
-    - mv ${JH_FILES_TO_COMMIT} gitlab/
-  script:
-    - cd gitlab
-    - git add ${JH_FILES_TO_COMMIT}
-    - git commit -m 'Add JH files'  # TODO: Mark which SHA we add
-    - git push -f "${SANDBOX_REPOSITORY}" "${AS_IF_JH_BRANCH}"
-
-sync-as-if-jh-branch:
-  extends:
-    - .as-if-jh-sandbox-variables
-    - .as-if-jh:rules:sync-as-if-jh
-  stage: prepare
-  needs: ["prepare-as-if-jh-branch"]
-  inherit:
-    variables:
-      # From .gitlab-ci.yml for the default Docker image and cache
-      - DEFAULT_CI_IMAGE
-      - REGISTRY_HOST
-      - REGISTRY_GROUP
-      - DEBIAN_VERSION
-      - RUBY_VERSION
-      - GO_VERSION
-      - RUST_VERSION
-      - PG_VERSION
-      - RUBYGEMS_VERSION
-      - CHROME_VERSION
-      - NODE_ENV
-  variables:
-    MERGE_FROM: "${CI_COMMIT_SHA}"  # This is used in https://jihulab.com/gitlab-cn/gitlab/-/blob/e98bcb37aea4cfe1e78e1daef1b58b5f732cf289/jh/bin/build_packagejson where we run in https://gitlab.com/gitlab-org-sandbox/gitlab-jh-validation
-  trigger:
-    # What this runs can be found at:
-    # https://gitlab.com/gitlab-org-sandbox/gitlab-jh-validation/-/blob/as-if-jh-code-sync/jh/.gitlab-ci.yml
-    project: gitlab-org-sandbox/gitlab-jh-validation
-    branch: as-if-jh-code-sync
-    strategy: depend
-
-start-as-if-jh:
-  extends:
-    - .as-if-jh:rules:start-as-if-jh
-  stage: prepare
-  needs:
-    - job: "prepare-as-if-jh-branch"
-    - job: "sync-as-if-jh-branch"
-      optional: true
-  inherit:
-    variables: false
-  variables:
-    FORCE_GITLAB_CI: "true"  # TODO: Trigger a merge request pipeline
-  trigger:
-    project: gitlab-org-sandbox/gitlab-jh-validation
-    branch: as-if-jh/${CI_COMMIT_REF_NAME}
-    strategy: depend

.gitlab/ci/build-images.gitlab-ci.yml

@@ -1,80 +0,0 @@
-.base-image-build:
-  extends: .use-kaniko
-  variables:
-    GIT_LFS_SKIP_SMUDGE: 1  # disable pulling objects from lfs
-  retry: 2
-
-.base-image-build-buildx:
-  extends: .use-buildx
-  variables:
-    GIT_LFS_SKIP_SMUDGE: 1  # disable pulling objects from lfs
-  retry: 2
-
-# This image is used by:
-# - The `review-qa-*` jobs
-# - The `e2e:package-and-test` child pipeline test stage jobs
-# See https://docs.gitlab.com/ee/development/testing_guide/end_to_end/index.html#testing-code-in-merge-requests for more details.
-build-qa-image:
-  extends:
-    - .base-image-build-buildx
-    - .build-images:rules:build-qa-image
-  stage: build-images
-  needs: []
-  script:
-    - run_timed_command "scripts/build_qa_image"
-
-build-qa-image as-if-foss:
-  extends:
-    - build-qa-image
-    - .as-if-foss
-    - .build-images:rules:build-qa-image-as-if-foss
-
-# Prepares an image with GDK configured based on code in master. This saves some time in MRs because some installation
-# and complilation will have already been performed.
-build-qa-on-gdk-master-image:
-  extends:
-    - .base-image-build-buildx
-    - .build-images:rules:build-qa-on-gdk-master-image
-  tags:
-    - e2e
-  stage: build-images
-  needs: []
-  variables:
-    QA_GDK_IMAGE: "${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab-qa-gdk"
-  before_script:
-    - !reference [.use-buildx, before_script]
-    - sysctl -n -w fs.inotify.max_user_watches=524288
-  script:
-    - |
-      docker buildx build \
-        --cache-to=type=inline \
-        --cache-from ${QA_GDK_IMAGE}:master \
-        --platform=${ARCH:-amd64} \
-        --add-host gdk.test:127.0.0.1 \
-        --tag ${QA_GDK_IMAGE}:master \
-        --file="qa/gdk/Dockerfile" \
-        --push \
-        ${CI_PROJECT_DIR}
-
-build-assets-image:
-  extends:
-    - .base-image-build
-    - .build-images:rules:build-assets-image
-  stage: build-images
-  needs: ["compile-production-assets"]
-  script:
-    - skopeo login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
-    - run_timed_command "scripts/build_assets_image"
-  artifacts:
-    expire_in: 7 days
-    paths:
-      # The `cached-assets-hash.txt` file is used in `review-build-cng-env` (`.gitlab/ci/review-apps/main.gitlab-ci.yml`)
-      # to pass the assets image tag to the CNG downstream pipeline.
-      - cached-assets-hash.txt
-
-build-assets-image as-if-foss:
-  extends:
-    - build-assets-image
-    - .as-if-foss
-    - .build-images:rules:build-assets-image-as-if-foss
-  needs: ["compile-production-assets as-if-foss"]

.gitlab/ci/cache-repo.gitlab-ci.yml

@@ -0,0 +1,33 @@
+# Builds a cached .tar.gz of the master branch with full history and
+# uploads it to Google Cloud Storage. This archive is downloaded by a
+# script defined by a CI/CD variable named CI_PRE_CLONE_SCRIPT. This has
+# two benefits:
+#
+# 1. It speeds up builds. A 800 MB download only takes seconds.
+# 2. It significantly reduces load on the file server. Smaller deltas
+#    means less time spent in git pack-objects.
+#
+# Since the destination directory of the archive depends on the project
+# ID, this is only run on GitLab.com.
+#
+# CI_REPO_CACHE_CREDENTIALS contains the Google Cloud service account
+# JSON for uploading to the gitlab-ci-git-repo-cache bucket. These
+# credentials are stored in the Production vault.
+#
+# Note that this bucket should be located in the same continent as the
+# runner, or network egress charges will apply:
+# https://cloud.google.com/storage/pricing
+cache-repo:
+  extends:
+    - .only:variables_refs-canonical-dot-com-schedules
+  image: gcr.io/google.com/cloudsdktool/cloud-sdk:alpine
+  stage: sync
+  allow_failure: true
+  variables:
+    GIT_DEPTH: 0
+    TAR_FILENAME: /tmp/gitlab-master.tar
+  script:
+    - gcloud auth activate-service-account --key-file=$CI_REPO_CACHE_CREDENTIALS
+    - tar cf $TAR_FILENAME .
+    - gzip $TAR_FILENAME
+    - gsutil cp $TAR_FILENAME.gz gs://gitlab-ci-git-repo-cache/project-$CI_PROJECT_ID/gitlab-master.tar.gz

.gitlab/ci/caching.gitlab-ci.yml

@@ -1,64 +0,0 @@
-cache-workhorse:
-  extends:
-    - .default-retry
-    - .default-before_script
-    - .rails-cache
-    - .setup-test-env-cache
-    - .caching:rules:cache-workhorse
-  stage: prepare
-  variables:
-    SETUP_DB: "false"
-  script:
-    - source scripts/gitlab_component_helpers.sh
-    - 'gitlab_workhorse_archive_doesnt_exist || { echoinfo "INFO: Exiting early as package exists."; exit 0; }'
-    - run_timed_command "scripts/setup-test-env"
-    - run_timed_command "select_gitlab_workhorse_essentials"
-    - run_timed_command "create_gitlab_workhorse_package"
-    - run_timed_command "upload_gitlab_workhorse_package"
-  artifacts:
-    expire_in: 7d
-    paths:
-      - ${TMP_TEST_GITLAB_WORKHORSE_PATH}/
-
-.cache-assets-base:
-  extends:
-    - .compile-assets-base
-    - .assets-compile-cache
-    - .caching:rules:cache-assets
-  stage: prepare
-  variables:
-    WEBPACK_REPORT: "false"
-  script:
-    - yarn_install_script
-    - export GITLAB_ASSETS_HASH=$(bundle exec rake gitlab:assets:hash_sum)
-    - source scripts/gitlab_component_helpers.sh
-    - 'gitlab_assets_archive_doesnt_exist || { echoinfo "INFO: Exiting early as package exists."; exit 0; }'
-    - assets_compile_script
-    - echo -n "${GITLAB_ASSETS_HASH}" > "cached-assets-hash.txt"
-    - run_timed_command "create_gitlab_assets_package"
-    - run_timed_command "upload_gitlab_assets_package"
-
-cache-assets:test:
-  extends: .cache-assets-base
-
-cache-assets:test as-if-foss:
-  extends:
-    - .cache-assets-base
-    - .as-if-foss
-
-cache-assets:production:
-  extends:
-    - .cache-assets-base
-    - .production
-
-packages-cleanup:
-  extends:
-    - .default-retry
-    - .caching:rules:packages-cleanup
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}
-  stage: prepare
-  before_script:
-    - source scripts/utils.sh
-    - install_gitlab_gem
-  script:
-    - scripts/packages/automated_cleanup.rb

.gitlab/ci/ci-templates.gitlab-ci.yml

@@ -1,13 +0,0 @@
-templates-shellcheck:
-  extends:
-    - .ci-templates:rules:shellcheck
-    - .default-before_script
-    - .default-retry
-    - .ruby-cache
-    - .use-pg14
-  stage: test
-  needs:
-    - setup-test-env
-  script:
-    - apt update && apt install -y shellcheck=0.7.1-1+deb11u1
-    - bundle exec scripts/lint_templates_bash.rb

.gitlab/ci/cng.gitlab-ci.yml

@@ -0,0 +1,15 @@
+cloud-native-image:
+  extends: .only:variables-canonical-dot-com
+  image: ruby:2.6-alpine
+  dependencies: []
+  stage: post-test
+  allow_failure: true
+  variables:
+    GIT_DEPTH: "1"
+  when: manual
+  script:
+    - install_gitlab_gem
+    - CNG_PROJECT_PATH="gitlab-org/build/CNG" BUILD_TRIGGER_TOKEN=$CI_JOB_TOKEN ./scripts/trigger-build cng
+  only:
+    refs:
+      - tags

.gitlab/ci/database.gitlab-ci.yml

@@ -1,147 +0,0 @@
-include:
-  - local: .gitlab/ci/rails/shared.gitlab-ci.yml
-
-db:rollback single-db-ci-connection:
-  extends:
-    - db:rollback
-    - .single-db-ci-connection
-    - .rails:rules:single-db-ci-connection
-
-db:migrate:reset single-db-ci-connection:
-  extends:
-    - db:migrate:reset
-    - .single-db-ci-connection
-    - .rails:rules:single-db-ci-connection
-
-db:check-schema-single-db-ci-connection:
-  extends:
-    - db:check-schema
-    - .single-db-ci-connection
-    - .rails:rules:single-db-ci-connection
-
-db:post_deployment_migrations_validator-single-db-ci-connection:
-  extends:
-    - db:post_deployment_migrations_validator
-    - .single-db-ci-connection
-    - .rails:rules:db:check-migrations-single-db-ci-connection
-
-db:backup_and_restore single-db-ci-connection:
-  extends:
-    - db:backup_and_restore
-    - .single-db-ci-connection
-    - .rails:rules:db-backup
-
-db:rollback:
-  extends:
-    - .db-job-base
-    - .rails:rules:db-rollback
-  script:
-    - bundle exec rake db:migrate VERSION=20220502173045  # 14.10 (last 14.x version)
-    - bundle exec rake db:migrate
-
-db:rollback single-db:
-  extends:
-    - db:rollback
-    - .single-db
-    - .rails:rules:single-db
-
-db:migrate:reset:
-  extends: .db-job-base
-  script:
-    - bundle exec rake db:migrate:reset
-
-db:migrate:reset single-db:
-  extends:
-    - db:migrate:reset
-    - .single-db
-    - .rails:rules:single-db
-
-db:check-schema:
-  extends:
-    - .db-job-base
-    - .rails:rules:ee-mr-and-default-branch-only
-  script:
-    - run_timed_command "bundle exec rake db:drop db:create db:migrate"
-
-db:check-schema-single-db:
-  extends:
-    - db:check-schema
-    - .single-db
-    - .rails:rules:single-db
-
-db:check-migrations:
-  extends:
-    - .db-job-base
-    - .rails:rules:ee-and-foss-mr-with-migration
-  script:
-    - git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME:$CI_MERGE_REQUEST_TARGET_BRANCH_NAME --depth 20
-    - scripts/validate_migration_schema
-  allow_failure: true
-
-db:check-migrations-single-db:
-  extends:
-    - db:check-migrations
-    - .single-db
-    - .rails:rules:db:check-migrations-single-db
-
-db:post_deployment_migrations_validator:
-  extends:
-    - .db-job-base
-    - .rails:rules:ee-and-foss-mr-with-migration
-  script:
-    - git fetch origin $CI_MERGE_REQUEST_TARGET_BRANCH_NAME:$CI_MERGE_REQUEST_TARGET_BRANCH_NAME --depth 20
-    - scripts/post_deployment_migrations_validator
-  allow_failure: true
-
-db:post_deployment_migrations_validator-single-db:
-  extends:
-    - db:post_deployment_migrations_validator
-    - .single-db
-    - .rails:rules:db:check-migrations-single-db
-
-db:migrate-non-superuser:
-  extends:
-    - .db-job-base
-    - .rails:rules:ee-and-foss-mr-with-migration
-  script:
-    - bundle exec rake gitlab:db:reset_as_non_superuser
-
-db:gitlabcom-database-testing:
-  extends: .rails:rules:db:gitlabcom-database-testing
-  stage: test
-  image: ruby:${RUBY_VERSION}-alpine
-  needs: []
-  allow_failure: true
-  script:
-    - source scripts/utils.sh
-    - install_gitlab_gem
-    - ./scripts/trigger-build.rb gitlab-com-database-testing
-
-db:backup_and_restore:
-  extends:
-    - .db-job-base
-    - .rails:rules:db-backup
-  variables:
-    SETUP_DB: "false"
-    GITLAB_ASSUME_YES: "1"
-  script:
-    - . scripts/prepare_build.sh
-    - bundle exec rake db:drop db:create db:schema:load db:seed_fu
-    - mkdir -p tmp/tests/public/uploads tmp/tests/{artifacts,pages,lfs-objects,terraform_state,registry,packages}
-    - bundle exec rake gitlab:backup:create
-    - date
-    - bundle exec rake gitlab:backup:restore
-
-db:backup_and_restore single-db:
-  extends:
-    - db:backup_and_restore
-    - .single-db
-    - .rails:rules:db-backup
-
-db:rollback geo:
-  extends:
-    - db:rollback
-    - .rails:rules:ee-only-migration
-  script:
-    - bundle exec rake db:migrate:geo VERSION=20170627195211
-    - bundle exec rake db:migrate:geo

.gitlab/ci/dev-fixtures.gitlab-ci.yml

@@ -1,35 +0,0 @@
-.run-dev-fixtures:
-  extends:
-    - .default-retry
-    - .rails-cache
-    - .default-before_script
-    - .use-pg13
-  stage: test
-  needs: ["setup-test-env"]
-  variables:
-    FIXTURE_PATH: "db/fixtures/development"
-    SEED_VSA: "true"
-    SEED_PRODUCTIVITY_ANALYTICS: "true"
-    VSA_ISSUE_COUNT: 1
-    SIZE: 0  # number of external projects to fork, requires network connection
-    # SEED_NESTED_GROUPS: "false" # requires network connection
-
-.run-dev-fixtures-script: &run-dev-fixtures-script
-  - section_start "gitaly-test-spawn" "Spawning Gitaly"; scripts/gitaly-test-spawn; section_end "gitaly-test-spawn";  # Do not use 'bundle exec' here
-  - section_start "seeding-db" "Seeding DB"; bundle exec rake db:seed_fu; section_end "seeding-db";
-
-run-dev-fixtures:
-  extends:
-    - .run-dev-fixtures
-    - .dev-fixtures:rules:ee-and-foss
-  script:
-    - *run-dev-fixtures-script
-
-run-dev-fixtures-ee:
-  extends:
-    - .run-dev-fixtures
-    - .dev-fixtures:rules:ee-only
-    - .use-pg13-es7-ee
-  script:
-    - cp ee/db/fixtures/development/* $FIXTURE_PATH
-    - *run-dev-fixtures-script

.gitlab/ci/docs.gitlab-ci.yml

@@ -1,126 +1,85 @@
 .review-docs:
   extends:
+    - .default-tags
     - .default-retry
-    - .docs:rules:review-docs
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-alpine
+    - .only:variables-canonical-dot-com
+    - .only:changes-docs
+  only:
+    refs:
+      - merge_requests
+  image: ruby:2.6-alpine
   stage: review
-  needs: []
+  dependencies: []
   variables:
-    # We're cloning the repo instead of downloading the script for now
-    # because some repos are private and CI_JOB_TOKEN cannot access files.
-    # See https://gitlab.com/gitlab-org/gitlab/issues/191273
-    GIT_DEPTH: 1
-    # By default, deploy the Review App using the `main` branch of the `gitlab-org/gitlab-docs` project
-    DOCS_BRANCH: main
+    GIT_STRATEGY: none
   environment:
-    name: review-docs/mr-${CI_MERGE_REQUEST_IID}
+    name: review-docs/$DOCS_GITLAB_REPO_SUFFIX-$CI_MERGE_REQUEST_IID
     # DOCS_REVIEW_APPS_DOMAIN and DOCS_GITLAB_REPO_SUFFIX are CI variables
     # Discussion: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14236/diffs#note_40140693
-    auto_stop_in: 2 weeks
-    url: http://${DOCS_BRANCH}-${DOCS_GITLAB_REPO_SUFFIX}-${CI_MERGE_REQUEST_IID}.${DOCS_REVIEW_APPS_DOMAIN}/${DOCS_GITLAB_REPO_SUFFIX}
+    url: http://docs-preview-$DOCS_GITLAB_REPO_SUFFIX-$CI_MERGE_REQUEST_IID.$DOCS_REVIEW_APPS_DOMAIN/$DOCS_GITLAB_REPO_SUFFIX
     on_stop: review-docs-cleanup
   before_script:
-    - source ./scripts/utils.sh
-    - install_gitlab_gem
+    # We don't clone the repo by using GIT_STRATEGY: none and only download the
+    # single script we need here so it's much faster than cloning.
+    - apk add --update openssl
+    - wget $CI_PROJECT_URL/raw/$CI_COMMIT_SHA/scripts/trigger-build-docs
+    - chmod 755 trigger-build-docs
+    - gem install httparty --no-document --version 0.17.3
+    - gem install gitlab --no-document --version 4.13.0
 
 # Always trigger a docs build in gitlab-docs only on docs-only branches.
 # Useful to preview the docs changes live.
 review-docs-deploy:
   extends: .review-docs
   script:
-    - ./scripts/trigger-build.rb docs deploy
+    - ./trigger-build-docs deploy
+  when: manual
 
 # Cleanup remote environment of gitlab-docs
 review-docs-cleanup:
   extends: .review-docs
   environment:
-    name: review-docs/mr-${CI_MERGE_REQUEST_IID}
+    name: review-docs/$DOCS_GITLAB_REPO_SUFFIX-$CI_MERGE_REQUEST_IID
     action: stop
   script:
-    - ./scripts/trigger-build.rb docs cleanup
+    - ./trigger-build-docs cleanup
+  when: manual
 
-docs-lint links:
+docs lint:
   extends:
-    - .docs:rules:docs-lint
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-docs/lint-html:alpine-3.17-ruby-3.2.1-f53af000
-  stage: lint
-  needs: []
+    - .default-tags
+    - .default-retry
+    - .default-only
+    - .only:changes-docs
+  image: "registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-docs-lint"
+  stage: test
+  dependencies: []
   script:
+    - scripts/lint-doc.sh
+    # Lint Markdown
+    - markdownlint --config .markdownlint.json 'doc/**/*.md'
     # Prepare docs for build
-    # The path must be 'ee/' because we have hardcoded links relying on it
-    # https://gitlab.com/gitlab-org/gitlab-docs/-/blob/887850752fc0e72856da6632db132f005ba77f16/content/index.erb#L44-63
-    - mv doc/ /tmp/gitlab-docs/content/ee
+    - mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX
     - cd /tmp/gitlab-docs
     # Build HTML from Markdown
     - bundle exec nanoc
-    # Check the internal links and anchors (in parallel)
-    - "parallel time bundle exec nanoc check ::: internal_links internal_anchors"
+    # Check the internal links
+    - bundle exec nanoc check internal_links
+    # Check the internal anchor links
+    - bundle exec nanoc check internal_anchors
 
-.docs-markdown-lint-image:
-  # When updating the image version here, update it in /scripts/lint-doc.sh too.
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-docs/lint-markdown:alpine-3.17-vale-2.24.0-markdownlint-0.33.0-markdownlint2-0.6.0
-
-docs-lint markdown:
+graphql-reference-verify:
   extends:
+    - .only-ee
+    - .default-tags
     - .default-retry
-    - .docs:rules:docs-lint
-    - .docs-markdown-lint-image
-    - .yarn-cache
-  stage: lint
-  needs: []
-  script:
-    - source ./scripts/utils.sh
-    - yarn_install_script
-    - scripts/lint-doc.sh
-
-docs-lint blueprint:
-  extends:
-    - .default-retry
-    - .docs:rules:docs-blueprints-lint
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-slim
-  stage: lint
-  needs: []
-  script:
-    - scripts/lint-docs-blueprints.rb
-
-docs code_quality:
-  extends:
-    - .reports:rules:code_quality
-    - .docs-markdown-lint-image
-  stage: lint
-  needs: []
-  dependencies: []
-  allow_failure: true
-  script:
-    - vale --output=doc/.vale/vale-json.tmpl --minAlertLevel warning doc > gl-code-quality-report-docs.json || exit_code=$?
-  artifacts:
-    reports:
-      codequality: gl-code-quality-report-docs.json
-    paths:
-      - gl-code-quality-report-docs.json
-    expire_in: 2 weeks
-    when: always
-
-ui-docs-links lint:
-  extends:
-    - .docs:rules:docs-lint
-    - .static-analysis-base
-    - .ruby-cache
-  stage: lint
-  needs: []
-  script:
-    - bundle exec haml-lint -i DocumentationLinks
-
-docs-lint deprecations-and-removals:
-  variables:
-    SETUP_DB: "false"
-  extends:
-    - .default-retry
-    - .rails-cache
+    - .default-cache
+    - .default-only
     - .default-before_script
-    - .docs:rules:deprecations-and-removals
-  stage: lint
-  needs: []
+    - .only:changes-code-backstage-qa
+    - .use-pg9
+  stage: test
+  needs: ["setup-test-env"]
   script:
-    - bundle exec rake gitlab:docs:check_deprecations
-    - bundle exec rake gitlab:docs:check_removals
+    - bundle exec rake gitlab:graphql:check_docs
+    - bundle exec rake gitlab:graphql:check_schema

.gitlab/ci/frontend.gitlab-ci.yml

@@ -1,255 +1,186 @@
-.compile-assets-base:
+.assets-compile-cache:
+  cache:
+    paths:
+      - vendor/ruby/
+      - .yarn-cache/
+      - tmp/cache/assets/sprockets
+
+.gitlab:assets:compile-metadata:
   extends:
+    - .default-tags
     - .default-retry
+    - .default-only
     - .default-before_script
     - .assets-compile-cache
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}-node-16.14:rubygems-${RUBYGEMS_VERSION}-git-2.33-lfs-2.9-yarn-1.22-graphicsmagick-1.3.36
+    - .only:changes-code-backstage-qa
+  image: registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-graphicsmagick-1.3.33-docker-19.03.1
+  stage: test
+  dependencies: ["setup-test-env"]
+  needs: ["setup-test-env"]
+  services:
+    - docker:19.03.0-dind
   variables:
+    NODE_ENV: "production"
+    RAILS_ENV: "production"
     SETUP_DB: "false"
-    WEBPACK_VENDOR_DLL: "true"
-    # Disable warnings in browserslist which can break on backports
-    # https://github.com/browserslist/browserslist/blob/a287ec6/node.js#L367-L384
-    BROWSERSLIST_IGNORE_OLD_DATA: "true"
-    WEBPACK_COMPILE_LOG_PATH: "tmp/webpack-output.log"
-  stage: prepare
-  script:
-    - yarn_install_script
-    - export GITLAB_ASSETS_HASH=$(bin/rake gitlab:assets:hash_sum)
-    - 'echo "CACHE_ASSETS_AS_PACKAGE: ${CACHE_ASSETS_AS_PACKAGE}"'
-    # The new strategy to cache assets as generic packages is experimental and can be disabled by removing the `CACHE_ASSETS_AS_PACKAGE` variable
-    - |
-      if [[ "${CACHE_ASSETS_AS_PACKAGE}" == "true" ]]; then
-        source scripts/gitlab_component_helpers.sh
-
-        if ! gitlab_assets_archive_doesnt_exist; then
-          # We remove all assets from the native cache as they could pollute the fresh assets from the package
-          rm -rf public/assets/ app/assets/javascripts/locale/**/app.js
-          run_timed_command "download_and_extract_gitlab_assets"
-        fi
-      fi
-    - assets_compile_script
-    - echo -n "${GITLAB_ASSETS_HASH}" > "cached-assets-hash.txt"
-
-compile-production-assets:
-  extends:
-    - .compile-assets-base
-    - .production
-    - .frontend:rules:compile-production-assets
+    SKIP_STORAGE_VALIDATION: "true"
+    WEBPACK_REPORT: "true"
+    # we override the max_old_space_size to prevent OOM errors
+    NODE_OPTIONS: --max_old_space_size=3584
+    DOCKER_DRIVER: overlay2
+    DOCKER_HOST: tcp://docker:2375
+  cache:
+    key: "assets-compile:production:vendor_ruby:.yarn-cache:tmp_cache_assets_sprockets:v6"
   artifacts:
     name: webpack-report
     expire_in: 31d
     paths:
-      # These assets are used in multiple locations:
-      # - in `build-assets-image` job to create assets image for packaging systems
-      # - GitLab UI for integration tests: https://gitlab.com/gitlab-org/gitlab-ui/-/blob/e88493b3c855aea30bf60baee692a64606b0eb1e/.storybook/preview-head.pug#L1
-      - cached-assets-hash.txt
+      - webpack-report/
       - public/assets/
-      - "${WEBPACK_COMPILE_LOG_PATH}"
-    when: always
-  after_script:
+  script:
+    - node --version
+    - retry yarn install --frozen-lockfile --production --cache-folder .yarn-cache --prefer-offline
+    - free -m
+    - retry bundle exec rake gitlab:assets:compile
+    - time scripts/build_assets_image
+    - scripts/clean-old-cached-assets
     - rm -f /etc/apt/sources.list.d/google*.list  # We don't need to update Chrome here
+  only:
+    variables:
+      - $CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/  # Matches the gitlab-org group and its subgroups
+      - $CI_SERVER_HOST == "dev.gitlab.org"
+  tags:
+    - gitlab-org
+    - docker
 
-compile-production-assets as-if-foss:
-  extends:
-    - compile-production-assets
-    - .as-if-foss
-    - .frontend:rules:compile-production-assets-as-if-foss
+gitlab:assets:compile pull-push-cache:
+  extends: .gitlab:assets:compile-metadata
+  only:
+    refs:
+      - master
+  cache:
+    policy: pull-push
 
-compile-test-assets:
+gitlab:assets:compile pull-cache:
+  extends: .gitlab:assets:compile-metadata
+  cache:
+    policy: pull
+
+.compile-assets-metadata:
   extends:
-    - .compile-assets-base
-    - .frontend:rules:compile-test-assets
+    - .default-tags
+    - .default-retry
+    - .default-only
+    - .default-before_script
+    - .assets-compile-cache
+    - .only:changes-code-backstage-qa
+  stage: prepare
+  script:
+    - node --version
+    - retry yarn install --frozen-lockfile --cache-folder .yarn-cache --prefer-offline
+    - free -m
+    - retry bundle exec rake gitlab:assets:compile
+    - scripts/clean-old-cached-assets
+  variables:
+    SETUP_DB: "false"
+    # we override the max_old_space_size to prevent OOM errors
+    NODE_OPTIONS: --max_old_space_size=3584
+  cache:
+    key: "assets-compile:v7"
   artifacts:
     expire_in: 7d
     paths:
-      - public/assets/
-      - node_modules/@gitlab/svgs/dist/icons.json  # app/helpers/icons_helper.rb uses this file
-      - "${WEBPACK_COMPILE_LOG_PATH}"
-    when: always
+      - node_modules
+      - public/assets
 
-compile-test-assets as-if-foss:
-  extends:
-    - compile-test-assets
-    - .frontend:rules:compile-test-assets-as-if-foss
-    - .as-if-foss
+compile-assets pull-push-cache:
+  extends: .compile-assets-metadata
+  only:
+    refs:
+      - master
+  cache:
+    policy: pull-push
 
-update-assets-compile-production-cache:
-  extends:
-    - compile-production-assets
-    - .assets-compile-cache-push
-    - .shared:rules:update-cache
-  stage: prepare
-  artifacts: {}  # This job's purpose is only to update the cache.
+compile-assets pull-push-cache foss:
+  extends: [".compile-assets-metadata", ".only-ee-as-if-foss"]
+  only:
+    refs:
+      - master
+  cache:
+    policy: pull-push
+    key: "assets-compile:v7:foss"
 
-update-assets-compile-test-cache:
-  extends:
-    - compile-test-assets
-    - .assets-compile-cache-push
-    - .shared:rules:update-cache
-  stage: prepare
-  script:
-    - !reference [compile-test-assets, script]
-    - echo -n "${GITLAB_ASSETS_HASH}" > "cached-assets-hash.txt"
-  artifacts: {}  # This job's purpose is only to update the cache.
+compile-assets pull-cache:
+  extends: .compile-assets-metadata
+  cache:
+    policy: pull
 
-update-storybook-yarn-cache:
-  extends:
-    - .default-retry
-    - .default-utils-before_script
-    - .storybook-yarn-cache-push
-    - .shared:rules:update-cache
-  stage: prepare
-  script:
-    - yarn_install_script
-
-retrieve-frontend-fixtures:
-  variables:
-    SETUP_DB: "false"
-  extends:
-    - .default-retry
-    - .frontend:rules:default-frontend-jobs
-  stage: prepare
-  script:
-    - source scripts/utils.sh
-    - source scripts/gitlab_component_helpers.sh
-    - install_gitlab_gem
-    - export_fixtures_sha_for_download
-    - |
-      if check_fixtures_download; then
-        run_timed_command "download_and_extract_fixtures"
-      fi
-  artifacts:
-    paths:
-      - tmp/tests/frontend/
-
-# Download fixtures only when a merge request contains changes to only JS files
-# and fixtures are present in the package registry.
-.frontend-fixtures-base:
+compile-assets pull-cache foss:
+  extends: [".compile-assets-metadata", ".only-ee-as-if-foss"]
+  cache:
+    policy: pull
+    key: "assets-compile:v7:foss"
+
+.only-code-frontend-job-base:
   extends:
+    - .default-tags
     - .default-retry
+    - .default-cache
+    - .default-only
     - .default-before_script
-    - .rails-cache
-    - .use-pg13
-  stage: fixtures
-  needs: ["setup-test-env", "retrieve-tests-metadata", "retrieve-frontend-fixtures"]
+    - .only:changes-code-backstage
+    - .use-pg9
+  stage: test
+  needs: ["setup-test-env", "compile-assets pull-cache"]
+  dependencies: ["setup-test-env", "compile-assets pull-cache"]
+
+.karma-base:
+  extends: .only-code-frontend-job-base
   variables:
-    # Don't add `CRYSTALBALL: "false"` here as we're enabling Crystalball for scheduled pipelines (in `.gitlab-ci.yml`), so that we get coverage data
-    # for the `frontend fixture RSpec files` that will be added to the Crystalball mapping in `update-tests-metadata`.
-    # More information in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74003.
-    WEBPACK_VENDOR_DLL: "true"
+    # we override the max_old_space_size to prevent OOM errors
+    NODE_OPTIONS: --max_old_space_size=3584
   script:
-    - source scripts/gitlab_component_helpers.sh
-    - |
-      if check_fixtures_reuse; then
-        echoinfo "INFO: Reusing frontend fixtures from 'retrieve-frontend-fixtures'."
-        exit 0
-      fi
-    - run_timed_command "gem install knapsack --no-document"
-    - section_start "gitaly-test-spawn" "Spawning Gitaly"; scripts/gitaly-test-spawn; section_end "gitaly-test-spawn";  # Do not use 'bundle exec' here
-    - source ./scripts/rspec_helpers.sh
-    - rspec_paralellized_job
+    - export BABEL_ENV=coverage CHROME_LOG_FILE=chrome_debug.log
+    - date
+    - scripts/gitaly-test-spawn
+    - date
+    - bundle exec rake karma
+
+karma:
+  extends: .karma-base
+  coverage: '/^Statements *: (\d+\.\d+%)/'
   artifacts:
-    name: frontend-fixtures
+    name: coverage-javascript
     expire_in: 31d
     when: always
     paths:
+      - chrome_debug.log
+      - coverage-javascript/
       - tmp/tests/frontend/
-      - knapsack/
-      - crystalball/
+    reports:
+      junit: junit_karma.xml
 
-# Builds FOSS, and EE fixtures in the EE project.
-# Builds FOSS fixtures in the FOSS project.
-rspec-all frontend_fixture:
+karma-foss:
   extends:
-    - .frontend-fixtures-base
-    - .frontend:rules:default-frontend-jobs
-  needs:
-    - !reference [.frontend-fixtures-base, needs]
-    - "compile-test-assets"
-  parallel: 7
-
-# Builds FOSS fixtures in the EE project, with the `ee/` folder removed (due to `as-if-foss`).
-rspec-all frontend_fixture as-if-foss:
-  extends:
-    - .frontend-fixtures-base
-    - .frontend:rules:frontend_fixture-as-if-foss
-    - .as-if-foss
-  variables:
-    # We explicitely disable Crystalball here so as even in scheduled pipelines we don't need it since it's already enabled for `rspec-all frontend_fixture` there.
-    CRYSTALBALL: "false"
-    WEBPACK_VENDOR_DLL: "true"
-    KNAPSACK_GENERATE_REPORT: ""
-    FLAKY_RSPEC_GENERATE_REPORT: ""
-  needs:
-    - !reference [.frontend-fixtures-base, needs]
-    - "compile-test-assets as-if-foss"
-
-# Uploads EE fixtures in the EE project.
-# Uploads FOSS fixtures in the FOSS project.
-upload-frontend-fixtures:
-  extends:
-    - .frontend-fixtures-base
-    - .frontend:rules:upload-frontend-fixtures
-  stage: fixtures
-  needs: ["rspec-all frontend_fixture"]
-  script:
-    - source scripts/utils.sh
-    - source scripts/gitlab_component_helpers.sh
-    - export_fixtures_sha_for_upload
-    - 'fixtures_archive_doesnt_exist || { echoinfo "INFO: Exiting early as package exists."; exit 0; }'
-    - run_timed_command "create_fixtures_package"
-    - run_timed_command "upload_fixtures_package"
-  artifacts: {}
-
-graphql-schema-dump:
-  variables:
-    SETUP_DB: "false"
-  extends:
-    - .default-retry
-    - .rails-cache
-    - .default-before_script
-    - .frontend:rules:default-frontend-jobs
-  stage: fixtures
-  needs: []
-  script:
-    - bundle exec rake gitlab:graphql:schema:dump
-  artifacts:
-    name: graphql-schema
-    paths:
-      - tmp/tests/graphql/gitlab_schema.graphql
-      - tmp/tests/graphql/gitlab_schema.json
-
-graphql-schema-dump as-if-foss:
-  extends:
-    - graphql-schema-dump
-    - .frontend:rules:default-frontend-jobs-as-if-foss
-    - .as-if-foss
-
-.frontend-test-base:
-  extends:
-    - .default-retry
-    - .yarn-cache
-  variables:
-    # Disable warnings in browserslist which can break on backports
-    # https://github.com/browserslist/browserslist/blob/a287ec6/node.js#L367-L384
-    BROWSERSLIST_IGNORE_OLD_DATA: "true"
-    USE_BUNDLE_INSTALL: "false"
-    SETUP_DB: "false"
-  before_script:
-    - !reference [.default-before_script, before_script]
-    - yarn_install_script
-  stage: test
+    - .karma-base
+    - .only-ee-as-if-foss
 
 .jest-base:
-  extends: .frontend-test-base
+  extends: .only-code-frontend-job-base
   script:
-    - run_timed_command "yarn jest:ci"
+    - scripts/gitaly-test-spawn
+    - date
+    - bundle exec rake frontend:fixtures
+    - date
+    - yarn jest --ci --coverage
+  cache:
+    key: jest
+    paths:
+      - tmp/jest/jest/
+    policy: pull-push
 
 jest:
-  extends:
-    - .jest-base
-    - .frontend:rules:jest
-  needs: ["rspec-all frontend_fixture"]
+  extends: .jest-base
   artifacts:
     name: coverage-frontend
     expire_in: 31d
@@ -260,165 +191,65 @@ jest:
       - tmp/tests/frontend/
     reports:
       junit: junit_jest.xml
-  parallel: 7
 
-jest predictive:
-  extends:
-    - jest
-    - .frontend:rules:jest:predictive
-  needs:
-    - !reference [jest, needs]
-    - "detect-tests"
-  script:
-    - if [[ -s "$RSPEC_CHANGED_FILES_PATH" ]] || [[ -s "$RSPEC_MATCHING_JS_FILES_PATH" ]]; then run_timed_command "yarn jest:ci:predictive"; fi
-
-jest as-if-foss:
+jest-foss:
   extends:
     - .jest-base
-    - .frontend:rules:jest:as-if-foss
-    - .as-if-foss
-  needs: ["rspec-all frontend_fixture as-if-foss"]
-  parallel: 4
+    - .only-ee-as-if-foss
+  cache:
+    policy: pull
 
-jest predictive as-if-foss:
-  extends:
-    - .jest-base
-    - .frontend:rules:jest:predictive:as-if-foss
-    - .as-if-foss
-  needs:
-    - "rspec-all frontend_fixture as-if-foss"
-    - "detect-tests"
-  script:
-    - if [[ -s "$RSPEC_CHANGED_FILES_PATH" ]] || [[ -s "$RSPEC_MATCHING_JS_FILES_PATH" ]]; then run_timed_command "yarn jest:ci:predictive"; fi
-
-jest-integration:
-  extends:
-    - .frontend-test-base
-    - .frontend:rules:default-frontend-jobs
-  script:
-    - run_timed_command "yarn jest:integration --ci"
-  needs: ["rspec-all frontend_fixture", "graphql-schema-dump"]
-
-coverage-frontend:
+.qa-frontend-node:
   extends:
+    - .default-tags
     - .default-retry
-    - .default-utils-before_script
-    - .yarn-cache
-    - .frontend:rules:coverage-frontend
-  needs:
-    - job: "jest"
-      optional: true
-    - job: "jest predictive"
-      optional: true
-  stage: post-test
-  script:
-    - yarn_install_script
-    - run_timed_command "yarn node scripts/frontend/merge_coverage_frontend.js"
-    # Removing the individual coverage results, as we just merged them.
-    - if ls coverage-frontend/jest-* > /dev/null 2>&1; then
-        rm -r coverage-frontend/jest-*;
-      fi
-  coverage: '/^Statements\s*:\s*?(\d+(?:\.\d+)?)%/'
-  artifacts:
-    name: coverage-frontend
-    expire_in: 31d
+    - .default-cache
+    - .default-only
+    - .only:changes-code-backstage
+  stage: test
+  dependencies: []
+  cache:
+    key: "$CI_JOB_NAME"
     paths:
-      - coverage-frontend/
-    reports:
-      coverage_report:
-        coverage_format: cobertura
-        path: coverage-frontend/cobertura-coverage.xml
+      - .yarn-cache/
+    policy: pull-push
+  script:
+    - date
+    - yarn install --frozen-lockfile --cache-folder .yarn-cache --prefer-offline
+    - date
+    - yarn run webpack-prod
+
+qa-frontend-node:8:
+  extends: .qa-frontend-node
+  image: node:carbon
+
+qa-frontend-node:10:
+  extends: .qa-frontend-node
+  image: node:dubnium
+
+qa-frontend-node:latest:
+  extends: .qa-frontend-node
+  image: node:latest
+  allow_failure: true
 
 webpack-dev-server:
   extends:
+    - .default-tags
     - .default-retry
-    - .default-utils-before_script
-    - .yarn-cache
-    - .frontend:rules:default-frontend-jobs
+    - .default-cache
+    - .default-only
+    - .only:changes-code-backstage
   stage: test
-  needs: []
+  needs: ["setup-test-env", "compile-assets pull-cache"]
+  dependencies: ["setup-test-env", "compile-assets pull-cache"]
   variables:
     WEBPACK_MEMORY_TEST: "true"
     WEBPACK_VENDOR_DLL: "true"
   script:
-    - yarn_install_script
-    - run_timed_command "retry yarn webpack-vendor"
-    - run_timed_command "node --expose-gc node_modules/.bin/webpack-dev-server --config config/webpack.config.js"
+    - yarn webpack-vendor
+    - node --expose-gc node_modules/.bin/webpack-dev-server --config config/webpack.config.js
   artifacts:
     name: webpack-dev-server
     expire_in: 31d
     paths:
       - webpack-dev-server.json
-
-bundle-size-review:
-  extends:
-    - .default-retry
-    - .default-utils-before_script
-    - .assets-compile-cache
-    - .frontend:rules:bundle-size-review
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:danger
-  stage: test
-  needs: []
-  script:
-    - yarn_install_script
-    - scripts/bundle_size_review
-  artifacts:
-    when: always
-    name: bundle-size-review
-    expire_in: 31d
-    paths:
-      - bundle-size-review/
-
-.startup-css-check-base:
-  extends:
-    - .frontend-test-base
-  script:
-    - run_timed_command "yarn generate:startup_css"
-    - yarn check:startup_css
-
-startup-css-check:
-  extends:
-    - .startup-css-check-base
-    - .frontend:rules:default-frontend-jobs
-  needs: ["compile-test-assets", "rspec-all frontend_fixture"]
-
-startup-css-check as-if-foss:
-  extends:
-    - .startup-css-check-base
-    - .as-if-foss
-    - .frontend:rules:default-frontend-jobs-as-if-foss
-  needs:
-    - job: "compile-test-assets as-if-foss"
-    - job: "rspec-all frontend_fixture as-if-foss"
-
-.compile-storybook-base:
-  extends:
-    - .frontend-test-base
-    - .storybook-yarn-cache
-  script:
-    - run_timed_command "retry yarn run storybook:install --frozen-lockfile"
-    - run_timed_command "yarn run storybook:build"
-  needs: ["graphql-schema-dump"]
-
-compile-storybook:
-  extends:
-    - .compile-storybook-base
-    - .frontend:rules:default-frontend-jobs
-  needs:
-    - !reference [.compile-storybook-base, needs]
-    - job: "rspec-all frontend_fixture"
-  artifacts:
-    name: storybook
-    expire_in: 31d
-    when: always
-    paths:
-      - storybook/public
-
-compile-storybook as-if-foss:
-  extends:
-    - .compile-storybook-base
-    - .as-if-foss
-    - .frontend:rules:default-frontend-jobs-as-if-foss
-  needs:
-    - job: "graphql-schema-dump as-if-foss"
-    - job: "rspec-all frontend_fixture as-if-foss"

.gitlab/ci/glfm.gitlab-ci.yml

@@ -1,16 +0,0 @@
-glfm-verify:
-  extends:
-    - .rails-job-base
-    - .glfm:rules:glfm-verify
-    - .use-pg13
-  stage: test
-  needs: ["setup-test-env"]
-  script:
-    - !reference [.base-script, script]
-    - bundle exec scripts/glfm/verify-all-generated-files-are-up-to-date.rb
-  artifacts:
-    name: changed-files
-    when: on_failure
-    expire_in: 31d
-    paths:
-      - glfm_specification/

.gitlab/ci/global.gitlab-ci.yml

@@ -1,445 +1,235 @@
+.default-tags:
+  tags:
+    - gitlab-org
+
 .default-retry:
   retry:
     max: 2  # This is confusing but this means "3 runs at max".
     when:
-      - api_failure
-      - data_integrity_failure
-      - job_execution_timeout
-      - runner_system_failure
-      - scheduler_failure
-      - stuck_or_timeout_failure
       - unknown_failure
-
-.default-utils-before_script:
-  before_script:
-    - echo $FOSS_ONLY
-    - '[ "$FOSS_ONLY" = "1" ] && rm -rf ee/ qa/spec/ee/ qa/qa/specs/features/ee/ qa/qa/ee/ qa/qa/ee.rb'
-    - export GOPATH=$CI_PROJECT_DIR/.go
-    - mkdir -p $GOPATH
-    - source scripts/utils.sh
+      - api_failure
+      - runner_system_failure
 
 .default-before_script:
   before_script:
-    - !reference [.default-utils-before_script, before_script]
-    - source scripts/prepare_build.sh
-
-.production:
-  variables:
-    RAILS_ENV: "production"
-    NODE_ENV: "production"
-    GITLAB_ALLOW_SEPARATE_CI_DATABASE: "true"
-
-.ruby-gems-cache: &ruby-gems-cache
-  key: "ruby-gems-debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}"
-  paths:
-    - vendor/ruby/
-  policy: pull
-
-.ruby-gems-cache-push: &ruby-gems-cache-push
-  <<: *ruby-gems-cache
-  policy: push  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up.
-
-.gitaly-binaries-cache: &gitaly-binaries-cache
-  key:
-    files:
-      - GITALY_SERVER_VERSION
-      - lib/gitlab/setup_helper.rb
-    prefix: "gitaly-binaries-debian-${DEBIAN_VERSION}"
-  paths:
-    - ${TMP_TEST_FOLDER}/gitaly/_build/bin/
-    - ${TMP_TEST_FOLDER}/gitaly/_build/deps/git/install/
-    - ${TMP_TEST_FOLDER}/gitaly/config.toml
-    - ${TMP_TEST_FOLDER}/gitaly/gitaly2.config.toml
-    - ${TMP_TEST_FOLDER}/gitaly/internal/
-    - ${TMP_TEST_FOLDER}/gitaly/run/
-    - ${TMP_TEST_FOLDER}/gitaly/run2/
-    - ${TMP_TEST_FOLDER}/gitaly/Makefile
-    - ${TMP_TEST_FOLDER}/gitaly/praefect.config.toml
-    - ${TMP_TEST_FOLDER}/gitaly/praefect-db.config.toml
-  policy: pull
-
-.go-pkg-cache: &go-pkg-cache
-  key: "go-pkg-${DEBIAN_VERSION}"
-  paths:
-    - .go/pkg/mod/
-  policy: pull
-
-.go-pkg-cache-push: &go-pkg-cache-push
-  <<: *go-pkg-cache
-  policy: push  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up.
-
-.node-modules-cache: &node-modules-cache
-  key: "node-modules-${DEBIAN_VERSION}-${NODE_ENV}"
-  paths:
-    - node_modules/
-    - tmp/cache/webpack-dlls/
-  policy: pull
-
-.node-modules-cache-push: &node-modules-cache-push
-  <<: *node-modules-cache
-  policy: push  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up.
-
-.assets-tmp-cache: &assets-tmp-cache
-  key: "assets-tmp-debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}-node-${NODE_ENV}-v1"
-  paths:
-    - tmp/cache/assets/sprockets/
-    - tmp/cache/babel-loader/
-    - tmp/cache/vue-loader/
-  policy: pull
-
-.assets-tmp-cache-push: &assets-tmp-cache-push
-  <<: *assets-tmp-cache
-  policy: push  # We want to rebuild the cache from scratch to ensure we don't pile up outdated cache files.
-
-.storybook-node-modules-cache: &storybook-node-modules-cache
-  key: "storybook-node-modules-${DEBIAN_VERSION}-${NODE_ENV}"
-  paths:
-    - storybook/node_modules/
-  policy: pull
-
-.storybook-node-modules-cache-push: &storybook-node-modules-cache-push
-  <<: *storybook-node-modules-cache
-  policy: push  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up.
-
-.rubocop-cache: &rubocop-cache
-  key: "rubocop-debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}"
-  paths:
-    - tmp/rubocop_cache/
-  policy: pull
-
-.rubocop-cache-push: &rubocop-cache-push
-  <<: *rubocop-cache
-  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up but RuboCop has a mechanism
-  # for keeping only the N latest cache files, so we take advantage of it with `pull-push`.
-  policy: push
-
-.qa-ruby-gems-cache: &qa-ruby-gems-cache
-  key:
-    prefix: "qa-ruby-gems-debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}"
-    files:
-      - qa/Gemfile.lock
-  paths:
-    - qa/vendor/ruby
-  policy: pull
-
-.qa-ruby-gems-cache-push: &qa-ruby-gems-cache-push
-  <<: *qa-ruby-gems-cache
-  policy: pull-push
-
-.setup-test-env-cache:
-  cache:
-    - *ruby-gems-cache
-    - *gitaly-binaries-cache
-    - *go-pkg-cache
-
-.setup-test-env-cache-push:
-  cache:
-    - *ruby-gems-cache-push
-    - *go-pkg-cache-push
-
-.gitaly-binaries-cache-push:
-  cache:
-    - <<: *gitaly-binaries-cache
-      policy: push  # We want to rebuild the cache from scratch to ensure stale dependencies are cleaned up.
-
-.ruby-cache:
-  cache:
-    - *ruby-gems-cache
-
-.rails-cache:
-  cache:
-    - *ruby-gems-cache
-
-.static-analysis-cache:
-  cache:
-    - *ruby-gems-cache
-    - *node-modules-cache
-    - *rubocop-cache
-
-.rubocop-job-cache:
-  cache:
-    - *ruby-gems-cache
-    - *rubocop-cache
-
-.rubocop-job-cache-push:
-  cache:
-    - *ruby-gems-cache  # We don't push this cache as it's already rebuilt by `update-setup-test-env-cache`
-    - *rubocop-cache-push
-
-.coverage-cache:
-  cache:
-    - *ruby-gems-cache
-
-.ruby-node-cache:
-  cache:
-    - *ruby-gems-cache
-    - *node-modules-cache
-
-.qa-bundler-variables: &qa-bundler-variables
-  variables:
-    BUNDLE_SUPPRESS_INSTALL_USING_MESSAGES: "true"
-    BUNDLE_SILENCE_ROOT_WARNING: "true"
-    BUNDLE_PATH: vendor
-
-.qa-cache:
-  <<: *qa-bundler-variables
-  cache:
-    - *qa-ruby-gems-cache
-
-.qa-cache-push:
-  <<: *qa-bundler-variables
-  cache:
-    - *qa-ruby-gems-cache-push
-
-.yarn-cache:
-  cache:
-    - *node-modules-cache
-
-.assets-compile-cache:
-  cache:
-    - *ruby-gems-cache
-    - *node-modules-cache
-    - *assets-tmp-cache
-
-.assets-compile-cache-push:
-  cache:
-    - *ruby-gems-cache  # We don't push this cache as it's already rebuilt by `update-setup-test-env-cache`
-    - *node-modules-cache-push
-    - *assets-tmp-cache-push
-
-.storybook-yarn-cache:
-  cache:
-    - *node-modules-cache
-    - *storybook-node-modules-cache
-
-.storybook-yarn-cache-push:
-  cache:
-    - *node-modules-cache  # We don't push this cache as it's already rebuilt by `update-assets-compile-*-cache`
-    - *storybook-node-modules-cache-push
-
-.use-pg12:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-12-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "12"
-
-.use-pg13:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-13-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.2-alpine
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "13"
-
-.use-pg14:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-14-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.2-alpine
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "14"
-
-.use-pg12-es7-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-12-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: elasticsearch:7.17.6
-      command: ["elasticsearch", "-E", "discovery.type=single-node", "-E", "xpack.security.enabled=false"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "12"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg13-es7-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-13-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.2-alpine
-    - name: elasticsearch:7.17.6
-      command: ["elasticsearch", "-E", "discovery.type=single-node", "-E", "xpack.security.enabled=false"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "13"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg14-es7-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-14-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.2-alpine
-    - name: elasticsearch:7.17.6
-      command: ["elasticsearch", "-E", "discovery.type=single-node", "-E", "xpack.security.enabled=false"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "14"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg13-es8-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-13-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: elasticsearch:8.6.2
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "13"
-    ES_SETTING_DISCOVERY_TYPE: "single-node"
-    ES_SETTING_XPACK_SECURITY_ENABLED: "false"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg14-es8-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-14-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: elasticsearch:8.6.2
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "14"
-    ES_SETTING_DISCOVERY_TYPE: "single-node"
-    ES_SETTING_XPACK_SECURITY_ENABLED: "false"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg13-opensearch1-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-13-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: opensearchproject/opensearch:1.3.5
-      alias: elasticsearch
-      command: ["bin/opensearch", "-E", "discovery.type=single-node", "-E", "plugins.security.disabled=true"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "13"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg13-opensearch2-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-13-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: opensearchproject/opensearch:2.2.1
-      alias: elasticsearch
-      command: ["bin/opensearch", "-E", "discovery.type=single-node", "-E", "plugins.security.disabled=true"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "13"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg14-opensearch1-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-14-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: opensearchproject/opensearch:1.3.5
-      alias: elasticsearch
-      command: ["bin/opensearch", "-E", "discovery.type=single-node", "-E", "plugins.security.disabled=true"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "14"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-pg14-opensearch2-ee:
-  services:
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:postgres-14-pgvector-0.4.1
-      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
-      alias: postgres
-    - name: redis:6.0-alpine
-    - name: opensearchproject/opensearch:2.2.1
-      alias: elasticsearch
-      command: ["bin/opensearch", "-E", "discovery.type=single-node", "-E", "plugins.security.disabled=true"]
-    - name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:zoekt-ci-image-1.0
-      alias: zoekt-ci-image
-  variables:
-    POSTGRES_HOST_AUTH_METHOD: trust
-    PG_VERSION: "14"
-    ZOEKT_INDEX_BASE_URL: http://zoekt-ci-image:6060
-    ZOEKT_SEARCH_BASE_URL: http://zoekt-ci-image:6070
-
-.use-kaniko:
-  image:
-    name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:kaniko
-    entrypoint: [""]
-  before_script:
+    - date
+    - export GOPATH=$CI_PROJECT_DIR/.go
+    - mkdir -p $GOPATH
     - source scripts/utils.sh
-    - mkdir -p /kaniko/.docker
-    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
+    - source scripts/prepare_build.sh
+    - date
 
-.as-if-foss:
+# Jobs that only need to pull cache
+.default-cache:
+  cache:
+    key: "debian-stretch-ruby-2.6.3-node-12.x"
+    paths:
+      - .go/pkg/mod
+      - vendor/ruby
+      - .yarn-cache/
+      - vendor/gitaly-ruby
+    policy: pull
+
+.default-only:
+  only:
+    refs:
+      - master
+      - /^[\d-]+-stable(-ee)?$/
+      - /^\d+-\d+-auto-deploy-\d+$/
+      - /^security\//
+      - merge_requests
+      - tags
+
+.only:variables-canonical-dot-com:
+  only:
+    variables:
+      - $CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/  # Matches the gitlab-org group or its subgroups
+
+.only:variables_refs-canonical-dot-com-schedules:
+  extends: .only:variables-canonical-dot-com
+  only:
+    refs:
+      - schedules
+
+.except:refs-deploy:
+  except:
+    refs:
+      - /^\d+-\d+-auto-deploy-\d+$/
+
+.except:refs-master-tags-stable-deploy:
+  except:
+    refs:
+      - master
+      - tags
+      - /^[\d-]+-stable(-ee)?$/
+      - /^\d+-\d+-auto-deploy-\d+$/
+
+.only:kubernetes:
+  only:
+    kubernetes: active
+
+.only-review:
+  extends:
+    - .only:variables-canonical-dot-com
+    - .only:kubernetes
+    - .except:refs-master-tags-stable-deploy
+
+.only-review-schedules:
+  extends:
+    - .only:variables_refs-canonical-dot-com-schedules
+    - .only:kubernetes
+    - .except:refs-deploy
+
+.code-patterns: &code-patterns
+  - ".gitlab/ci/**/*"
+  - ".{eslintignore,gitattributes,nvmrc,prettierrc,stylelintrc,yamllint}"
+  - ".{codeclimate,eslintrc,gitlab-ci,haml-lint,haml-lint_todo,rubocop,rubocop_todo,scss-lint}.yml"
+  - ".csscomb.json"
+  - "Dockerfile.assets"
+  - "*_VERSION"
+  - "Gemfile{,.lock}"
+  - "Rakefile"
+  - "{babel.config,jest.config}.js"
+  - "config.ru"
+  - "{package.json,yarn.lock}"
+  - "{,ee/}{app,bin,config,db,haml_lint,lib,locale,public,scripts,symbol,vendor}/**/*"
+  - "doc/api/graphql/reference/*" # Files in this folder are auto-generated
+
+.backstage-patterns: &backstage-patterns
+  - "Dangerfile"
+  - "danger/**/*"
+  - "{,ee/}fixtures/**/*"
+  - "{,ee/}rubocop/**/*"
+  - "{,ee/}spec/**/*"
+  - "doc/README.md"  # Some RSpec test rely on this file
+
+.qa-patterns: &qa-patterns
+  - ".dockerignore"
+  - "qa/**/*"
+
+.docs-patterns: &docs-patterns
+  - ".gitlab/route-map.yml"
+  - "doc/**/*"
+  - ".markdownlint.json"
+
+.only:changes-code:
+  only:
+    changes: *code-patterns
+
+.only:changes-qa:
+  only:
+    changes: *qa-patterns
+
+.only:changes-docs:
+  only:
+    changes: *docs-patterns
+
+.only:changes-code-backstage:
+  only:
+    changes:
+      - ".gitlab/ci/**/*"
+      - ".{eslintignore,gitattributes,nvmrc,prettierrc,stylelintrc,yamllint}"
+      - ".{codeclimate,eslintrc,gitlab-ci,haml-lint,haml-lint_todo,rubocop,rubocop_todo,scss-lint}.yml"
+      - ".csscomb.json"
+      - "Dockerfile.assets"
+      - "*_VERSION"
+      - "Gemfile{,.lock}"
+      - "Rakefile"
+      - "{babel.config,jest.config}.js"
+      - "config.ru"
+      - "{package.json,yarn.lock}"
+      - "{,ee/}{app,bin,config,db,haml_lint,lib,locale,public,scripts,symbol,vendor}/**/*"
+      - "doc/api/graphql/reference/*" # Files in this folder are auto-generated
+      # Backstage changes
+      - "Dangerfile"
+      - "danger/**/*"
+      - "{,ee/}fixtures/**/*"
+      - "{,ee/}rubocop/**/*"
+      - "{,ee/}spec/**/*"
+      - "doc/README.md"  # Some RSpec test rely on this file
+
+.only:changes-code-qa:
+  only:
+    changes:
+      - ".gitlab/ci/**/*"
+      - ".{eslintignore,gitattributes,nvmrc,prettierrc,stylelintrc,yamllint}"
+      - ".{codeclimate,eslintrc,gitlab-ci,haml-lint,haml-lint_todo,rubocop,rubocop_todo,scss-lint}.yml"
+      - ".csscomb.json"
+      - "Dockerfile.assets"
+      - "*_VERSION"
+      - "Gemfile{,.lock}"
+      - "Rakefile"
+      - "{babel.config,jest.config}.js"
+      - "config.ru"
+      - "{package.json,yarn.lock}"
+      - "{,ee/}{app,bin,config,db,haml_lint,lib,locale,public,scripts,symbol,vendor}/**/*"
+      - "doc/api/graphql/reference/*" # Files in this folder are auto-generated
+      # QA changes
+      - ".dockerignore"
+      - "qa/**/*"
+
+.only:changes-code-backstage-qa:
+  only:
+    changes:
+      - ".gitlab/ci/**/*"
+      - ".{eslintignore,gitattributes,nvmrc,prettierrc,stylelintrc,yamllint}"
+      - ".{codeclimate,eslintrc,gitlab-ci,haml-lint,haml-lint_todo,rubocop,rubocop_todo,scss-lint}.yml"
+      - ".csscomb.json"
+      - "Dockerfile.assets"
+      - "*_VERSION"
+      - "Gemfile{,.lock}"
+      - "Rakefile"
+      - "{babel.config,jest.config}.js"
+      - "config.ru"
+      - "{package.json,yarn.lock}"
+      - "{,ee/}{app,bin,config,db,haml_lint,lib,locale,public,scripts,symbol,vendor}/**/*"
+      - "doc/api/graphql/reference/*" # Files in this folder are auto-generated
+      # Backstage changes
+      - "Dangerfile"
+      - "danger/**/*"
+      - "{,ee/}fixtures/**/*"
+      - "{,ee/}rubocop/**/*"
+      - "{,ee/}spec/**/*"
+      - "doc/README.md"  # Some RSpec test rely on this file
+      # QA changes
+      - ".dockerignore"
+      - "qa/**/*"
+
+.use-pg9:
+  services:
+    - name: postgres:9.6
+      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
+    - name: redis:alpine
+
+.use-pg10:
+  image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-10-graphicsmagick-1.3.33"
+  services:
+    - name: postgres:10.9
+      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
+    - name: redis:alpine
+
+.use-pg9-ee:
+  services:
+    - name: postgres:9.6
+      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
+    - name: redis:alpine
+    - name: elasticsearch:5.6.12
+
+.use-pg10-ee:
+  image: "registry.gitlab.com/gitlab-org/gitlab-build-images:ruby-2.6.3-golang-1.12-git-2.24-lfs-2.9-chrome-73.0-node-12.x-yarn-1.16-postgresql-10-graphicsmagick-1.3.33"
+  services:
+    - name: postgres:10.9
+      command: ["postgres", "-c", "fsync=off", "-c", "synchronous_commit=off", "-c", "full_page_writes=off"]
+    - name: redis:alpine
+    - name: elasticsearch:5.6.12
+
+.only-ee:
+  only:
+    variables:
+      - $CI_PROJECT_NAME == "gitlab"
+      - $CI_PROJECT_NAME == "gitlab-ee"  # Support former project name for forks/mirrors
+
+.only-ee-as-if-foss:
+  extends: .only-ee
   variables:
     FOSS_ONLY: '1'
-
-.use-docker-in-docker:
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}docker:${DOCKER_VERSION}
-  services:
-    - docker:${DOCKER_VERSION}-dind
-  variables:
-    DOCKER_DRIVER: overlay2
-    DOCKER_HOST: tcp://docker:2375
-    DOCKER_TLS_CERTDIR: ""
-  tags:
-    # See https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/7019 for tag descriptions
-    - gitlab-org-docker
-
-.use-buildx:
-  extends: .use-docker-in-docker
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-slim:docker-${DOCKER_VERSION}
-  variables:
-    QEMU_IMAGE: tonistiigi/binfmt:qemu-v7.0.0
-  before_script:
-    - !reference [.default-utils-before_script, before_script]
-    - echo "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" -u "$CI_REGISTRY_USER" --password-stdin
-    - |
-      if [[ "${ARCH}" =~ arm64 ]]; then
-        echo -e "\033[1;33mInstalling latest qemu emulators\033[0m"
-        docker pull -q ${QEMU_IMAGE};
-        docker run --rm --privileged ${QEMU_IMAGE} --uninstall qemu-*;
-        docker run --rm --privileged ${QEMU_IMAGE} --install all;
-      fi
-    - docker buildx create --use  # creates and set's to active buildkit builder
-
-.use-kube-context:
-  before_script:
-    - export KUBE_CONTEXT="gitlab-org/gitlab:review-apps"
-    - kubectl config use-context ${KUBE_CONTEXT}

.gitlab/ci/graphql.gitlab-ci.yml

@@ -1,15 +0,0 @@
-graphql-verify:
-  variables:
-    SETUP_DB: "false"
-  extends:
-    - .default-retry
-    - .rails-cache
-    - .default-before_script
-    - .graphql:rules:graphql-verify
-  stage: test
-  needs: []
-  script:
-    - bundle exec rake gitlab:graphql:validate
-    - bundle exec rake gitlab:graphql:check_docs
-    - bundle exec rake gitlab:graphql:schema:dump
-    - node scripts/frontend/graphql_possible_types_extraction.js --check

.gitlab/ci/memory.gitlab-ci.yml

@@ -1,41 +1,55 @@
 .only-code-memory-job-base:
   extends:
+    - .default-tags
     - .default-retry
-    - .rails-cache
+    - .default-cache
+    - .default-only
     - .default-before_script
-    - .memory:rules
-  variables:
-    METRICS_FILE: "metrics.txt"
-  artifacts:
-    reports:
-      metrics: "${METRICS_FILE}"
-    expire_in: 62d
+    - .only:changes-code
 
+memory-static:
+  extends: .only-code-memory-job-base
+  variables:
+    SETUP_DB: "false"
+  script:
+    # Uses two different reports from the 'derailed_benchmars' gem.
+
+    # Loads each of gems in the Gemfile and checks how much memory they consume when they are required.
+    # 'derailed_benchmarks' internally uses 'get_process_mem'
+    - bundle exec derailed bundle:mem > tmp/memory_bundle_mem.txt
+    - scripts/generate-gems-size-metrics-static tmp/memory_bundle_mem.txt >> 'tmp/memory_metrics.txt'
+
+    # Outputs detailed information about objects created while gems are loaded.
+    # 'derailed_benchmarks' internally uses 'memory_profiler'
+    - bundle exec derailed bundle:objects > tmp/memory_bundle_objects.txt
+    - scripts/generate-gems-memory-metrics-static tmp/memory_bundle_objects.txt >> 'tmp/memory_metrics.txt'
+  artifacts:
+    paths:
+      - tmp/memory_*.txt
+    reports:
+      metrics: tmp/memory_metrics.txt
 
 # Show memory usage caused by invoking require per gem.
-# Hits the app with one request to ensure that any last minute require-s have been called.
+# Unlike `memory-static`, it hits the app with one request to ensure that any last minute require-s have been called.
 # The application is booted in `production` environment.
 # All tests are run without a webserver (directly using Rack::Mock by default).
 memory-on-boot:
   extends:
     - .only-code-memory-job-base
-    - .production
-    - .use-pg13
-  stage: test
-  needs: ["setup-test-env", "compile-test-assets"]
+    - .use-pg10
   variables:
+    NODE_ENV: "production"
+    RAILS_ENV: "production"
     SETUP_DB: "true"
-    MEMORY_ON_BOOT_FILE_PREFIX: "tmp/memory_on_boot_"
-    TEST_COUNT: 5
+    SKIP_STORAGE_VALIDATION: "true"
+    # we override the max_old_space_size to prevent OOM errors
+    NODE_OPTIONS: --max_old_space_size=3584
   script:
-    - |
-      for i in $(seq 1 $TEST_COUNT)
-      do
-        echo "Starting run $i out of $TEST_COUNT"
-        PATH_TO_HIT="/users/sign_in" CUT_OFF=0.3 bundle exec derailed exec perf:mem >> "${MEMORY_ON_BOOT_FILE_PREFIX}$i.txt"
-      done
-    - scripts/generate-memory-metrics-on-boot "${MEMORY_ON_BOOT_FILE_PREFIX}" "$TEST_COUNT" >> "${METRICS_FILE}"
+    # Both bootsnap and derailed monkey-patch Kernel#require, which leads to circular dependency
+    - ENABLE_BOOTSNAP=false PATH_TO_HIT="/users/sign_in" CUT_OFF=0.3 bundle exec derailed exec perf:mem >> 'tmp/memory_on_boot.txt'
+    - scripts/generate-memory-metrics-on-boot tmp/memory_on_boot.txt >> 'tmp/memory_on_boot_metrics.txt'
   artifacts:
     paths:
-      - "${METRICS_FILE}"
-      - "${MEMORY_ON_BOOT_FILE_PREFIX}*.txt"
+      - tmp/memory_*.txt
+    reports:
+      metrics: tmp/memory_on_boot_metrics.txt

.gitlab/ci/notifications.gitlab-ci.yml

@@ -0,0 +1,23 @@
+.notify:
+  image: ruby:2.6-alpine
+  stage: notification
+  dependencies: []
+  cache: {}
+  before_script:
+    - apk update && apk add git curl bash
+    - source scripts/utils.sh
+    - source scripts/notifications.sh
+    - install_gitlab_gem
+  variables:
+    COMMIT_NOTES_URL: "https://${CI_SERVER_HOST}/${CI_PROJECT_PATH}/commit/${CI_COMMIT_SHA}#notes-list"
+
+schedule:package-and-qa:notify-failure:
+  extends:
+    - .only:variables_refs-canonical-dot-com-schedules
+    - .notify
+  script:
+    - 'export NOTIFICATION_MESSAGE=":skull_and_crossbones: Scheduled QA against master failed! :skull_and_crossbones: See ${CI_PIPELINE_URL}. For downstream pipelines, see ${COMMIT_NOTES_URL}"'
+    - 'notify_on_job_failure schedule:package-and-qa qa-master "${NOTIFICATION_MESSAGE}" ci_failing'
+  needs: ["schedule:package-and-qa"]
+  allow_failure: true
+  when: always

.gitlab/ci/notify.gitlab-ci.yml

@@ -1,41 +0,0 @@
-.notify-defaults:
-  stage: notify
-  dependencies: []
-  cache: {}
-
-create-issues-for-failing-tests:
-  extends:
-    - .notify-defaults
-    - .notify:rules:create-issues-for-failing-tests
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}
-  variables:
-    FAILED_TESTS_DIR: "${CI_PROJECT_DIR}/tmp/failed_tests"
-    FAILING_ISSUES_PROJECT: "gitlab-org/quality/engineering-productivity/flaky-tests-playground"
-    FAILING_ISSUE_JSON_DIR: "${CI_PROJECT_DIR}/tmp/issues"
-  before_script:
-    - source ./scripts/utils.sh
-    - source ./scripts/rspec_helpers.sh
-    - install_gitlab_gem
-  script:
-    - mkdir -p "${FAILING_ISSUE_JSON_DIR}"
-    - retrieve_failed_tests "${FAILED_TESTS_DIR}" "json" "latest"
-    - scripts/pipeline/create_test_failure_issues.rb --project "${FAILING_ISSUES_PROJECT}" --tests-report-file "${FAILED_TESTS_DIR}/rspec_failed_tests.json" --issues-json-folder "${FAILING_ISSUE_JSON_DIR}" --api-token "${FAILING_ISSUES_PROJECT_TOKEN}"
-    - scripts/pipeline/create_test_failure_issues.rb --project "${FAILING_ISSUES_PROJECT}" --tests-report-file "${FAILED_TESTS_DIR}/rspec_ee_failed_tests.json" --issues-json-folder "${FAILING_ISSUE_JSON_DIR}" --api-token "${FAILING_ISSUES_PROJECT_TOKEN}"
-  artifacts:
-    paths:
-      - ${FAILED_TESTS_DIR}/
-      - ${FAILING_ISSUE_JSON_DIR}/
-    when: always
-    expire_in: 2 days
-
-notify-package-and-test-failure:
-  extends:
-    - .notify-defaults
-    - .notify:rules:notify-package-and-test-failure
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}
-  before_script:
-    - source scripts/utils.sh
-    - apt-get update
-    - install_gitlab_gem
-  script:
-    - scripts/generate-failed-package-and-test-mr-message.rb

.gitlab/ci/package-and-test-nightly/main.gitlab-ci.yml

@@ -1,87 +0,0 @@
-include:
-  - local: .gitlab/ci/qa-common/main.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/rules.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/variables.gitlab-ci.yml
-
-workflow:
-  rules:
-    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_PIPELINE_SOURCE == "schedule" && $SCHEDULE_TYPE == "nightly"'
-
-.ce:
-  variables:
-    RELEASE: ${REGISTRY_HOST}/${REGISTRY_GROUP}/build/omnibus-gitlab-mirror/gitlab-ce:${CI_COMMIT_SHA}
-
-.ee:
-  variables:
-    RELEASE: ${REGISTRY_HOST}/${REGISTRY_GROUP}/build/omnibus-gitlab-mirror/gitlab-ee:${CI_COMMIT_SHA}
-
-# ==========================================
-# Prepare stage
-# ==========================================
-# TODO: enable once ee jobs are added
-# trigger-omnibus-env:
-#   extends:
-#     - .trigger-omnibus-env
-
-trigger-omnibus-env-ce:
-  extends:
-    - .trigger-omnibus-env-ce
-  variables:
-    FOSS_ONLY: "1"  # set FOSS_ONLY because we don't pass it via trigger job
-
-# TODO: enable once ee jobs are added
-# trigger-omnibus:
-#   extends:
-#     - .trigger-omnibus
-#   needs:
-#     - trigger-omnibus-env
-
-trigger-omnibus-ce:
-  extends:
-    - .trigger-omnibus-ce
-  needs:
-    - trigger-omnibus-env-ce
-
-# TODO: enable when first parallel job is added
-# download-knapsack-report:
-#   extends:
-#     - .download-knapsack-report
-#     - .rules:download-knapsack
-
-# ==========================================
-# Test stage
-# ==========================================
-update-ee-to-ce:
-  extends:
-    - .qa
-    - .update-script
-    - .ce
-  variables:
-    UPDATE_TYPE: minor
-    UPDATE_FROM_EDITION: ee
-    QA_RSPEC_TAGS: --tag smoke
-
-# ==========================================
-# Post test stage
-# ==========================================
-e2e-test-report:
-  extends:
-    - .e2e-test-report
-
-# TODO: enable when first parallel job is added
-# upload-knapsack-report:
-#   extends:
-#     - .upload-knapsack-report
-#     - .rules:report:process-results
-
-export-test-metrics:
-  extends:
-    - .export-test-metrics
-
-relate-test-failures:
-  extends:
-    - .relate-test-failures
-
-notify-slack:
-  extends:
-    - .notify-slack

.gitlab/ci/package-and-test/main.gitlab-ci.yml

@@ -1,525 +0,0 @@
-# E2E tests pipeline loaded dynamically by script: scripts/generate-e2e-pipeline
-# For adding new tests, refer to: doc/development/testing_guide/end_to_end/package_and_test_pipeline.md
-include:
-  - local: .gitlab/ci/qa-common/main.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/rules.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/variables.gitlab-ci.yml
-
-# ==========================================
-# Prepare stage
-# ==========================================
-check-release-set:
-  extends: .rules:prepare
-  stage: .pre
-  script:
-    - |
-      if [ -z "$RELEASE" ]; then
-        echo "E2E test pipeline requires omnibus installation docker image to be set via $RELEASE environment variable"
-        exit 1
-      else
-        echo "Omnibus installation image is set to '$RELEASE'"
-      fi
-
-trigger-omnibus-env:
-  extends:
-    - .trigger-omnibus-env
-    - .rules:omnibus-build
-
-trigger-omnibus-env-ce:
-  extends:
-    - .trigger-omnibus-env-ce
-    - .rules:omnibus-build-ce
-
-trigger-omnibus:
-  extends:
-    - .trigger-omnibus
-    - .rules:omnibus-build
-  needs:
-    - trigger-omnibus-env
-
-trigger-omnibus-ce:
-  extends:
-    - .trigger-omnibus-ce
-    - .rules:omnibus-build-ce
-  needs:
-    - trigger-omnibus-env-ce
-
-download-knapsack-report:
-  extends:
-    - .download-knapsack-report
-    - .rules:download-knapsack
-
-cache-gems:
-  extends:
-    - .qa-install
-    - .ruby-image
-    - .rules:update-cache
-  stage: .pre
-  tags:
-    - e2e
-  script:
-    - echo "Populated qa cache"
-  cache:
-    policy: pull-push
-
-# ==========================================
-# Test stage
-# ==========================================
-
-# ------------------------------------------
-# Manual jobs
-# ------------------------------------------
-
-# Run manual quarantine job
-#   this job requires passing QA_SCENARIO variable
-#   and optionally QA_TESTS to run specific quarantined tests
-_quarantine:
-  extends:
-    - .qa
-    - .rules:test:manual
-  needs:
-    - job: trigger-omnibus
-      optional: true
-  stage: test
-  variables:
-    QA_RSPEC_TAGS: --tag quarantine
-
-# ------------------------------------------
-# FF changes
-# ------------------------------------------
-
-# Run specs with feature flags set to the opposite of the default state
-instance-ff-inverse:
-  extends:
-    - .qa
-    - .parallel
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    QA_KNAPSACK_REPORT_NAME: ee-instance
-    GITLAB_QA_OPTS: --set-feature-flags $QA_FEATURE_FLAGS
-  rules:
-    - !reference [.rules:test:feature-flags-set, rules]
-
-# ------------------------------------------
-# Jobs with parallel variant
-# ------------------------------------------
-instance-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-instance:
-  extends:
-    - .parallel
-    - instance-selective
-  rules:
-    - !reference [.rules:test:feature-flags-set, rules]  # always run instance to validate ff change
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-
-praefect-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Praefect
-    QA_CAN_TEST_PRAEFECT: "true"
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-praefect:
-  extends:
-    - .parallel
-    - praefect-selective
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-
-relative-url-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::RelativeUrl
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-relative-url:
-  extends:
-    - .parallel
-    - relative-url-selective
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-
-decomposition-single-db-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    GITLAB_QA_OPTS: --omnibus-config decomposition_single_db $EXTRA_GITLAB_QA_OPTS
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-decomposition-single-db:
-  extends:
-    - .parallel
-    - decomposition-single-db-selective
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-
-decomposition-multiple-db-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    GITLAB_ALLOW_SEPARATE_CI_DATABASE: "true"
-    GITLAB_QA_OPTS: --omnibus-config decomposition_multiple_db $EXTRA_GITLAB_QA_OPTS
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-decomposition-multiple-db:
-  extends:
-    - .parallel
-    - decomposition-multiple-db-selective
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::All/
-
-object-storage-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    QA_RSPEC_TAGS: --tag object_storage
-    GITLAB_QA_OPTS: --omnibus-config object_storage $EXTRA_GITLAB_QA_OPTS
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::ObjectStorage/
-object-storage:
-  extends: object-storage-selective
-  parallel: 2
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::ObjectStorage/
-
-object-storage-aws-selective:
-  extends: object-storage-selective
-  variables:
-    AWS_S3_ACCESS_KEY: $QA_AWS_S3_ACCESS_KEY
-    AWS_S3_BUCKET_NAME: $QA_AWS_S3_BUCKET_NAME
-    AWS_S3_KEY_ID: $QA_AWS_S3_KEY_ID
-    AWS_S3_REGION: $QA_AWS_S3_REGION
-    GITLAB_QA_OPTS: --omnibus-config object_storage_aws $EXTRA_GITLAB_QA_OPTS
-object-storage-aws:
-  extends: object-storage-aws-selective
-  parallel: 2
-  rules:
-    - !reference [object-storage, rules]
-
-object-storage-gcs-selective:
-  extends: object-storage-selective
-  variables:
-    GCS_BUCKET_NAME: $QA_GCS_BUCKET_NAME
-    GOOGLE_PROJECT: $QA_GOOGLE_PROJECT
-    GOOGLE_JSON_KEY: $QA_GOOGLE_JSON_KEY
-    GOOGLE_CLIENT_EMAIL: $QA_GOOGLE_CLIENT_EMAIL
-    GITLAB_QA_OPTS: --omnibus-config object_storage_gcs $EXTRA_GITLAB_QA_OPTS
-object-storage-gcs:
-  extends: object-storage-gcs-selective
-  parallel: 2
-  rules:
-    - !reference [object-storage, rules]
-
-packages-selective:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    QA_RSPEC_TAGS: --tag packages
-    GITLAB_QA_OPTS: --omnibus-config packages $EXTRA_GITLAB_QA_OPTS
-  rules:
-    - !reference [.rules:test:qa-selective, rules]
-    - if: $QA_SUITES =~ /Test::Instance::Packages/
-packages:
-  extends: packages-selective
-  parallel: 2
-  rules:
-    - !reference [.rules:test:qa-parallel, rules]
-    - if: $QA_SUITES =~ /Test::Instance::Packages/
-
-# ------------------------------------------
-# Non parallel jobs
-# ------------------------------------------
-update-minor:
-  extends:
-    - .qa
-    - .update-script
-  variables:
-    UPDATE_TYPE: minor
-    QA_RSPEC_TAGS: --tag smoke
-  rules:
-    - !reference [.rules:test:update, rules]
-    - if: $QA_SUITES =~ /Test::Instance::Smoke/
-    - !reference [.rules:test:manual, rules]
-
-update-major:
-  extends:
-    - .qa
-    - .update-script
-  variables:
-    UPDATE_TYPE: major
-    QA_RSPEC_TAGS: --tag smoke
-  rules:
-    - !reference [.rules:test:update, rules]
-    - if: $QA_SUITES =~ /Test::Instance::Smoke/
-    - !reference [.rules:test:manual, rules]
-
-gitlab-pages:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::GitlabPages
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Instance::GitlabPages/
-    - !reference [.rules:test:manual, rules]
-
-gitaly-cluster:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::GitalyCluster
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::GitalyCluster/
-    - !reference [.rules:test:manual, rules]
-
-group-saml:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::GroupSAML
-  rules:
-    - !reference [.rules:test:ee-only, rules]
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::GroupSAML/
-    - !reference [.rules:test:manual, rules]
-
-oauth:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::OAuth
-  rules:
-    - !reference [.rules:test:qa-default-branch, rules]
-    - if: $QA_SUITES =~ /Test::Integration::OAuth/
-    - !reference [.rules:test:manual, rules]
-
-instance-saml:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::InstanceSAML
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::InstanceSAML/
-    - !reference [.rules:test:manual, rules]
-
-jira:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Jira
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Jira/
-    - !reference [.rules:test:manual, rules]
-
-integrations:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Integrations
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Integrations/
-    - !reference [.rules:test:manual, rules]
-
-ldap-no-server:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::LDAPNoServer
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::LDAPNoServer/
-    - !reference [.rules:test:manual, rules]
-
-ldap-tls:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::LDAPTLS
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::LDAPTLS/
-    - !reference [.rules:test:manual, rules]
-
-ldap-no-tls:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::LDAPNoTLS
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::LDAPNoTLS/
-    - !reference [.rules:test:manual, rules]
-
-mtls:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::MTLS
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Mtls/
-    - !reference [.rules:test:manual, rules]
-
-mattermost:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Mattermost
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Mattermost/
-    - !reference [.rules:test:manual, rules]
-
-registry:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Registry
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Registry/
-    - !reference [.rules:test:manual, rules]
-
-registry-with-cdn:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::RegistryWithCDN
-    GCS_CDN_BUCKET_NAME: $QA_GCS_CDN_BUCKET_NAME
-    GOOGLE_CDN_LB: $QA_GOOGLE_CDN_LB
-    GOOGLE_CDN_JSON_KEY: $QA_GOOGLE_CDN_JSON_KEY
-    GOOGLE_CDN_SIGNURL_KEY: $QA_GOOGLE_CDN_SIGNURL_KEY
-    GOOGLE_CDN_SIGNURL_KEY_NAME: $QA_GOOGLE_CDN_SIGNURL_KEY_NAME
-  before_script:
-    - unset GITLAB_QA_ADMIN_ACCESS_TOKEN
-    - !reference [.qa, before_script]
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::RegistryWithCDN/
-    - !reference [.rules:test:manual, rules]
-
-repository-storage:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::RepositoryStorage
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Instance::RepositoryStorage/
-    - !reference [.rules:test:manual, rules]
-
-service-ping-disabled:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::ServicePingDisabled
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::ServicePingDisabled/
-    - !reference [.rules:test:manual, rules]
-
-smtp:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::SMTP
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::SMTP/
-    - !reference [.rules:test:manual, rules]
-
-cloud-activation:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    QA_RSPEC_TAGS: --tag cloud_activation
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Instance::CloudActivation/
-    - !reference [.rules:test:manual, rules]
-
-large-setup:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Instance::Image
-    QA_RSPEC_TAGS: --tag can_use_large_setup
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Instance::LargeSetup/
-    - !reference [.rules:test:manual, rules]
-
-metrics:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Metrics
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Instance::Metrics/
-    - !reference [.rules:test:manual, rules]
-
-elasticsearch:
-  extends: .qa
-  variables:
-    QA_SCENARIO: "Test::Integration::Elasticsearch"
-  before_script:
-    - !reference [.qa, before_script]
-  rules:
-    - !reference [.rules:test:ee-only, rules]
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Elasticsearch/
-    - !reference [.rules:test:manual, rules]
-
-registry-object-storage-tls:
-  extends: object-storage-aws-selective
-  variables:
-    QA_SCENARIO: Test::Integration::RegistryTLS
-    QA_RSPEC_TAGS: ""
-    GITLAB_TLS_CERTIFICATE: $QA_GITLAB_TLS_CERTIFICATE
-    GITLAB_QA_OPTS: --omnibus-config registry_object_storage $EXTRA_GITLAB_QA_OPTS
-
-importers:
-  extends: .qa
-  variables:
-    QA_SCENARIO: Test::Integration::Import
-    QA_MOCK_GITHUB: "true"
-  rules:
-    - !reference [.rules:test:qa, rules]
-    - if: $QA_SUITES =~ /Test::Integration::Import/
-    - !reference [.rules:test:manual, rules]
-
-# ==========================================
-# Post test stage
-# ==========================================
-e2e-test-report:
-  extends:
-    - .e2e-test-report
-    - .rules:report:allure-report
-
-upload-knapsack-report:
-  extends:
-    - .upload-knapsack-report
-    - .rules:report:process-results
-
-export-test-metrics:
-  extends:
-    - .export-test-metrics
-    - .rules:report:process-results
-
-relate-test-failures:
-  extends:
-    - .relate-test-failures
-    - .rules:report:process-results
-
-generate-test-session:
-  extends:
-    - .generate-test-session
-    - .rules:report:process-results
-
-notify-slack:
-  extends:
-    - .notify-slack
-    - .rules:report:process-results

.gitlab/ci/pages.gitlab-ci.yml

@@ -1,37 +1,24 @@
-.compress-public: &compress-public
-  - find public -type f -regex '.*\.\(htm\|html\|txt\|text\|js\|json\|css\|svg\|xml\)$' -exec gzip -f -k {} \;
-  - find public -type f -regex '.*\.\(htm\|html\|txt\|text\|js\|json\|css\|svg\|xml\)$' -exec brotli -f -k {} \;
-
 pages:
   extends:
+    - .default-tags
     - .default-retry
-    - .pages:rules
+    - .default-cache
+    - .default-only
+    - .only:variables-canonical-dot-com
+    - .only:changes-code-backstage-qa
+  only:
+    refs:
+      - master
   stage: pages
-  environment: pages
-  resource_group: pages
-  needs:
-    - "rspec:coverage"
-    - "coverage-frontend"
-    - "compile-production-assets"
-    - "compile-storybook"
-    - "update-tests-metadata"
-    - "generate-frontend-fixtures-mapping"
-  before_script:
-    - apt-get update && apt-get -y install brotli gzip
+  dependencies: ["coverage", "karma", "gitlab:assets:compile pull-cache"]
   script:
     - mv public/ .public/
     - mkdir public/
-    - mkdir -p public/$(dirname "$KNAPSACK_RSPEC_SUITE_REPORT_PATH") public/$(dirname "$FLAKY_RSPEC_SUITE_REPORT_PATH") public/$(dirname "$RSPEC_PACKED_TESTS_MAPPING_PATH") public/$(dirname "$FRONTEND_FIXTURES_MAPPING_PATH")
     - mv coverage/ public/coverage-ruby/ || true
-    - mv coverage-frontend/ public/coverage-frontend/ || true
-    - mv storybook/public public/storybook || true
+    - mv coverage-javascript/ public/coverage-javascript/ || true
+    - mv webpack-report/ public/webpack-report/ || true
     - cp .public/assets/application-*.css public/application.css || true
-    - mv $KNAPSACK_RSPEC_SUITE_REPORT_PATH public/$KNAPSACK_RSPEC_SUITE_REPORT_PATH || true
-    - mv $FLAKY_RSPEC_SUITE_REPORT_PATH public/$FLAKY_RSPEC_SUITE_REPORT_PATH || true
-    - mv $RSPEC_PACKED_TESTS_MAPPING_PATH.gz public/$RSPEC_PACKED_TESTS_MAPPING_PATH.gz || true
-    - mv $FRONTEND_FIXTURES_MAPPING_PATH public/$FRONTEND_FIXTURES_MAPPING_PATH || true
-    - *compress-public
+    - cp .public/assets/application-*.css.gz public/application.css.gz || true
   artifacts:
     paths:
       - public
-    expire_in: 31d

.gitlab/ci/preflight.gitlab-ci.yml

@@ -1,66 +0,0 @@
-.preflight-job-base:
-  stage: preflight
-  extends:
-    - .default-retry
-  needs: []
-
-.qa-preflight-job:
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3-chrome-${CHROME_VERSION}-docker-${DOCKER_VERSION}
-  extends:
-    - .preflight-job-base
-    - .qa-cache
-  variables:
-    USE_BUNDLE_INSTALL: "false"
-    SETUP_DB: "false"
-  before_script:
-    - !reference [.default-before_script, before_script]
-    - cd qa && bundle install
-
-rails-production-server-boot:
-  extends:
-    - .preflight-job-base
-    - .default-before_script
-    - .production
-    - .ruby-cache
-    - .setup:rules:rails-production-server-boot
-    - .use-pg13
-  variables:
-    BUNDLE_WITHOUT: "development:test"
-    BUNDLE_WITH: "production"
-  needs: []
-  script:
-    - source scripts/utils.sh
-    - cp config/puma.rb.example config/puma.rb
-    - sed --in-place "s:/home/git/gitlab:${PWD}:" config/puma.rb
-    - echo 'bind "tcp://127.0.0.1:3000"' >> config/puma.rb
-    - bundle exec puma --environment production --config config/puma.rb &
-    - sleep 40  # See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114124#note_1309506358
-    - retry_times_sleep 10 5 "curl http://127.0.0.1:3000"
-    - kill $(jobs -p)
-
-no-ee-check:
-  extends:
-    - .preflight-job-base
-    - .setup:rules:no-ee-check
-  script:
-    - scripts/no-dir-check ee
-
-no-jh-check:
-  extends:
-    - .preflight-job-base
-    - .setup:rules:no-jh-check
-  script:
-    - scripts/no-dir-check jh
-
-qa:selectors:
-  extends:
-    - .qa-preflight-job
-    - .qa:rules:ee-and-foss
-  script:
-    - bundle exec bin/qa Test::Sanity::Selectors
-
-qa:selectors-as-if-foss:
-  extends:
-    - qa:selectors
-    - .qa:rules:as-if-foss
-    - .as-if-foss

.gitlab/ci/qa-common/main.gitlab-ci.yml

@@ -1,280 +0,0 @@
-default:
-  interruptible: true
-
-workflow:
-  name: $PIPELINE_NAME
-
-include:
-  - project: gitlab-org/quality/pipeline-common
-    ref: 5.1.1
-    file:
-      - /ci/base.gitlab-ci.yml
-      - /ci/allure-report.yml
-      - /ci/knapsack-report.yml
-
-stages:
-  - test
-  - report
-  - notify
-
-# ==========================================
-# Templates
-# ==========================================
-.parallel:
-  parallel: 5
-  variables:
-    QA_KNAPSACK_REPORT_PATH: $CI_PROJECT_DIR/qa/knapsack
-
-.ruby-image:
-  # Because this pipeline template can be included directly in other projects,
-  # image path and registry needs to be defined explicitly
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3
-
-.qa-install:
-  variables:
-    BUNDLE_SUPPRESS_INSTALL_USING_MESSAGES: "true"
-    BUNDLE_SILENCE_ROOT_WARNING: "true"
-  extends:
-    - .gitlab-qa-install
-
-.update-script:
-  script:
-    - !reference [.bundle-prefix]
-    - export QA_COMMAND="$BUNDLE_PREFIX gitlab-qa Test::Omnibus::UpdateFromPrevious $RELEASE $GITLAB_SEMVER_VERSION $UPDATE_TYPE $UPDATE_FROM_EDITION -- $QA_RSPEC_TAGS $RSPEC_REPORT_OPTS"
-    - echo "Running - '$QA_COMMAND'"
-    - eval "$QA_COMMAND"
-
-.qa:
-  extends:
-    - .qa-base
-    - .qa-install
-    - .gitlab-qa-report
-  stage: test
-  tags:
-    - e2e
-  variables:
-    QA_GENERATE_ALLURE_REPORT: "true"
-    QA_CAN_TEST_PRAEFECT: "false"
-    QA_INTERCEPT_REQUESTS: "true"
-    GITLAB_LICENSE_MODE: test
-    GITLAB_QA_ADMIN_ACCESS_TOKEN: $QA_ADMIN_ACCESS_TOKEN
-    GITLAB_QA_OPTS: $EXTRA_GITLAB_QA_OPTS
-    # todo: remove in 16.1 milestone when not needed for backwards compatibility anymore
-    EE_LICENSE: $QA_EE_LICENSE
-    GITHUB_ACCESS_TOKEN: $QA_GITHUB_ACCESS_TOKEN
-  # Allow QA jobs to fail as they are flaky. The top level `package-and-e2e:ee`
-  # pipeline is not allowed to fail, so without allowing QA to fail, we will be
-  # blocking merges due to flaky tests.
-  allow_failure: true
-
-.trigger-omnibus-env:
-  stage: .pre
-  needs:
-    # We need this job because we need its `cached-assets-hash.txt` artifact, so that we can pass the assets image tag to the downstream omnibus-gitlab pipeline.
-    - pipeline: $PARENT_PIPELINE_ID
-      job: build-assets-image
-  variables:
-    BUILD_ENV: build.env
-  before_script:
-    - |
-      # This is duplicating the function from `scripts/utils.sh` since `.gitlab/ci/package-and-test/main.gitlab-ci.yml` can be included in other projects.
-      function assets_image_tag() {
-        local cache_assets_hash_file="cached-assets-hash.txt"
-
-        if [[ -n "${CI_COMMIT_TAG}" ]]; then
-          echo -n "${CI_COMMIT_REF_NAME}"
-        elif [[ -f "${cache_assets_hash_file}" ]]; then
-          echo -n "assets-hash-$(cat ${cache_assets_hash_file} | cut -c1-10)"
-        else
-          echo -n "${CI_COMMIT_SHA}"
-        fi
-      }
-  script:
-    - |
-      SECURITY_SOURCES=$([[ ! "$CI_PROJECT_NAMESPACE" =~ ^gitlab-org\/security ]] || echo "true")
-      echo "SECURITY_SOURCES=${SECURITY_SOURCES:-false}" > $BUILD_ENV
-      echo "OMNIBUS_GITLAB_CACHE_UPDATE=${OMNIBUS_GITLAB_CACHE_UPDATE:-false}" >> $BUILD_ENV
-      for version_file in *_VERSION; do echo "$version_file=$(cat $version_file)" >> $BUILD_ENV; done
-      echo "OMNIBUS_GITLAB_RUBY3_BUILD=${OMNIBUS_GITLAB_RUBY3_BUILD:-false}" >> $BUILD_ENV
-      echo "OMNIBUS_GITLAB_RUBY2_BUILD=${OMNIBUS_GITLAB_RUBY2_BUILD:-false}" >> $BUILD_ENV
-      echo "OMNIBUS_GITLAB_CACHE_EDITION=${OMNIBUS_GITLAB_CACHE_EDITION:-GITLAB}" >> $BUILD_ENV
-      echo "OMNIBUS_GITLAB_BUILD_ON_ALL_OS=${OMNIBUS_GITLAB_BUILD_ON_ALL_OS:-false}" >> $BUILD_ENV
-      echo "GITLAB_ASSETS_TAG=$(assets_image_tag)" >> $BUILD_ENV
-      echo "EE=$([[ $FOSS_ONLY == '1' ]] && echo 'false' || echo 'true')" >> $BUILD_ENV
-      target_branch_name="${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-${CI_COMMIT_REF_NAME}}"
-      echo "TRIGGER_BRANCH=$([[ "${target_branch_name}" =~ ^[0-9-]+-stable(-ee)?$ ]] && echo ${target_branch_name%-ee} || echo 'master')" >> $BUILD_ENV
-    - |
-      echo "Built environment file for omnibus build:"
-      cat $BUILD_ENV
-  artifacts:
-    expire_in: 3 days
-    reports:
-      dotenv: $BUILD_ENV
-    paths:
-      - $BUILD_ENV
-
-.trigger-omnibus-env-ce:
-  extends: .trigger-omnibus-env
-  needs:
-    - pipeline: $PARENT_PIPELINE_ID
-      job: build-assets-image as-if-foss
-
-.trigger-omnibus:
-  stage: .pre
-  inherit:
-    variables: false
-  variables:
-    GITALY_SERVER_VERSION: $GITALY_SERVER_VERSION
-    GITLAB_ELASTICSEARCH_INDEXER_VERSION: $GITLAB_ELASTICSEARCH_INDEXER_VERSION
-    GITLAB_KAS_VERSION: $GITLAB_KAS_VERSION
-    GITLAB_METRICS_EXPORTER_VERSION: $GITLAB_METRICS_EXPORTER_VERSION
-    GITLAB_PAGES_VERSION: $GITLAB_PAGES_VERSION
-    GITLAB_SHELL_VERSION: $GITLAB_SHELL_VERSION
-    GITLAB_WORKHORSE_VERSION: $GITLAB_WORKHORSE_VERSION
-    GITLAB_VERSION: $CI_COMMIT_SHA
-    GITLAB_ASSETS_TAG: $GITLAB_ASSETS_TAG
-    IMAGE_TAG: $CI_COMMIT_SHA
-    TOP_UPSTREAM_SOURCE_PROJECT: $CI_PROJECT_PATH
-    SECURITY_SOURCES: $SECURITY_SOURCES
-    CACHE_UPDATE: $OMNIBUS_GITLAB_CACHE_UPDATE
-    RUBY3_BUILD: $OMNIBUS_GITLAB_RUBY3_BUILD
-    RUBY2_BUILD: $OMNIBUS_GITLAB_RUBY2_BUILD
-    CACHE_EDITION: $OMNIBUS_GITLAB_CACHE_EDITION
-    BUILD_ON_ALL_OS: $OMNIBUS_GITLAB_BUILD_ON_ALL_OS
-    SKIP_QA_TEST: "true"
-    ee: $EE
-  trigger:
-    project: gitlab-org/build/omnibus-gitlab-mirror
-    branch: $TRIGGER_BRANCH
-    strategy: depend
-
-.trigger-omnibus-ce:
-  extends:
-    - .trigger-omnibus
-  variables:
-    # Override gitlab repository so that omnibus doesn't use foss repository for CE build
-    GITLAB_ALTERNATIVE_REPO: $CI_PROJECT_URL
-
-.download-knapsack-report:
-  extends:
-    - .gitlab-qa-image
-  stage: .pre
-  variables:
-    KNAPSACK_DIR: ${CI_PROJECT_DIR}/qa/knapsack
-    GIT_STRATEGY: none
-  script:
-    # when using qa-image, code runs in /home/gitlab/qa folder
-    - bundle exec rake "knapsack:download[test]"
-    - mkdir -p "$KNAPSACK_DIR" && cp knapsack/*.json "${KNAPSACK_DIR}/"
-  allow_failure: true
-  artifacts:
-    paths:
-      - qa/knapsack/*.json
-    expire_in: 1 day
-
-.e2e-test-report:
-  extends:
-    - .generate-allure-report-base
-  stage: report
-  variables:
-    GITLAB_AUTH_TOKEN: $PROJECT_TOKEN_FOR_CI_SCRIPTS_API_USAGE
-    ALLURE_PROJECT_PATH: $CI_PROJECT_PATH
-    ALLURE_MERGE_REQUEST_IID: $CI_MERGE_REQUEST_IID
-
-.upload-knapsack-report:
-  extends:
-    - .generate-knapsack-report-base
-    - .qa-install
-    - .ruby-image
-  stage: report
-  when: always
-
-.export-test-metrics:
-  extends:
-    - .qa-install
-    - .ruby-image
-  stage: report
-  when: always
-  variables:
-    QA_METRICS_REPORT_FILE_PATTERN: $CI_PROJECT_DIR/gitlab-qa-run-*/**/test-metrics-*.json
-  script:
-    - bundle exec rake "ci:export_test_metrics[$QA_METRICS_REPORT_FILE_PATTERN]"
-
-.relate-test-failures:
-  extends:
-    - .qa-install
-    - .ruby-image
-  stage: report
-  when: always
-  variables:
-    QA_RSPEC_JSON_FILE_PATTERN: "${CI_PROJECT_DIR}/gitlab-qa-run-*/**/rspec-*.json"
-  script:
-    - |
-      if [ "$SUITE_FAILED" != "true" ] && [ "$SUITE_RAN" == "true" ]; then
-        echo "Test suite passed. Exiting..."
-        exit 0
-      fi
-    - |
-      bundle exec relate-failure-issue \
-        --input-files "${QA_RSPEC_JSON_FILE_PATTERN}" \
-        --project "gitlab-org/gitlab" \
-        --token "${QA_RELATE_FAILURE_ISSUE_TOKEN}"
-
-.generate-test-session:
-  extends:
-    - .qa-install
-    - .ruby-image
-  stage: report
-  when: always
-  variables:
-    QA_RSPEC_JSON_FILE_PATTERN: "${CI_PROJECT_DIR}/gitlab-qa-run-*/**/rspec-*.json"
-  script:
-    - |
-      bundle exec generate-test-session \
-        --input-files "${QA_RSPEC_JSON_FILE_PATTERN}" \
-        --project "gitlab-org/quality/testcase-sessions" \
-        --token "${QA_TEST_SESSION_TOKEN}" \
-        --ci-project-token "${GENERATE_TEST_SESSION_READ_API_REPORTER_TOKEN}" \
-        --issue-url-file report_issue_url.txt
-  artifacts:
-    when: always
-    expire_in: 1d
-    paths:
-      - qa/report_issue_url.txt
-
-.notify-slack:
-  extends:
-    - .notify-slack-qa
-    - .qa-install
-    - .ruby-image
-  stage: notify
-  variables:
-    QA_RSPEC_XML_FILE_PATTERN: "${CI_PROJECT_DIR}/gitlab-qa-run-*/**/rspec-*.xml"
-    SLACK_ICON_EMOJI: ci_failing
-    STATUS_SYM: ☠️
-    STATUS: failed
-    TYPE: "($QA_RUN_TYPE) "
-  when: always
-  script:
-    - |
-      if [ "$SUITE_FAILED" != "true" ] && [ "$SUITE_RAN" == "true" ]; then
-        echo "Test suite passed. Exiting..."
-        exit 0
-      fi
-    - bundle exec prepare-stage-reports --input-files "${QA_RSPEC_XML_FILE_PATTERN}"
-    - !reference [.notify-slack-qa, script]
-
-# ==========================================
-# Pre stage
-# ==========================================
-dont-interrupt-me:
-  stage: .pre
-  interruptible: false
-  script:
-    - echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
-  rules:
-    - if: '$CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH && $CI_MERGE_REQUEST_IID == null'
-      allow_failure: true
-    - if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" || $CI_MERGE_REQUEST_EVENT_TYPE == "detached"'
-      when: manual
-      allow_failure: true

.gitlab/ci/qa-common/rules.gitlab-ci.yml

@@ -1,154 +0,0 @@
-# Specific specs passed
-.specific-specs: &specific-specs
-  if: $QA_TESTS != ""
-
-# No specific specs passed
-.all-specs: &all-specs
-  if: $QA_TESTS == ""
-
-# FF changes
-.feature-flags-set: &feature-flags-set
-  if: $QA_FEATURE_FLAGS =~ /enabled|disabled/
-
-# Manually trigger job on ff changes but with default ff state instead of inverted
-.feature-flags-set-manual: &feature-flags-set-manual
-  <<: *feature-flags-set
-  when: manual
-  allow_failure: true
-
-# Run the job on master pipeline
-.default-branch: &default-branch
-  if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
-
-# Run all tests when QA framework changes present, full suite execution is explicitly enabled or a feature flag file is removed
-.qa-run-all-tests: &qa-run-all-tests
-  if: $QA_FRAMEWORK_CHANGES == "true" || $QA_RUN_ALL_TESTS == "true" || $QA_RUN_ALL_E2E_LABEL == "true" || $QA_FEATURE_FLAGS =~ /deleted/
-
-# Run job when MR has pipeline:run-all-e2e label
-.qa-run-all-e2e-label: &qa-run-all-e2e-label
-  if: $QA_RUN_ALL_E2E_LABEL == "true"
-
-# Process test results (notify failure to slack, create test session report, relate test failures)
-.process-test-results: &process-test-results
-  if: $PROCESS_TEST_RESULTS == "true"
-
-.not-canonical-project: &not-canonical-project
-  if: '$CI_PROJECT_PATH != "gitlab-org/gitlab" && $CI_PROJECT_PATH != "gitlab-cn/gitlab"'
-
-# Selective test execution against omnibus instance have following execution scenarios:
-#   * only e2e spec files changed - runs only changed specs
-#   * qa framework changes - runs full test suite
-#   * feature flag changed - runs full test suite with base gitlab instance configuration with both ff states
-#   * quarantined e2e spec - skips execution of e2e tests by creating a no-op pipeline
-
-# ------------------------------------------
-# Prepare
-# ------------------------------------------
-.rules:prepare:
-  rules:
-    - when: always
-
-.rules:omnibus-build:
-  rules:
-    - if: $SKIP_OMNIBUS_TRIGGER == "true"
-      when: never
-    - if: $FOSS_ONLY != "1"
-
-.rules:omnibus-build-ce:
-  rules:
-    - if: $SKIP_OMNIBUS_TRIGGER == "true"
-      when: never
-    - if: $FOSS_ONLY == "1"
-
-.rules:update-cache:
-  rules:
-    - if: '$UPDATE_QA_CACHE == "true"'
-
-.rules:download-knapsack:
-  rules:
-    - when: always
-
-# ------------------------------------------
-# Test
-# ------------------------------------------
-.rules:test:manual:
-  rules:
-    - when: manual
-      allow_failure: true
-      variables:
-        QA_TESTS: ""
-
-.rules:test:feature-flags-set:
-  rules:
-    # unset specific specs if pipeline has feature flag changes and run full suite
-    - <<: *feature-flags-set
-      variables:
-        QA_TESTS: ""
-
-# parallel and non parallel rules are used for jobs that require parallel execution and thus need to switch
-# between parallel and non parallel when only certain specs are executed
-.rules:test:qa-selective:
-  rules:
-    # always run parallel with full suite when framework changes present or ff state changed
-    - <<: *qa-run-all-tests
-      when: never
-    - <<: *all-specs
-      when: never
-    - <<: *feature-flags-set
-      when: never
-
-.rules:test:qa-parallel:
-  rules:
-    - *qa-run-all-tests
-    - <<: *specific-specs
-      when: manual
-      allow_failure: true
-      variables:
-        QA_TESTS: ""
-    - *feature-flags-set-manual
-
-# general qa job rule for jobs without the need to run in parallel
-.rules:test:qa:
-  rules:
-    - *qa-run-all-tests
-    - *feature-flags-set-manual
-
-.rules:test:ee-only:
-  rules:
-    - if: $FOSS_ONLY == "1"
-      when: never
-
-.rules:test:update:
-  rules:
-    # skip upgrade jobs if gitlab version is not in semver compatible format
-    # these jobs need gitlab version because we can't reliably detect it from just the image
-    - if: $GITLAB_SEMVER_VERSION !~ /^\d+\.\d+\.\d+/
-      when: never
-    # update type tests are used to check if gitlab upgrade can be performed correctly (mainly migrations)
-    # there isn't much benefit in running tests after update with new sidebar enabled and there
-    # is also an issue to properly pass feature toggle to this job due to how gitlab-qa parses cli args
-    - if: $QA_SUPER_SIDEBAR_ENABLED == "true"
-      when: never
-    - !reference [.rules:test:ee-only, rules]
-    - !reference [.rules:test:qa, rules]
-
-.rules:test:qa-default-branch:
-  rules:
-    - *qa-run-all-e2e-label
-    - *default-branch
-    - *feature-flags-set-manual
-
-# ------------------------------------------
-# Report
-# ------------------------------------------
-.rules:report:allure-report:
-  rules:
-    - if: $SKIP_ALLURE_REPORT == "true"
-      when: never
-    - when: always
-
-.rules:report:process-results:
-  rules:
-    - <<: *not-canonical-project
-      when: never
-    - *process-test-results

.gitlab/ci/qa-common/variables.gitlab-ci.yml

@@ -1,20 +0,0 @@
-# Default variables for package-and-test
-
-variables:
-  REGISTRY_HOST: "registry.gitlab.com"
-  REGISTRY_GROUP: "gitlab-org"
-  SKIP_REPORT_IN_ISSUES: "true"
-  SKIP_OMNIBUS_TRIGGER: "true"
-  OMNIBUS_GITLAB_CACHE_UPDATE: "false"
-  OMNIBUS_GITLAB_RUBY3_BUILD: "false"
-  OMNIBUS_GITLAB_RUBY2_BUILD: "false"
-  OMNIBUS_GITLAB_CACHE_EDITION: "GITLAB"
-  OMNIBUS_GITLAB_BUILD_ON_ALL_OS: "false"
-  ALLURE_JOB_NAME: $CI_PROJECT_NAME
-  COLORIZED_LOGS: "true"
-  QA_LOG_LEVEL: "info"
-  QA_TESTS: ""
-  QA_FEATURE_FLAGS: ""
-  # run all tests by default when package-and-test is included natively in other projects
-  # this will be overridden when selective test execution is used in gitlab canonical project
-  QA_RUN_ALL_TESTS: "true"

.gitlab/ci/qa.gitlab-ci.yml

@@ -1,166 +1,69 @@
 .qa-job-base:
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3-chrome-${CHROME_VERSION}-docker-${DOCKER_VERSION}
   extends:
+    - .default-tags
     - .default-retry
-    - .qa-cache
+    - .default-only
+    - .only:changes-code-qa
   stage: test
-  needs: []
-  variables:
-    USE_BUNDLE_INSTALL: "false"
-    SETUP_DB: "false"
+  dependencies: []
+  cache:
+    key: "qa-framework-jobs:v1"
+    paths:
+      - vendor/ruby
   before_script:
-    - !reference [.default-before_script, before_script]
-    - cd qa && bundle install
-
-.e2e-trigger-base:
-  extends: .production  # this makes sure GITLAB_ALLOW_SEPARATE_CI_DATABASE is passed to the child pipeline
-  stage: qa
-  needs:
-    - build-assets-image
-    - build-qa-image
-    - e2e-test-pipeline-generate
-  variables:
-    # This is needed by `trigger-omnibus-env` (`.gitlab/ci/package-and-test/main.gitlab-ci.yml`).
-    PARENT_PIPELINE_ID: $CI_PIPELINE_ID
-    SKIP_MESSAGE: Skipping package-and-test due to mr containing only quarantine changes!
-    GITLAB_QA_IMAGE: "${CI_REGISTRY_IMAGE}/gitlab-ee-qa:${CI_COMMIT_SHA}"
-    RUN_WITH_BUNDLE: "true"  # instructs pipeline to install and run gitlab-qa gem via bundler
-    QA_PATH: qa  # sets the optional path for bundler to run from
-    DYNAMIC_PIPELINE_YML: package-and-test-pipeline.yml  # yml files are generated by scripts/generate-e2e-pipeline script
-  inherit:
-    variables:
-      - CHROME_VERSION
-      - RUBY_VERSION
-      - DOCKER_VERSION
-      - REGISTRY_GROUP
-      - REGISTRY_HOST
-      - OMNIBUS_GITLAB_CACHE_EDITION
-      - OMNIBUS_GITLAB_RUBY3_BUILD
-      - OMNIBUS_GITLAB_RUBY2_BUILD
-  trigger:
-    strategy: depend
-    forward:
-      yaml_variables: true
-      pipeline_variables: true
-    include:
-      - artifact: $DYNAMIC_PIPELINE_YML
-        job: e2e-test-pipeline-generate
+    - cd qa/
+    - bundle install --clean --jobs=$(nproc) --path=vendor --retry=3 --quiet
+    - bundle check
 
 qa:internal:
-  extends:
-    - .qa-job-base
-    - .qa:rules:internal
+  extends: .qa-job-base
   script:
-    - bundle exec rspec -O .rspec_internal
+    - bundle exec rspec
 
-qa:internal-as-if-foss:
-  extends:
-    - qa:internal
-    - .qa:rules:internal-as-if-foss
-    - .as-if-foss
-
-qa:master-auto-quarantine-dequarantine:
-  extends:
-    - .qa-job-base
-  rules:
-    - if: '$QA_TRIGGER_AUTO_QUARANTINE =~ /true|yes|1/i'
+qa:selectors:
+  extends: .qa-job-base
   script:
-    - bundle exec confiner -r .confiner/master.yml
-  allow_failure: true
+    - bundle exec bin/qa Test::Sanity::Selectors
 
-qa:nightly-auto-quarantine-dequarantine:
+qa:selectors-foss:
   extends:
-    - .qa-job-base
-  rules:
-    - if: '$QA_TRIGGER_AUTO_QUARANTINE =~ /true|yes|1/i'
-  script:
-    - bundle exec confiner -r .confiner/nightly.yml
-  allow_failure: true
+    - qa:selectors
+    - .only-ee-as-if-foss
 
-qa:update-qa-cache:
-  extends:
-    - .qa-job-base
-    - .qa-cache-push
-    - .shared:rules:update-cache
-  stage: prepare
-  script:
-    - echo "Cache has been updated and ready to be uploaded."
-
-e2e:package-and-test-ee:
-  extends:
-    - .e2e-trigger-base
-    - .qa:rules:package-and-test-ee
-  needs:
-    - build-assets-image
-    - build-qa-image
-    - e2e-test-pipeline-generate
-  variables:
-    RELEASE: "${REGISTRY_HOST}/${REGISTRY_GROUP}/build/omnibus-gitlab-mirror/gitlab-ee:${CI_COMMIT_SHA}"
-    QA_RUN_TYPE: e2e-package-and-test
-    ALLURE_JOB_NAME: e2e-package-and-test
-    PIPELINE_NAME: E2E Omnibus GitLab EE
-
-e2e:package-and-test-ce:
-  extends:
-    - e2e:package-and-test-ee
-    - .qa:rules:package-and-test-ce
-  needs:
-    - build-assets-image as-if-foss
-    - build-qa-image as-if-foss
-    - e2e-test-pipeline-generate
-  variables:
-    FOSS_ONLY: "1"
-    RELEASE: ${REGISTRY_HOST}/${REGISTRY_GROUP}/build/omnibus-gitlab-mirror/gitlab-ce:${CI_COMMIT_SHA}
-    GITLAB_QA_IMAGE: ${CI_REGISTRY_IMAGE}/gitlab-ce-qa:${CI_COMMIT_SHA}
-    QA_RUN_TYPE: e2e-package-and-test-ce
-    ALLURE_JOB_NAME: e2e-package-and-test-ce
-    PIPELINE_NAME: E2E Omnibus GitLab CE
-
-e2e:package-and-test-super-sidebar:
-  extends:
-    - e2e:package-and-test-ee
-    - .qa:rules:package-and-test-sidebar
-  when: manual
-  variables:
-    QA_SUPER_SIDEBAR_ENABLED: "true"
-    EXTRA_GITLAB_QA_OPTS: --set-feature-flags super_sidebar_nav=enabled
-    QA_RUN_TYPE: e2e-package-and-test-super-sidebar
-    ALLURE_JOB_NAME: e2e-package-and-test-super-sidebar
-    PIPELINE_NAME: E2E Omnibus Super Sidebar
-
-e2e:package-and-test-nightly:
-  extends:
-    - .e2e-trigger-base
-    - .qa:rules:package-and-test-nightly
-  needs:
-    - build-assets-image
-    - build-assets-image as-if-foss
-    - build-qa-image
-    - build-qa-image as-if-foss
-    - e2e-test-pipeline-generate
-  variables:
-    GITLAB_SEMVER_VERSION: $GITLAB_SEMVER_VERSION
-    QA_RUN_TYPE: nightly
-    ALLURE_JOB_NAME: nightly
-    PIPELINE_NAME: E2E Omnibus GitLab Nightly
-    DYNAMIC_PIPELINE_YML: package-and-test-nightly-pipeline.yml
-
-e2e:test-on-gdk:
-  extends:
-    - .e2e-trigger-base
-    - .qa:rules:e2e:test-on-gdk
+.package-and-qa-base:
+  image: ruby:2.6-alpine
   stage: qa
-  needs:
-    # In scheduled master pipelines we wait for the image to be built.
-    # In MRs we assume the last scheduled master pipeline built the image already.
-    - job: build-qa-on-gdk-master-image
-      optional: true
-    - job: e2e-test-pipeline-generate
-      artifacts: true
-  variables:
-    ALLURE_JOB_NAME: e2e-test-on-gdk
-    QA_RUN_TYPE: e2e-test-on-gdk
-    PIPELINE_NAME: E2E GDK
-    DYNAMIC_PIPELINE_YML: test-on-gdk-pipeline.yml
-    SKIP_MESSAGE: Skipping test-on-gdk due to mr containing only quarantine changes!
+  dependencies: []
+  retry: 0
+  script:
+    - source scripts/utils.sh
+    - install_gitlab_gem
+    - ./scripts/trigger-build omnibus
+
+package-and-qa-manual:
+  extends:
+    - .package-and-qa-base
+    - .default-only
+    - .only:variables-canonical-dot-com
+    - .except:refs-deploy
+    - .only:changes-code
+  when: manual
+  needs: ["build-qa-image", "gitlab:assets:compile pull-cache"]
+
+package-and-qa:
+  extends:
+    - .package-and-qa-base
+    - .default-only
+    - .only:variables-canonical-dot-com
+    - .except:refs-master-tags-stable-deploy
+    - .only:changes-qa
+  needs: ["build-qa-image", "gitlab:assets:compile pull-cache"]
+  allow_failure: true
+
+schedule:package-and-qa:
+  extends:
+    - .package-and-qa-base
+    - .default-only
+    - .only:variables_refs-canonical-dot-com-schedules
+  needs: ["build-qa-image", "gitlab:assets:compile pull-cache"]
   allow_failure: true

.gitlab/ci/rails/rspec-foss-impact.gitlab-ci.yml.erb

@@ -1,90 +0,0 @@
-# RSpec FOSS impact pipeline loaded dynamically by script: scripts/generate_rspec_pipeline.rb
-
-include:
-  - local: .gitlab/ci/rails/shared.gitlab-ci.yml
-
-default:
-  image: $DEFAULT_CI_IMAGE
-  tags:
-    - gitlab-org
-  # Default job timeout set to 90m https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10520
-  timeout: 90m
-  interruptible: true
-
-stages:
-  - test
-
-dont-interrupt-me:
-  extends: .rules:dont-interrupt
-  stage: .pre
-  interruptible: false
-  script:
-    - echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
-
-.base-rspec-foss-impact:
-  extends: .rspec-base-pg13-as-if-foss
-  needs:
-    - pipeline: $PARENT_PIPELINE_ID
-      job: detect-tests
-    - pipeline: $PARENT_PIPELINE_ID
-      job: setup-test-env
-    - pipeline: $PARENT_PIPELINE_ID
-      job: retrieve-tests-metadata
-    - pipeline: $PARENT_PIPELINE_ID
-      job: compile-test-assets as-if-foss
-  rules:
-    - when: always
-  variables:
-    RSPEC_TESTS_FILTER_FILE: "${RSPEC_MATCHING_TESTS_FOSS_PATH}"
-    RSPEC_TESTS_MAPPING_ENABLED: "true"
-  script:
-    - !reference [.base-script, script]
-    - rspec_paralellized_job "--tag ~quarantine --tag ~level:background_migration --tag ~zoekt"
-  artifacts:
-    expire_in: 7d
-    paths:
-      - "${RSPEC_MATCHING_TESTS_FOSS_PATH}"
-      - tmp/capybara/
-
-<% if rspec_files_per_test_level[:migration][:files].size > 0 %>
-rspec migration foss-impact:
-  extends: .base-rspec-foss-impact
-<% if rspec_files_per_test_level[:migration][:parallelization] > 1 %>
-  parallel: <%= rspec_files_per_test_level[:migration][:parallelization] %>
-<% end %>
-  script:
-    - !reference [.base-script, script]
-    - rspec_paralellized_job "--tag ~quarantine --tag ~zoekt"
-<% end %>
-
-<% if rspec_files_per_test_level[:background_migration][:files].size > 0 %>
-rspec background_migration foss-impact:
-  extends: .base-rspec-foss-impact
-<% if rspec_files_per_test_level[:background_migration][:parallelization] > 1 %>
-  parallel: <%= rspec_files_per_test_level[:background_migration][:parallelization] %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level[:unit][:files].size > 0 %>
-rspec unit foss-impact:
-  extends: .base-rspec-foss-impact
-<% if rspec_files_per_test_level[:unit][:parallelization] > 1 %>
-  parallel: <%= rspec_files_per_test_level[:unit][:parallelization] %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level[:integration][:files].size > 0 %>
-rspec integration foss-impact:
-  extends: .base-rspec-foss-impact
-<% if rspec_files_per_test_level[:integration][:parallelization] > 1 %>
-  parallel: <%= rspec_files_per_test_level[:integration][:parallelization] %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level[:system][:files].size > 0 %>
-rspec system foss-impact:
-  extends: .base-rspec-foss-impact
-<% if rspec_files_per_test_level[:system][:parallelization] > 1 %>
-  parallel: <%= rspec_files_per_test_level[:system][:parallelization] %>
-<% end %>
-<% end %>

.gitlab/ci/rails/rspec-predictive.gitlab-ci.yml.erb

@@ -1,153 +0,0 @@
-# RSpec preditive pipeline loaded dynamically by script: scripts/generate_rspec_pipeline.rb
-
-include:
-  - local: .gitlab/ci/rails/shared.gitlab-ci.yml
-
-default:
-  image: $DEFAULT_CI_IMAGE
-  tags:
-    - gitlab-org
-  # Default job timeout set to 90m https://gitlab.com/gitlab-com/gl-infra/infrastructure/-/issues/10520
-  timeout: 90m
-  interruptible: true
-
-stages:
-  - test
-
-dont-interrupt-me:
-  extends: .rules:dont-interrupt
-  stage: .pre
-  interruptible: false
-  script:
-    - echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
-
-.base-predictive:
-  needs:
-    - pipeline: $PARENT_PIPELINE_ID
-      job: detect-tests
-    - pipeline: $PARENT_PIPELINE_ID
-      job: setup-test-env
-    - pipeline: $PARENT_PIPELINE_ID
-      job: retrieve-tests-metadata
-    - pipeline: $PARENT_PIPELINE_ID
-      job: compile-test-assets
-  rules:
-    - when: always
-  variables:
-    RSPEC_TESTS_MAPPING_ENABLED: "true"
-
-<% if test_suite_prefix.nil? %>
-.base-rspec-predictive:
-  extends:
-    - .rspec-base-pg12
-    - .base-predictive
-  variables:
-    # We're using the FOSS one here because we want to exclude EE-only ones
-    # For EE-only ones, we have EE-only jobs.
-    RSPEC_TESTS_FILTER_FILE: "${RSPEC_MATCHING_TESTS_FOSS_PATH}"
-
-<% if rspec_files_per_test_level.dig(:migration, :files).size > 0 %>
-rspec migration predictive:
-  extends:
-    - .base-rspec-predictive
-    - .rspec-base-migration
-<% if rspec_files_per_test_level.dig(:migration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:migration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:background_migration, :files).size > 0 %>
-rspec background_migration predictive:
-  extends:
-    - .base-rspec-predictive
-    - .rspec-base-migration
-<% if rspec_files_per_test_level.dig(:background_migration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:background_migration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:unit, :files).size > 0 %>
-rspec unit predictive:
-  extends:
-    - .base-rspec-predictive
-<% if rspec_files_per_test_level.dig(:unit, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:unit, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:integration, :files).size > 0 %>
-rspec integration predictive:
-  extends:
-    - .base-rspec-predictive
-<% if rspec_files_per_test_level.dig(:integration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:integration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:system, :files).size > 0 %>
-rspec system predictive:
-  extends:
-    - .base-rspec-predictive
-<% if rspec_files_per_test_level.dig(:system, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:system, :parallelization) %>
-<% end %>
-<% end %>
-
-<% end %>
-
-<% if test_suite_prefix == 'ee/' %>
-.base-rspec-ee-predictive:
-  extends:
-    - .rspec-ee-base-pg12
-    - .base-predictive
-  variables:
-    RSPEC_TESTS_FILTER_FILE: "${RSPEC_MATCHING_TESTS_EE_PATH}"
-
-<% if rspec_files_per_test_level.dig(:migration, :files).size > 0 %>
-rspec-ee migration predictive:
-  extends:
-    - .base-rspec-ee-predictive
-    - .rspec-base-migration
-<% if rspec_files_per_test_level.dig(:migration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:migration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:background_migration, :files).size > 0 %>
-rspec-ee background_migration predictive:
-  extends:
-    - .base-rspec-ee-predictive
-    - .rspec-base-migration
-<% if rspec_files_per_test_level.dig(:background_migration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:background_migration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:unit, :files).size > 0 %>
-rspec-ee unit predictive:
-  extends:
-    - .base-rspec-ee-predictive
-<% if rspec_files_per_test_level.dig(:unit, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:unit, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:integration, :files).size > 0 %>
-rspec-ee integration predictive:
-  extends:
-    - .base-rspec-ee-predictive
-<% if rspec_files_per_test_level.dig(:integration, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:integration, :parallelization) %>
-<% end %>
-<% end %>
-
-<% if rspec_files_per_test_level.dig(:system, :files).size > 0 %>
-rspec-ee system predictive:
-  extends:
-    - .base-rspec-ee-predictive
-<% if rspec_files_per_test_level.dig(:system, :parallelization) > 1 %>
-  parallel: <%= rspec_files_per_test_level.dig(:system, :parallelization) %>
-<% end %>
-<% end %>
-
-<% end %>

.gitlab/ci/rails/shared.gitlab-ci.yml

@@ -1,218 +0,0 @@
-include:
-  - local: .gitlab/ci/global.gitlab-ci.yml
-  - local: .gitlab/ci/rules.gitlab-ci.yml
-
-.rules:dont-interrupt:
-  rules:
-    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
-      allow_failure: true
-    - if: $CI_MERGE_REQUEST_IID
-      when: manual
-      allow_failure: true
-
-#######################
-# rspec job base specs
-.rails-job-base:
-  extends:
-    - .default-retry
-    - .default-before_script
-    - .rails-cache
-
-.base-script:
-  script:
-    - source ./scripts/rspec_helpers.sh
-    # Only install knapsack after bundle install! Otherwise oddly some native
-    # gems could not be found under some circumstance. No idea why, hours wasted.
-    - run_timed_command "gem install knapsack --no-document"
-    - echo -e "\e[0Ksection_start:`date +%s`:gitaly-test-spawn[collapsed=true]\r\e[0KStarting Gitaly"
-    - section_start "gitaly-test-spawn" "Spawning Gitaly"; scripts/gitaly-test-spawn; section_end "gitaly-test-spawn"  # Do not use 'bundle exec' here
-    - echo -e "\e[0Ksection_end:`date +%s`:gitaly-test-spawn\r\e[0K"
-
-.single-db:
-  variables:
-    DECOMPOSED_DB: "false"
-
-.single-db-ci-connection:
-  extends: .single-db
-  variables:
-    CI_CONNECTION_DB: "true"
-
-.single-db-rspec:
-  extends: .single-db
-
-.single-db-ci-connection-rspec:
-  extends: .single-db-ci-connection
-
-.praefect-with-db:
-  variables:
-    GITALY_PRAEFECT_WITH_DB: '1'
-
-.rspec-base:
-  extends:
-    - .rails-job-base
-    - .base-artifacts
-  stage: test
-  variables:
-    RUBY_GC_MALLOC_LIMIT: 67108864
-    RUBY_GC_MALLOC_LIMIT_MAX: 134217728
-    RECORD_DEPRECATIONS: "true"
-    GEO_SECONDARY_PROXY: 0
-    SUCCESSFULLY_RETRIED_TEST_EXIT_CODE: 137
-  needs:
-    - job: "setup-test-env"
-    - job: "retrieve-tests-metadata"
-    - job: "compile-test-assets"
-    - job: "detect-tests"
-      optional: true
-  script:
-    - !reference [.base-script, script]
-    # We need to exclude background migration because unit tests run with
-    # spec/lib, yet background migration tests are also sitting there,
-    # and they should run on their own jobs so we don't need to run them
-    # in unit tests again.
-    - rspec_paralellized_job "--tag ~quarantine --tag ~level:background_migration"
-  allow_failure:
-    exit_codes: !reference [.rspec-base, variables, SUCCESSFULLY_RETRIED_TEST_EXIT_CODE]
-
-.base-artifacts:
-  artifacts:
-    expire_in: 31d
-    when: always
-    paths:
-      - coverage/
-      - crystalball/
-      - deprecations/
-      - knapsack/
-      - query_recorder/
-      - rspec/
-      - tmp/capybara/
-      - log/*.log
-    reports:
-      junit: ${JUNIT_RESULT_FILE}
-
-.rspec-base-migration:
-  script:
-    - !reference [.base-script, script]
-    - rspec_paralellized_job "--tag ~quarantine --tag ~zoekt"
-
-.rspec-base-pg12:
-  extends:
-    - .rspec-base
-    - .use-pg12
-
-.rspec-base-pg13:
-  extends:
-    - .rspec-base
-    - .use-pg13
-
-.rspec-base-pg13-as-if-foss:
-  extends:
-    - .rspec-base
-    - .as-if-foss
-    - .use-pg13
-  needs:
-    - job: "setup-test-env"
-    - job: "retrieve-tests-metadata"
-    - job: "compile-test-assets as-if-foss"
-    - job: "detect-tests"
-      optional: true
-
-.rspec-base-pg14:
-  extends:
-    - .rspec-base
-    - .use-pg14
-
-.rspec-ee-base-pg12:
-  extends:
-    - .rspec-base
-    - .use-pg12-es7-ee
-
-.rspec-ee-base-pg13:
-  extends:
-    - .rspec-base
-    - .use-pg13-es7-ee
-
-.rspec-ee-base-pg13-es8:
-  extends:
-    - .rspec-base
-    - .use-pg13-es8-ee
-    - .rails:rules:run-search-tests
-
-.rspec-ee-base-pg13-opensearch1:
-  extends:
-    - .rspec-base
-    - .use-pg13-opensearch1-ee
-    - .rails:rules:run-search-tests
-
-.rspec-ee-base-pg13-opensearch2:
-  extends:
-    - .rspec-base
-    - .use-pg13-opensearch2-ee
-    - .rails:rules:run-search-tests
-
-.rspec-ee-base-pg14:
-  extends:
-    - .rspec-base
-    - .use-pg14-es7-ee
-
-.rspec-ee-base-pg14-es8:
-  extends:
-    - .rspec-base
-    - .use-pg14-es8-ee
-    - .rails:rules:run-search-tests
-
-.rspec-ee-base-pg14-opensearch1:
-  extends:
-    - .rspec-base
-    - .use-pg14-opensearch1-ee
-    - .rails:rules:run-search-tests
-
-.rspec-ee-base-pg14-opensearch2:
-  extends:
-    - .rspec-base
-    - .use-pg14-opensearch2-ee
-    - .rails:rules:run-search-tests
-
-.db-job-base:
-  extends:
-    - .rails-job-base
-    - .rails:rules:ee-and-foss-migration
-    - .use-pg13
-  stage: test
-  needs: ["setup-test-env"]
-# rspec job base specs
-######################
-
-############################
-# rspec job parallel configs
-.rspec-migration-parallel:
-  parallel: 8
-
-.rspec-background-migration-parallel:
-  parallel: 4
-
-.rspec-ee-migration-parallel:
-  parallel: 2
-
-.rspec-ee-background-migration-parallel:
-  parallel: 2
-
-.rspec-unit-parallel:
-  parallel: 28
-
-.rspec-ee-unit-parallel:
-  parallel: 18
-
-.rspec-integration-parallel:
-  parallel: 12
-
-.rspec-ee-integration-parallel:
-  parallel: 6
-
-.rspec-system-parallel:
-  parallel: 28
-
-.rspec-ee-system-parallel:
-  parallel: 10
-# rspec job parallel configs
-############################

.gitlab/ci/release-environments.gitlab-ci.yml

@@ -1,23 +0,0 @@
----
-start-release-environments-pipeline:
-  allow_failure: true
-  extends:
-    - .release-environments:rules:start-release-environments-pipeline
-  stage: release-environments
-  # We do not want to have ALL global variables passed as trigger variables,
-  # as they cannot be overridden. See this issue for more context:
-  #
-  # https://gitlab.com/gitlab-org/gitlab/-/issues/387183
-  inherit:
-    variables:
-      - RUBY_VERSION
-
-  # These variables are set in the pipeline schedules.
-  # They need to be explicitly passed on to the child pipeline.
-  # https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword
-  variables:
-    # This is needed by `release-environments-build-cng-env` (`.gitlab/ci/release-environments/main.gitlab-ci.yml`).
-    PARENT_PIPELINE_ID: $CI_PIPELINE_ID
-  trigger:
-    strategy: depend
-    include: .gitlab/ci/release-environments/main.gitlab-ci.yml

.gitlab/ci/release-environments/main.gitlab-ci.yml

@@ -1,94 +0,0 @@
----
-default:
-  interruptible: true
-
-stages:
-  - prepare
-  - deploy
-
-include:
-  - local: .gitlab/ci/global.gitlab-ci.yml
-
-release-environments-build-cng-env:
-  allow_failure: true
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-alpine3.16
-  stage: prepare
-  needs:
-    # We need this job because we need its `cached-assets-hash.txt` artifact, so that we can pass the assets image tag to the downstream CNG pipeline.
-    - pipeline: $PARENT_PIPELINE_ID
-      job: build-assets-image
-  variables:
-    BUILD_ENV: build.env
-  before_script:
-    - source ./scripts/utils.sh
-    - install_gitlab_gem
-  script:
-    - 'ruby -r./scripts/trigger-build.rb -e "puts Trigger.variables_for_env_file(Trigger::CNG.new.variables)" > $BUILD_ENV'
-    - echo "GITLAB_ASSETS_TAG=$(assets_image_tag)" >> $BUILD_ENV
-    - ruby -e 'puts "FULL_RUBY_VERSION=#{RUBY_VERSION}"' >> build.env
-    - cat $BUILD_ENV
-  artifacts:
-    reports:
-      dotenv: $BUILD_ENV
-    paths:
-      - $BUILD_ENV
-    expire_in: 7 days
-    when: always
-
-release-environments-build-cng:
-  allow_failure: true
-  stage: prepare
-  needs: ["release-environments-build-cng-env"]
-  inherit:
-    variables: false
-  variables:
-    GITLAB_REF_SLUG: "${GITLAB_REF_SLUG}"
-    # CNG pipeline specific variables
-    GITLAB_VERSION: "${GITLAB_VERSION}"
-    GITLAB_TAG: "${GITLAB_TAG}"
-    GITLAB_ASSETS_TAG: "${GITLAB_ASSETS_TAG}"
-    FORCE_RAILS_IMAGE_BUILDS: "${FORCE_RAILS_IMAGE_BUILDS}"
-    CE_PIPELINE: "${CE_PIPELINE}"  # Based on https://docs.gitlab.com/ee/ci/jobs/job_control.html#check-if-a-variable-exists, `if: '$CE_PIPELINE'` will evaluate to `false` when this variable is empty
-    EE_PIPELINE: "${EE_PIPELINE}"  # Based on https://docs.gitlab.com/ee/ci/jobs/job_control.html#check-if-a-variable-exists, `if: '$EE_PIPELINE'` will evaluate to `false` when this variable is empty
-    GITLAB_ELASTICSEARCH_INDEXER_VERSION: "${GITLAB_ELASTICSEARCH_INDEXER_VERSION}"
-    GITLAB_KAS_VERSION: "${GITLAB_KAS_VERSION}"
-    GITLAB_METRICS_EXPORTER_VERSION: "${GITLAB_METRICS_EXPORTER_VERSION}"
-    GITLAB_PAGES_VERSION: "${GITLAB_PAGES_VERSION}"
-    GITLAB_SHELL_VERSION: "${GITLAB_SHELL_VERSION}"
-    GITALY_SERVER_VERSION: "${GITALY_SERVER_VERSION}"
-    RUBY_VERSION: "${FULL_RUBY_VERSION}"
-    IMAGE_TAG_EXT: "-${CI_COMMIT_SHORT_SHA}"
-  trigger:
-    project: gitlab-org/build/CNG-mirror
-    branch: $TRIGGER_BRANCH
-    strategy: depend
-
-release-environments-deploy-env:
-  allow_failure: true
-  stage: deploy
-  needs: ["release-environments-build-cng"]
-  variables:
-    DEPLOY_ENV: deploy.env
-  script:
-    - ./scripts/construct-release-environments-versions.rb > $DEPLOY_ENV
-  artifacts:
-    reports:
-      dotenv: $DEPLOY_ENV
-    paths:
-      - $DEPLOY_ENV
-    expire_in: 7 days
-    when: always
-
-release-environments-deploy:
-  allow_failure: true
-  stage: deploy
-  needs: ["release-environments-deploy-env"]
-  inherit:
-    variables: false
-  variables:
-    VERSIONS: "${VERSIONS}"
-    ENVIRONMENT: "${ENVIRONMENT}"
-  trigger:
-    project: gitlab-com/gl-infra/release-environments
-    branch: main
-    strategy: depend

.gitlab/ci/releases.gitlab-ci.yml

@@ -1,28 +1,36 @@
+---
+
 # Syncs any changes pushed to a stable branch to the corresponding
 # gitlab-foss/CE stable branch. We run this prior to any tests so that random
 # failures don't prevent a sync.
 .merge-train-sync:
   # We don't need/want any global before/after commands, so we overwrite these
   # settings.
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}alpine:edge
+  image: alpine:edge
   stage: sync
   before_script:
-    - apk add --no-cache --update curl bash jq
+    - apk add --no-cache --update curl bash
+  after_script: []
   script:
     - bash scripts/sync-stable-branch.sh
+  only:
+    variables:
+      - $CI_SERVER_HOST == "gitlab.com"
 
 sync-stable-branch:
-  extends:
-    - .releases:rules:canonical-dot-com-gitlab-stable-branch-only
-    - .merge-train-sync
+  extends: .merge-train-sync
   variables:
     SOURCE_PROJECT: gitlab-org/gitlab
     TARGET_PROJECT: gitlab-org/gitlab-foss
+  only:
+    refs:
+      - /^[\d-]+-stable-ee$/@gitlab-org/gitlab
 
 sync-security-branch:
-  extends:
-    - .releases:rules:canonical-dot-com-security-gitlab-stable-branch-only
-    - .merge-train-sync
+  extends: .merge-train-sync
   variables:
     SOURCE_PROJECT: gitlab-org/security/gitlab
     TARGET_PROJECT: gitlab-org/security/gitlab-foss
+  only:
+    refs:
+      - /^[\d-]+-stable-ee$/@gitlab-org/security/gitlab

.gitlab/ci/reports.gitlab-ci.yml

@@ -1,127 +1,236 @@
-include:
-  - template: Jobs/Code-Quality.gitlab-ci.yml
-  - template: Jobs/SAST.gitlab-ci.yml
-  - template: Jobs/Secret-Detection.gitlab-ci.yml
-  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
+# include:
+#   - template: Code-Quality.gitlab-ci.yml
+#   - template: Security/SAST.gitlab-ci.yml
+#   - template: Security/Dependency-Scanning.gitlab-ci.yml
+#   - template: Security/DAST.gitlab-ci.yml
 
+# We need to duplicate this job's definition because it seems it's impossible to
+# override an included `only.refs`.
+# See https://gitlab.com/gitlab-org/gitlab/issues/31371.
 code_quality:
   extends:
     - .default-retry
-    - .use-docker-in-docker
-  stage: lint
-  artifacts:
-    paths:
-      - gl-code-quality-report.json  # GitLab-specific
-  # extends generated values cannot overwrite values from included files
-  # Use !reference as a workaround here
-  rules: !reference [".reports:rules:code_quality", rules]
-  allow_failure: true
-
-.sast-analyzer:
-  # We need to re-`extends` from `sast` as the `extends` here overrides the one from the template.
-  extends:
-    - .default-retry
-    - sast
-  stage: lint
-  needs: []
-  artifacts:
-    paths:
-      - gl-sast-report.json  # GitLab-specific
-    expire_in: 1 week  # GitLab-specific
-  variables:
-    SAST_BRAKEMAN_LEVEL: 2  # GitLab-specific
-    SAST_EXCLUDED_PATHS: "qa, spec, doc, ee/spec, config/gitlab.yml.example, tmp"  # GitLab-specific
-    SAST_EXCLUDED_ANALYZERS: bandit, flawfinder, phpcs-security-audit, pmd-apex, security-code-scan, spotbugs, eslint, nodejs-scan, sobelow
-
-brakeman-sast:
-  rules: !reference [".reports:rules:brakeman-sast", rules]
-
-semgrep-sast:
-  rules: !reference [".reports:rules:semgrep-sast", rules]
-
-.secret-analyzer:
-  extends: .default-retry
-  stage: lint
-  needs: []
-  artifacts:
-    paths:
-      - gl-secret-detection-report.json  # GitLab-specific
-    expire_in: 1 week  # GitLab-specific
-
-secret_detection:
-  rules: !reference [".reports:rules:secret_detection", rules]
-
-.ds-analyzer:
-  # We need to re-`extends` from `dependency_scanning` as the `extends` here overrides the one from the template.
-  extends:
-    - .default-retry
-    - dependency_scanning
-  stage: lint
-  needs: []
-  variables:
-    DS_EXCLUDED_PATHS: "qa/qa/ee/fixtures/secure_premade_reports, spec, ee/spec, tmp"  # GitLab-specific
-    DS_EXCLUDED_ANALYZERS: "gemnasium-maven"
-  artifacts:
-    paths:
-      - gl-dependency-scanning-report.json  # GitLab-specific
-    expire_in: 1 week  # GitLab-specific
-
-gemnasium-dependency_scanning:
-  variables:
-    DS_REMEDIATE: "false"
-  rules: !reference [".reports:rules:gemnasium-dependency_scanning", rules]
-
-gemnasium-python-dependency_scanning:
-  rules: !reference [".reports:rules:gemnasium-python-dependency_scanning", rules]
-
-yarn-audit-dependency_scanning:
-  extends: .ds-analyzer
-  image: "${REGISTRY_HOST}/${REGISTRY_GROUP}/security-products/analyzers/npm-audit:1"
-  variables:
-    TOOL: yarn
-  rules: !reference [".reports:rules:yarn-audit-dependency_scanning", rules]
-
-# Analyze dependencies for malicious behavior
-# See https://gitlab.com/gitlab-com/gl-security/security-research/package-hunter
-.package_hunter-base:
-  extends: .default-retry
+    - .default-only
+    - .only:changes-code-backstage
   stage: test
-  image:
-    name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/security-products/package-hunter-cli:v1.3.3@sha256:1d3af9a61aa01549a62be17fa655fcf06271ac9e1b1e822c2a7930fa1d4a8a6b
-    entrypoint: [""]
-  variables:
-    HTR_user: '$PACKAGE_HUNTER_USER'
-    HTR_pass: '$PACKAGE_HUNTER_PASS'
-  needs: []
+  image: docker:stable
   allow_failure: true
-  before_script:
-    - rm -r spec locale .git app/assets/images doc/
-    - cd .. && tar -I "gzip --best" -cf gitlab.tgz gitlab/
+  services:
+    - docker:stable-dind
+  variables:
+    DOCKER_DRIVER: overlay2
+    DOCKER_TLS_CERTDIR: ""
+    CODE_QUALITY_IMAGE: "registry.gitlab.com/gitlab-org/security-products/codequality:12-5-stable"
   script:
-    - DEBUG=* node /usr/src/app/cli.js analyze --format gitlab --manager ${PACKAGE_MANAGER} gitlab.tgz | tee ${CI_PROJECT_DIR}/gl-dependency-scanning-report.json
-  after_script:
-    - mkdir ~/.aws
-    - '[[ -z "${AWS_SIEM_REPORT_INGESTION_CREDENTIALS_FILE}" ]] || mv "${AWS_SIEM_REPORT_INGESTION_CREDENTIALS_FILE}" ~/.aws/credentials'
-    - npm install --no-save --ignore-scripts @aws-sdk/client-s3@3.49.0
-    - scripts/ingest-reports-to-siem || true  # Allow legacy report to fail as we'll remove it in the future anyway
-    - scripts/ingest-reports-to-siem-devo
+    - |
+      if ! docker info &>/dev/null; then
+        if [ -z "$DOCKER_HOST" -a "$KUBERNETES_PORT" ]; then
+          export DOCKER_HOST='tcp://localhost:2375'
+        fi
+      fi
+    - docker pull --quiet "$CODE_QUALITY_IMAGE"
+    - docker run
+        --env SOURCE_CODE="$PWD"
+        --volume "$PWD":/code
+        --volume /var/run/docker.sock:/var/run/docker.sock
+        "$CODE_QUALITY_IMAGE" /code
   artifacts:
+    reports:
+      codequality: gl-code-quality-report.json
     paths:
-      - gl-dependency-scanning-report.json
+      - gl-code-quality-report.json
+    expire_in: 1 week
+  dependencies: []
+  except:
+    variables:
+      - $CODE_QUALITY_DISABLED
+
+# We need to duplicate this job's definition because it seems it's impossible to
+# override an included `only.refs`.
+# See https://gitlab.com/gitlab-org/gitlab/issues/31371.
+# Once https://gitlab.com/gitlab-org/gitlab/merge_requests/16487 will be deployed
+# to GitLab.com, we should be able to use the template and set SAST_DISABLE_DIND: "true".
+sast:
+  extends:
+    - .default-retry
+    - .default-only
+    - .only:changes-code-backstage-qa
+  stage: test
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+    DOCKER_TLS_CERTDIR: ""
+    SAST_BRAKEMAN_LEVEL: 2
+    SAST_EXCLUDED_PATHS: qa,spec,doc,ee/spec
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - export SAST_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
+    - |
+      if ! docker info &>/dev/null; then
+        if [ -z "$DOCKER_HOST" -a "$KUBERNETES_PORT" ]; then
+          export DOCKER_HOST='tcp://localhost:2375'
+        fi
+      fi
+    - | # this is required to avoid undesirable reset of Docker image ENV variables being set on build stage
+      function propagate_env_vars() {
+        CURRENT_ENV=$(printenv)
+
+        for VAR_NAME; do
+          echo $CURRENT_ENV | grep "${VAR_NAME}=" > /dev/null && echo "--env $VAR_NAME "
+        done
+      }
+    - |
+      docker run \
+        $(propagate_env_vars \
+          SAST_BANDIT_EXCLUDED_PATHS \
+          SAST_ANALYZER_IMAGES \
+          SAST_ANALYZER_IMAGE_PREFIX \
+          SAST_ANALYZER_IMAGE_TAG \
+          SAST_DEFAULT_ANALYZERS \
+          SAST_PULL_ANALYZER_IMAGES \
+          SAST_BRAKEMAN_LEVEL \
+          SAST_FLAWFINDER_LEVEL \
+          SAST_GITLEAKS_ENTROPY_LEVEL \
+          SAST_GOSEC_LEVEL \
+          SAST_EXCLUDED_PATHS \
+          SAST_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
+          SAST_PULL_ANALYZER_IMAGE_TIMEOUT \
+          SAST_RUN_ANALYZER_TIMEOUT \
+          SAST_JAVA_VERSION \
+          ANT_HOME \
+          ANT_PATH \
+          GRADLE_PATH \
+          JAVA_OPTS \
+          JAVA_PATH \
+          JAVA_8_VERSION \
+          JAVA_11_VERSION \
+          MAVEN_CLI_OPTS \
+          MAVEN_PATH \
+          MAVEN_REPO_PATH \
+          SBT_PATH \
+          FAIL_NEVER \
+        ) \
+        --volume "$PWD:/code" \
+        --volume /var/run/docker.sock:/var/run/docker.sock \
+        "registry.gitlab.com/gitlab-org/security-products/sast:$SAST_VERSION" /app/bin/run /code
+  artifacts:
+    expire_in: 7 days
+    paths:
+      - gl-sast-report.json
+    reports:
+      sast: gl-sast-report.json
+  dependencies: []
+  only:
+    variables:
+      - $GITLAB_FEATURES =~ /\bsast\b/
+  except:
+    variables:
+      - $SAST_DISABLED
+
+# We need to duplicate this job's definition because it seems it's impossible to
+# override an included `only.refs`.
+# See https://gitlab.com/gitlab-org/gitlab/issues/31371.
+dependency_scanning:
+  extends:
+    - .default-retry
+    - .default-only
+    - .only:changes-code-backstage-qa
+  stage: test
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+    DOCKER_TLS_CERTDIR: ""
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - export DS_VERSION=${SP_VERSION:-$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')}
+    - |
+      if ! docker info &>/dev/null; then
+        if [ -z "$DOCKER_HOST" -a "$KUBERNETES_PORT" ]; then
+          export DOCKER_HOST='tcp://localhost:2375'
+        fi
+      fi
+    - | # this is required to avoid undesirable reset of Docker image ENV variables being set on build stage
+      function propagate_env_vars() {
+        CURRENT_ENV=$(printenv)
+
+        for VAR_NAME; do
+          echo $CURRENT_ENV | grep "${VAR_NAME}=" > /dev/null && echo "--env $VAR_NAME "
+        done
+      }
+    - |
+      docker run \
+        $(propagate_env_vars \
+          DS_ANALYZER_IMAGES \
+          DS_ANALYZER_IMAGE_PREFIX \
+          DS_ANALYZER_IMAGE_TAG \
+          DS_DEFAULT_ANALYZERS \
+          DS_EXCLUDED_PATHS \
+          DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
+          DS_PULL_ANALYZER_IMAGE_TIMEOUT \
+          DS_RUN_ANALYZER_TIMEOUT \
+          DS_PYTHON_VERSION \
+          DS_PIP_DEPENDENCY_PATH \
+          PIP_INDEX_URL \
+          PIP_EXTRA_INDEX_URL \
+        ) \
+        --volume "$PWD:/code" \
+        --volume /var/run/docker.sock:/var/run/docker.sock \
+        "registry.gitlab.com/gitlab-org/security-products/dependency-scanning:$DS_VERSION" /code
+  artifacts:
     reports:
       dependency_scanning: gl-dependency-scanning-report.json
-    expire_in: 1 week
+  dependencies: []
+  only:
+    variables:
+      - $GITLAB_FEATURES =~ /\bdependency_scanning\b/
+  except:
+    variables:
+      - $DEPENDENCY_SCANNING_DISABLED
 
-package_hunter-yarn:
+# We need to duplicate this job's definition because it seems it's impossible to
+# override an included `only.refs`.
+# See https://gitlab.com/gitlab-org/gitlab/issues/31371.
+dast:
   extends:
-    - .package_hunter-base
-    - .reports:rules:package_hunter-yarn
+    - .default-retry
+    - .default-only
+    - .only:changes-code-qa
+    - .only-review
+  stage: qa
+  needs: ["review-deploy"]
+  dependencies: ["review-deploy"]
+  before_script:
+    - export DAST_WEBSITE="$(cat review_app_url.txt)"
+  image:
+    name: "registry.gitlab.com/gitlab-org/security-products/dast:$CI_SERVER_VERSION_MAJOR-$CI_SERVER_VERSION_MINOR-stable"
   variables:
-    PACKAGE_MANAGER: yarn
-
-package_hunter-bundler:
-  extends:
-    - .package_hunter-base
-    - .reports:rules:package_hunter-bundler
-  variables:
-    PACKAGE_MANAGER: bundler
+  # URL to scan:
+  # DAST_WEBSITE: https://example.com/
+  #
+  # Time limit for target availability (scan is attempted even when timeout):
+  # DAST_TARGET_AVAILABILITY_TIMEOUT: 60
+  #
+  # Set these variables to scan with an authenticated user:
+  # DAST_AUTH_URL: https://example.com/sign-in
+  # DAST_USERNAME: john.doe@example.com
+  # DAST_PASSWORD: john-doe-password
+  # DAST_USERNAME_FIELD: session[user] # the name of username field at the sign-in HTML form
+  # DAST_PASSWORD_FIELD: session[password] # the name of password field at the sign-in HTML form
+  # DAST_AUTH_EXCLUDE_URLS: http://example.com/sign-out,http://example.com/sign-out-2 # optional: URLs to skip during the authenticated scan; comma-separated, no spaces in between
+  #
+  # Perform ZAP Full Scan, which includes both passive and active scanning:
+  # DAST_FULL_SCAN_ENABLED: "true"
+  allow_failure: true
+  script:
+    - export DAST_WEBSITE=${DAST_WEBSITE:-$(cat environment_url.txt)}
+    - /analyze -t $DAST_WEBSITE
+  artifacts:
+    expire_in: 7 days
+    paths:
+      - gl-dast-report.json
+    reports:
+      dast: gl-dast-report.json

.gitlab/ci/review-apps/dast-api.gitlab-ci.yml

@@ -1,35 +0,0 @@
-include:
-  - template: DAST-API.gitlab-ci.yml
-
-dast_api:
-  needs: ["review-deploy"]
-  # Uncomment resource_group if DAST_API_PROFILE is changed to an active scan
-  # resource_group: dast_api_scan
-  rules:
-    - when: never
-
-dast_api_graphql:
-  extends: dast_api
-  variables:
-    DAST_API_GRAPHQL: /api/graphql
-    DAST_API_PROFILE: Passive
-    DAST_API_TARGET_URL: ${CI_ENVIRONMENT_URL}
-    DAST_API_OVERRIDES_ENV: "{\"headers\":{\"Authorization\":\"Bearer $REVIEW_APPS_ROOT_TOKEN\"}}"
-  rules:
-    - !reference [".reports:rules:schedule-dast", rules]
-    #
-    # To run this job in an MR pipeline, use this rule:
-    # - !reference [".reports:rules:test-dast", rules]
-
-dast_api_rest:
-  extends: dast_api
-  variables:
-    DAST_API_OPENAPI: doc/api/openapi/openapi_v2.yaml
-    DAST_API_PROFILE: Passive
-    DAST_API_TARGET_URL: ${CI_ENVIRONMENT_URL}
-    DAST_API_OVERRIDES_ENV: "{\"headers\":{\"Authorization\":\"Bearer $REVIEW_APPS_ROOT_TOKEN\"}}"
-  rules:
-    - !reference [".reports:rules:schedule-dast", rules]
-    #
-    # To run this job in an MR pipeline, use this rule:
-    # - !reference [".reports:rules:test-dast", rules]

.gitlab/ci/review-apps/dast.gitlab-ci.yml

@@ -1,106 +0,0 @@
-.dast_conf:
-  tags:
-    - prm
-  # For scheduling dast job
-  extends:
-    - .reports:rules:schedule-dast
-  image:
-    name: "${CI_TEMPLATE_REGISTRY_HOST}/security-products/dast:$DAST_VERSION"
-  resource_group: dast_scan
-  variables:
-    DAST_USERNAME_FIELD: "name:user[login]"
-    DAST_PASSWORD_FIELD: "name:user[password]"
-    DAST_SUBMIT_FIELD: "css:.js-sign-in-button"
-    DAST_FULL_SCAN_ENABLED: "true"
-    DAST_VERSION: 3
-    GIT_STRATEGY: none
-    # -Xmx is used to set the JVM memory to 6GB to prevent DAST OutOfMemoryError.
-    DAST_ZAP_CLI_OPTIONS: "-Xmx6144m"
-  before_script:
-    - 'export DAST_WEBSITE="${DAST_WEBSITE:-$(cat environment_url.txt)}"'
-    - 'export DAST_AUTH_URL="${DAST_WEBSITE}/users/sign_in"'
-    - 'export DAST_PASSWORD="${REVIEW_APPS_ROOT_PASSWORD}"'
-    # Help pages are excluded from scan as they are static pages.
-    # profile/two_factor_auth is excluded from scan to prevent 2FA from being turned on from user profile, which will reduce coverage.
-    - 'DAST_EXCLUDE_URLS="${DAST_WEBSITE}/help/.*,${DAST_WEBSITE}/-/profile/two_factor_auth,${DAST_WEBSITE}/users/sign_out"'
-    # Exclude the automatically generated monitoring project from being tested due to https://gitlab.com/gitlab-org/gitlab/-/issues/260362
-    - 'export DAST_EXCLUDE_URLS="${DAST_EXCLUDE_URLS},${DAST_WEBSITE}/gitlab-instance-.*"'
-  needs: ["review-deploy"]
-  stage: dast
-  # Default job timeout set to 90m and dast rules needs 2h to so that it won't timeout.
-  timeout: 3h
-  # Add retry because of intermittent connection problems. See https://gitlab.com/gitlab-org/gitlab/-/issues/244313
-  retry: 1
-  artifacts:
-    paths:
-      - gl-dast-report.json  # GitLab-specific
-    reports:
-      dast: gl-dast-report.json
-    expire_in: 1 week  # GitLab-specific
-  allow_failure: true
-
-# DAST scan with a subset of Release scan rules.
-# ZAP rule details can be found at https://www.zaproxy.org/docs/alerts/
-
-dast:anti-clickjacking-header:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user1"
-    DAST_ONLY_INCLUDE_RULES: "10020"
-  script:
-    - /analyze
-
-dast:xss-persistant:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user2"
-    DAST_ONLY_INCLUDE_RULES: "40014"
-  script:
-    - /analyze
-
-dast:insecure-http-method:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user3"
-    DAST_ONLY_INCLUDE_RULES: "90028"
-  script:
-    - /analyze
-
-dast:server-side-template-inj:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user4"
-    DAST_ONLY_INCLUDE_RULES: "90035"
-  script:
-    - /analyze
-
-dast:server-side-template-inj-blind:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user5"
-    DAST_ONLY_INCLUDE_RULES: "90035"
-  script:
-    - /analyze
-
-dast:session-fixation:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user6"
-    DAST_ONLY_INCLUDE_RULES: "40013"
-  script:
-    - /analyze
-
-dast:xss-dombased:
-  extends:
-    - .dast_conf
-  variables:
-    DAST_USERNAME: "user10"
-    DAST_ONLY_INCLUDE_RULES: "40026"
-  script:
-    - /analyze

.gitlab/ci/review-apps/main.gitlab-ci.yml

@@ -1,203 +0,0 @@
-default:
-  interruptible: true
-
-stages:
-  - prepare
-  - deploy
-  - post-deploy
-  - qa
-  - post-qa
-  - dast
-
-include:
-  - local: .gitlab/ci/global.gitlab-ci.yml
-  - local: .gitlab/ci/review-apps/rules.gitlab-ci.yml
-  - local: .gitlab/ci/review-apps/qa.gitlab-ci.yml
-  - local: .gitlab/ci/review-apps/dast.gitlab-ci.yml
-  - local: .gitlab/ci/review-apps/dast-api.gitlab-ci.yml
-
-.base-before_script: &base-before_script
-  - source ./scripts/utils.sh
-  - source ./scripts/review_apps/review-apps.sh
-
-dont-interrupt-me:
-  extends: .rules:dont-interrupt
-  stage: prepare
-  interruptible: false
-  script:
-    - echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
-
-review-build-cng-env:
-  extends:
-    - .default-retry
-    - .review:rules:review-build-cng
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-alpine3.16
-  stage: prepare
-  needs:
-    # We need this job because we need its `cached-assets-hash.txt` artifact, so that we can pass the assets image tag to the downstream CNG pipeline.
-    - pipeline: $PARENT_PIPELINE_ID
-      job: build-assets-image
-  variables:
-    BUILD_ENV: build.env
-  before_script:
-    - source ./scripts/utils.sh
-    - install_gitlab_gem
-  script:
-    - 'ruby -r./scripts/trigger-build.rb -e "puts Trigger.variables_for_env_file(Trigger::CNG.new.variables)" > $BUILD_ENV'
-    - echo "GITLAB_ASSETS_TAG=$(assets_image_tag)" >> $BUILD_ENV
-    - ruby -e 'puts "FULL_RUBY_VERSION=#{RUBY_VERSION}"' >> build.env
-    - cat $BUILD_ENV
-  artifacts:
-    reports:
-      dotenv: $BUILD_ENV
-    paths:
-      - $BUILD_ENV
-    expire_in: 7 days
-    when: always
-
-review-build-cng:
-  extends: .review:rules:review-build-cng
-  stage: prepare
-  needs: ["review-build-cng-env"]
-  inherit:
-    variables: false
-  variables:
-    TOP_UPSTREAM_SOURCE_PROJECT: "${TOP_UPSTREAM_SOURCE_PROJECT}"
-    TOP_UPSTREAM_SOURCE_REF: "${TOP_UPSTREAM_SOURCE_REF}"
-    TOP_UPSTREAM_SOURCE_JOB: "${TOP_UPSTREAM_SOURCE_JOB}"
-    TOP_UPSTREAM_SOURCE_SHA: "${TOP_UPSTREAM_SOURCE_SHA}"
-    TOP_UPSTREAM_MERGE_REQUEST_PROJECT_ID: "${TOP_UPSTREAM_MERGE_REQUEST_PROJECT_ID}"
-    TOP_UPSTREAM_MERGE_REQUEST_IID: "${TOP_UPSTREAM_MERGE_REQUEST_IID}"
-    GITLAB_REF_SLUG: "${GITLAB_REF_SLUG}"
-    # CNG pipeline specific variables
-    GITLAB_VERSION: "${GITLAB_VERSION}"
-    GITLAB_TAG: "${GITLAB_TAG}"
-    GITLAB_ASSETS_TAG: "${GITLAB_ASSETS_TAG}"
-    FORCE_RAILS_IMAGE_BUILDS: "${FORCE_RAILS_IMAGE_BUILDS}"
-    CE_PIPELINE: "${CE_PIPELINE}"  # Based on https://docs.gitlab.com/ee/ci/jobs/job_control.html#check-if-a-variable-exists, `if: '$CE_PIPELINE'` will evaluate to `false` when this variable is empty
-    EE_PIPELINE: "${EE_PIPELINE}"  # Based on https://docs.gitlab.com/ee/ci/jobs/job_control.html#check-if-a-variable-exists, `if: '$EE_PIPELINE'` will evaluate to `false` when this variable is empty
-    GITLAB_ELASTICSEARCH_INDEXER_VERSION: "${GITLAB_ELASTICSEARCH_INDEXER_VERSION}"
-    GITLAB_KAS_VERSION: "${GITLAB_KAS_VERSION}"
-    GITLAB_METRICS_EXPORTER_VERSION: "${GITLAB_METRICS_EXPORTER_VERSION}"
-    GITLAB_PAGES_VERSION: "${GITLAB_PAGES_VERSION}"
-    GITLAB_SHELL_VERSION: "${GITLAB_SHELL_VERSION}"
-    GITLAB_WORKHORSE_VERSION: "${GITLAB_WORKHORSE_VERSION}"
-    GITALY_SERVER_VERSION: "${GITALY_SERVER_VERSION}"
-    RUBY_VERSION: "${FULL_RUBY_VERSION}"
-  trigger:
-    project: gitlab-org/build/CNG-mirror
-    branch: $TRIGGER_BRANCH
-    strategy: depend
-
-.review-workflow-base:
-  image: ${REVIEW_APPS_IMAGE}
-  retry:
-    max: 2  # This is confusing but this means "3 runs at max"
-  variables:
-    HOST_SUFFIX: "${CI_ENVIRONMENT_SLUG}"
-    DOMAIN: "-${CI_ENVIRONMENT_SLUG}.${REVIEW_APPS_DOMAIN}"
-    GITLAB_HELM_CHART_REF: "febc4ad69acb7bba0eeb4a62daa577d0b7c3ee71"  # 6.9.1: https://gitlab.com/gitlab-org/charts/gitlab/-/commit/febc4ad69acb7bba0eeb4a62daa577d0b7c3ee71
-  environment:
-    name: review/${CI_COMMIT_REF_SLUG}${SCHEDULE_TYPE}  # No separator for SCHEDULE_TYPE so it's compatible as before and looks nice without it
-    url: https://gitlab-${CI_ENVIRONMENT_SLUG}.${REVIEW_APPS_DOMAIN}
-    on_stop: trigger-review-stop
-
-review-deploy:
-  extends:
-    - .review-workflow-base
-    - .review:rules:review-deploy
-  stage: deploy
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}dtzar/helm-kubectl:3.9.3
-  needs:
-    - review-build-cng
-    - review-delete-deployment  # We always want to start from a clean slate (i.e. no helm release, no k8s namespace)
-  cache:
-    key: "review-deploy-dependencies-charts-${GITLAB_HELM_CHART_REF}-v1"
-    paths:
-      - "gitlab-${GITLAB_HELM_CHART_REF}"
-  environment:
-    action: start
-  before_script:
-    - export GITLAB_SHELL_VERSION=$(<GITLAB_SHELL_VERSION)
-    - export GITALY_VERSION=$(<GITALY_SERVER_VERSION)
-    - export GITLAB_WORKHORSE_VERSION=$(<GITLAB_WORKHORSE_VERSION)
-    - echo "${CI_ENVIRONMENT_URL}" > environment_url.txt
-    - echo "QA_GITLAB_URL=${CI_ENVIRONMENT_URL}" > environment.env
-    - *base-before_script
-    - !reference [".use-kube-context", before_script]
-  script:
-    - run_timed_command "retry delete_helm_release"
-    - run_timed_command "check_kube_domain"
-    - run_timed_command "download_chart"
-    - run_timed_command "deploy" || (display_deployment_debug && exit 1)
-    - run_timed_command "verify_deploy" || (display_deployment_debug && exit 1)
-    - run_timed_command "disable_sign_ups" || (display_deployment_debug && exit 1)
-    - run_timed_command "verify_commit_sha" || (display_deployment_debug && exit 1)
-  after_script:
-    # Run seed-dast-test-data.sh only when DAST_RUN is set to true. This is to pupulate review app with data for DAST scan.
-    # Set DAST_RUN to true when jobs are manually scheduled.
-    - if [ "$DAST_RUN" == "true" ]; then source scripts/review_apps/seed-dast-test-data.sh; TRACE=1 trigger_proj_user_creation; fi
-  artifacts:
-    paths:
-      - environment_url.txt
-      - curl-logs/
-    reports:
-      dotenv: environment.env
-    expire_in: 7 days
-    when: always
-
-review-deploy-sample-projects:
-  extends:
-    - .review-workflow-base
-    - .review:rules:review-deploy
-  stage: deploy
-  needs: ["review-deploy"]
-  environment:
-    action: prepare
-  before_script:
-    - export GITLAB_SHELL_VERSION=$(<GITLAB_SHELL_VERSION)
-    - export GITALY_VERSION=$(<GITALY_SERVER_VERSION)
-    - export GITLAB_WORKHORSE_VERSION=$(<GITLAB_WORKHORSE_VERSION)
-    - echo "${CI_ENVIRONMENT_URL}" > environment_url.txt
-    - *base-before_script
-    - !reference [".use-kube-context", before_script]
-  script:
-    - date
-    - create_sample_projects
-
-.review-stop-base:
-  extends: .review-workflow-base
-  environment:
-    action: stop
-  variables:
-    # We're cloning the repo instead of downloading the script for now
-    # because some repos are private and CI_JOB_TOKEN cannot access files.
-    # See https://gitlab.com/gitlab-org/gitlab/issues/191273
-    GIT_DEPTH: 1
-
-review-delete-deployment:
-  extends:
-    - .review-stop-base
-    - .review:rules:review-delete-deployment
-  dependencies: []
-  stage: prepare
-  before_script:
-    - source ./scripts/utils.sh
-    - source ./scripts/review_apps/review-apps.sh
-    - !reference [".use-kube-context", before_script]
-  script:
-    - retry delete_helm_release
-
-trigger-review-stop:
-  extends:
-    - .review-stop-base
-    - .review:rules:trigger-review-stop
-  stage: deploy
-  needs: []
-  before_script:
-    - source ./scripts/utils.sh
-    - install_gitlab_gem
-  script:
-    - review_stop_job_id="$(scripts/api/get_job_id.rb --pipeline-id "${PARENT_PIPELINE_ID}" --job-name "review-stop")"
-    - |
-      curl --request POST --header "Private-Token: ${PROJECT_TOKEN_FOR_CI_SCRIPTS_API_USAGE}" "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/jobs/${review_stop_job_id}/play"

.gitlab/ci/review-apps/qa.gitlab-ci.yml

@@ -1,182 +0,0 @@
-include:
-  - project: gitlab-org/quality/pipeline-common
-    ref: 5.1.1
-    file:
-      - /ci/base.gitlab-ci.yml
-      - /ci/allure-report.yml
-      - /ci/knapsack-report.yml
-  - template: Verify/Browser-Performance.gitlab-ci.yml
-
-.test-variables:
-  variables:
-    QA_GENERATE_ALLURE_REPORT: "true"
-    QA_CAN_TEST_PRAEFECT: "false"
-    GITLAB_USERNAME: "root"
-    GITLAB_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
-    GITLAB_ADMIN_USERNAME: "root"
-    GITLAB_ADMIN_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
-    GITLAB_QA_ADMIN_ACCESS_TOKEN: "${REVIEW_APPS_ROOT_TOKEN}"
-    GITHUB_ACCESS_TOKEN: "${QA_GITHUB_ACCESS_TOKEN}"
-
-.bundle-base:
-  extends:
-    - .qa-cache
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3
-  before_script:
-    - cd qa && bundle install
-
-.review-qa-base:
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3-git-2.36-lfs-2.9-chrome-${CHROME_VERSION}-docker-${DOCKER_VERSION}-gcloud-383-kubectl-1.23
-  extends:
-    - .use-docker-in-docker
-    - .bundle-base
-    - .test-variables
-  stage: qa
-  needs:
-    - review-deploy
-    - download-knapsack-report
-  variables:
-    GIT_LFS_SKIP_SMUDGE: 1
-    WD_INSTALL_DIR: /usr/local/bin
-    RSPEC_REPORT_OPTS: --force-color --order random --format documentation --format RspecJunitFormatter --out tmp/rspec-${CI_JOB_ID}.xml
-  script:
-    - QA_COMMAND="bundle exec bin/qa ${QA_SCENARIO} ${QA_GITLAB_URL} -- ${QA_TESTS} ${RSPEC_REPORT_OPTS}"
-    - echo "Running - '${QA_COMMAND}'"
-    - eval "$QA_COMMAND"
-  after_script:
-    - |
-      echo "Sentry errors for the current review-app test run can be found via following url:"
-      echo "https://sentry.gitlab.net/gitlab/gitlab-review-apps/releases/$(echo "${CI_COMMIT_SHA}" | cut -c1-11)/all-events/."
-  artifacts:
-    paths:
-      - qa/tmp
-    reports:
-      junit: qa/tmp/rspec-*.xml
-    expire_in: 7 days
-    when: always
-
-# Store knapsack report as artifact so the same report is reused across all jobs
-download-knapsack-report:
-  extends:
-    - .bundle-base
-    - .rules:prepare-report
-  stage: prepare
-  script:
-    - bundle exec rake "knapsack:download[qa]"
-  allow_failure: true
-  artifacts:
-    paths:
-      - qa/knapsack/review-qa-*.json
-    expire_in: 1 day
-
-review-qa-smoke:
-  extends:
-    - .review-qa-base
-    - .rules:qa-smoke
-  variables:
-    QA_SCENARIO: Test::Instance::Smoke
-    QA_RUN_TYPE: review-qa-smoke
-  retry: 1
-
-review-qa-blocking:
-  extends:
-    - .review-qa-base
-    - .rules:qa-blocking
-  variables:
-    QA_SCENARIO: Test::Instance::ReviewBlocking
-    QA_RUN_TYPE: review-qa-blocking
-  retry: 1
-review-qa-blocking-parallel:
-  extends:
-    - review-qa-blocking
-    - .rules:qa-blocking-parallel
-  parallel: 10
-
-review-qa-non-blocking:
-  extends:
-    - .review-qa-base
-    - .rules:qa-non-blocking
-  variables:
-    QA_SCENARIO: Test::Instance::ReviewNonBlocking
-    QA_RUN_TYPE: review-qa-non-blocking
-  when: manual
-  allow_failure: true
-review-qa-non-blocking-parallel:
-  extends:
-    - review-qa-non-blocking
-    - .rules:qa-non-blocking-parallel
-  parallel: 5
-
-browser_performance:
-  extends:
-    - .default-retry
-    - .review:rules:review-performance
-  stage: qa
-  needs: ["review-deploy"]
-  variables:
-    URL: environment_url.txt
-
-e2e-test-report:
-  extends:
-    - .generate-allure-report-base
-    - .rules:prepare-report
-  stage: post-qa
-  variables:
-    ALLURE_JOB_NAME: e2e-review-qa
-    ALLURE_PROJECT_PATH: $CI_PROJECT_PATH
-    ALLURE_RESULTS_GLOB: qa/tmp/allure-results
-    ALLURE_MERGE_REQUEST_IID: $CI_MERGE_REQUEST_IID
-    GITLAB_AUTH_TOKEN: $PROJECT_TOKEN_FOR_CI_SCRIPTS_API_USAGE
-    GIT_STRATEGY: none
-  allow_failure: true
-  when: always
-
-upload-knapsack-report:
-  extends:
-    - .generate-knapsack-report-base
-    - .bundle-base
-  stage: post-qa
-  variables:
-    QA_KNAPSACK_REPORT_FILE_PATTERN: $CI_PROJECT_DIR/qa/tmp/knapsack/*/*.json
-
-delete-test-resources:
-  extends:
-    - .bundle-base
-    - .rules:prepare-report
-  stage: post-qa
-  variables:
-    QA_TEST_RESOURCES_FILE_PATTERN: $CI_PROJECT_DIR/qa/tmp/test-resources-*.json
-    GITLAB_QA_ACCESS_TOKEN: $REVIEW_APPS_ROOT_TOKEN
-  script:
-    - export GITLAB_ADDRESS="$QA_GITLAB_URL"
-    - bundle exec rake "test_resources:delete[$QA_TEST_RESOURCES_FILE_PATTERN]"
-  allow_failure: true
-  when: always
-
-notify-slack:
-  extends:
-    - .notify-slack-qa
-    - .qa-cache
-    - .rules:main-run
-  stage: post-qa
-  variables:
-    RUN_WITH_BUNDLE: "true"
-    QA_PATH: qa
-    ALLURE_JOB_NAME: e2e-review-qa
-    SLACK_ICON_EMOJI: ci_failing
-    STATUS_SYM: ☠️
-    STATUS: failed
-    TYPE: "(review-app) "
-  when: on_failure
-  script:
-    - bundle exec prepare-stage-reports --input-files "${CI_PROJECT_DIR}/qa/tmp/rspec-*.xml"
-    - !reference [.notify-slack-qa, script]
-
-export-test-metrics:
-  extends:
-    - .bundle-base
-    - .rules:main-run
-  stage: post-qa
-  when: always
-  script:
-    - bundle exec rake "ci:export_test_metrics[tmp/test-metrics-*.json]"

.gitlab/ci/review-apps/rules.gitlab-ci.yml

@@ -1,170 +0,0 @@
-# ------------------------------------------
-# Conditions
-# ------------------------------------------
-# Specific specs passed
-.specific-specs: &specific-specs
-  if: $QA_TESTS != ""
-
-# No specific specs passed
-.all-specs: &all-specs
-  if: $QA_TESTS == ""
-
-# No specific specs in mr pipeline
-.all-specs-mr: &all-specs-mr
-  if: '($CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" || $CI_MERGE_REQUEST_EVENT_TYPE == "detached") && $QA_TESTS == ""'
-  when: manual
-
-# Triggered by change pattern
-.app-changes: &app-changes
-  if: $APP_CHANGE_TRIGGER == "true"
-
-# Run all tests when framework changes present or explicitly enabled full suite execution
-.qa-run-all-tests: &qa-run-all-tests
-  if: $QA_FRAMEWORK_CHANGES == "true" || $QA_RUN_ALL_TESTS == "true" || $QA_RUN_ALL_E2E_LABEL == "true"
-
-.default-branch: &default-branch
-  if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
-
-.if-merge-request: &if-merge-request
-  if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" || $CI_MERGE_REQUEST_EVENT_TYPE == "detached"'
-
-.if-merge-request-labels-run-review-app: &if-merge-request-labels-run-review-app
-  if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-review-app/'
-
-.if-dot-com-ee-schedule-nightly-child-pipeline: &if-dot-com-ee-schedule-nightly-child-pipeline
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_PATH == "gitlab-org/gitlab" && $CI_PIPELINE_SOURCE == "parent_pipeline" && $SCHEDULE_TYPE == "nightly"'
-
-# ------------------------------------------
-# Changes patterns
-# ------------------------------------------
-.ci-review-patterns: &ci-review-patterns
-  - ".gitlab-ci.yml"
-  - ".gitlab/ci/frontend.gitlab-ci.yml"
-  - ".gitlab/ci/build-images.gitlab-ci.yml"
-  - ".gitlab/ci/review.gitlab-ci.yml"
-  - ".gitlab/ci/review-apps/**/*"
-  - "scripts/review_apps/**/*"
-  - "scripts/trigger-build.rb"
-  - "{,ee/,jh/}{bin,config}/**/*.rb"
-
-# ------------------------------------------
-# Conditions set
-# ------------------------------------------
-.qa-manual: &qa-manual
-  when: manual
-  allow_failure: true
-  variables:
-    QA_TESTS: ""
-
-.never-when-qa-run-all-tests-or-no-specific-specs:
-  - <<: *qa-run-all-tests
-    when: never
-  - <<: *all-specs
-    when: never
-
-.never-when-specific-specs-always-when-qa-run-all-tests:
-  - *qa-run-all-tests
-  - <<: *specific-specs
-    when: manual
-    allow_failure: true
-    variables:
-      QA_TESTS: ""
-
-# ------------------------------------------
-# Prepare
-# ------------------------------------------
-.rules:dont-interrupt:
-  rules:
-    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
-      allow_failure: true
-    - if: $CI_MERGE_REQUEST_IID
-      when: manual
-      allow_failure: true
-
-.review:rules:review-build-cng:
-  rules:
-    - when: always
-
-.review:rules:review-delete-deployment:
-  rules:
-    - when: on_success
-
-# ------------------------------------------
-# Deploy
-# ------------------------------------------
-.review:rules:review-deploy:
-  rules:
-    - when: on_success
-
-.review:rules:trigger-review-stop:
-  rules:
-    - when: manual
-      allow_failure: true
-
-# ------------------------------------------
-# Test
-# ------------------------------------------
-.rules:qa-smoke:
-  rules:
-    # always trigger smoke suite if review pipeline got triggered by specific changes in application code
-    - <<: *app-changes
-      variables:
-        QA_TESTS: ""  # unset QA_TESTS even if specific tests were inferred from stage label
-    - *qa-run-all-tests
-    - if: $QA_SUITES =~ /Test::Instance::Smoke/
-    - *qa-manual
-
-.rules:qa-blocking:
-  rules:
-    - <<: *app-changes
-      when: never
-    - !reference [.never-when-qa-run-all-tests-or-no-specific-specs]
-    - if: $QA_SUITES =~ /Test::Instance::ReviewBlocking/
-.rules:qa-blocking-parallel:
-  rules:
-    # always trigger blocking suite if review pipeline got triggered by specific changes in application code
-    - <<: *app-changes
-      variables:
-        QA_TESTS: ""  # unset QA_TESTS even if specific tests were inferred from stage label
-    - !reference [.never-when-specific-specs-always-when-qa-run-all-tests]
-    - if: $QA_SUITES =~ /Test::Instance::ReviewBlocking/
-
-.rules:qa-non-blocking:
-  rules:
-    - !reference [.never-when-qa-run-all-tests-or-no-specific-specs]
-    - if: $QA_SUITES =~ /Test::Instance::ReviewNonBlocking/
-.rules:qa-non-blocking-parallel:
-  rules:
-    - !reference [.never-when-specific-specs-always-when-qa-run-all-tests]
-    - *all-specs-mr  # set full suite to manual when no specific specs passed in mr
-    - if: $QA_SUITES =~ /Test::Instance::ReviewNonBlocking/
-
-.review:rules:review-performance:
-  rules:
-    - if: '$DAST_RUN == "true"'  # Skip this job when DAST is run
-      when: never
-    - <<: *if-merge-request-labels-run-review-app  # we explicitly don't allow the job to fail in that case
-    - <<: *if-merge-request  # we explicitly don't allow the job to fail in that case
-      changes: *ci-review-patterns
-    - when: on_success
-      allow_failure: true
-
-# ------------------------------------------
-# DAST
-# ------------------------------------------
-.reports:rules:schedule-dast:
-  rules:
-    - if: '$DAST_DISABLED || $GITLAB_FEATURES !~ /\bdast\b/'
-      when: never
-    - <<: *if-dot-com-ee-schedule-nightly-child-pipeline
-
-# ------------------------------------------
-# Prepare/Report
-# ------------------------------------------
-.rules:prepare-report:
-  rules:
-    - when: always
-
-.rules:main-run:
-  rules:
-    - *default-branch

.gitlab/ci/review.gitlab-ci.yml

@@ -1,135 +1,320 @@
-review-cleanup:
+.review-docker:
   extends:
+    - .default-tags
     - .default-retry
-    - .review:rules:review-cleanup
-  image: ${REVIEW_APPS_IMAGE}
-  stage: prepare
-  needs: []
-  environment:
-    name: review/regular-cleanup
-    action: access
+    - .default-only
+  image: registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-qa-alpine
+  services:
+    - docker:19.03.0-dind
+  tags:
+    - gitlab-org
+    - docker
   variables:
-    GIT_DEPTH: 1
+    DOCKER_DRIVER: overlay2
+    DOCKER_HOST: tcp://docker:2375
+    GITLAB_EDITION: "ce"
+
+build-qa-image:
+  extends:
+    - .review-docker
+    - .only:variables-canonical-dot-com
+    - .except:refs-deploy
+    - .only:changes-code-qa
+  stage: prepare
+  script:
+    - '[[ ! -d "ee/" ]] || export GITLAB_EDITION="ee"'
+    - export QA_MASTER_IMAGE="${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab/gitlab-${GITLAB_EDITION}-qa:master"
+    - export QA_IMAGE="${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab/gitlab-${GITLAB_EDITION}-qa:${CI_COMMIT_REF_SLUG}"
+    - echo "${CI_JOB_TOKEN}" | docker login --username gitlab-ci-token --password-stdin ${CI_REGISTRY}
+    - time docker pull "${QA_MASTER_IMAGE}"
+    - time docker build --cache-from "${QA_MASTER_IMAGE}" --tag ${QA_IMAGE} --file ./qa/Dockerfile ./
+    - time docker push ${QA_IMAGE}
+
+.base-review-cleanup:
+  extends:
+    - .default-tags
+    - .default-retry
+    - .default-only
+  stage: prepare
+  image: registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-charts-build-base
+  allow_failure: true
+  environment:
+    name: review/auto-cleanup
+    action: stop
   before_script:
     - source scripts/utils.sh
-    - !reference [".use-kube-context", before_script]
     - install_gitlab_gem
-    - setup_gcloud
   script:
-    - scripts/review_apps/automated_cleanup.rb --dry-run="${DRY_RUN:-false}" || (scripts/slack review-apps-monitoring "☠️ \`${CI_JOB_NAME}\` failed! ☠️ See ${CI_JOB_URL} - <https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/review-apps.md#review-cleanup-job-failed|📗 RUNBOOK 📕>" warning "GitLab Bot" && exit 1);
+    - ruby -rrubygems scripts/review_apps/automated_cleanup.rb
+
+schedule:review-cleanup:
+  extends:
+    - .base-review-cleanup
+    - .only-review-schedules
+
+manual:review-cleanup:
+  extends:
+    - .base-review-cleanup
+    - .only:changes-code-qa
+  when: manual
+
+.review-build-cng-base:
+  extends:
+    - .default-tags
+    - .default-retry
+    - .default-only
+  image: ruby:2.6-alpine
+  stage: review-prepare
+  before_script:
+    - source scripts/utils.sh
+    - install_api_client_dependencies_with_apk
+    - install_gitlab_gem
+  dependencies: []
+  script:
+    - BUILD_TRIGGER_TOKEN=$REVIEW_APPS_BUILD_TRIGGER_TOKEN ./scripts/trigger-build cng
+
+review-build-cng:
+  extends:
+    - .review-build-cng-base
+    - .only-review
+    - .only:changes-code-qa
+  needs: ["gitlab:assets:compile pull-cache"]
+
+schedule:review-build-cng:
+  extends:
+    - .review-build-cng-base
+    - .only-review-schedules
+  needs: ["gitlab:assets:compile pull-cache"]
+
+.review-workflow-base:
+  extends:
+    - .default-tags
+    - .default-retry
+    - .default-only
+  image: registry.gitlab.com/gitlab-org/gitlab-build-images:gitlab-charts-build-base
+  dependencies: []
+  variables:
+    HOST_SUFFIX: "${CI_ENVIRONMENT_SLUG}"
+    DOMAIN: "-${CI_ENVIRONMENT_SLUG}.${REVIEW_APPS_DOMAIN}"
+    GITLAB_HELM_CHART_REF: "v2.5.1"
+    GITLAB_EDITION: "ce"
+  environment:
+    name: review/${CI_COMMIT_REF_NAME}
+    url: https://gitlab-${CI_ENVIRONMENT_SLUG}.${REVIEW_APPS_DOMAIN}
+    on_stop: review-stop
+
+.review-deploy-base:
+  extends: .review-workflow-base
+  stage: review
+  allow_failure: true
+  before_script:
+    - '[[ ! -d "ee/" ]] || export GITLAB_EDITION="ee"'
+    - export GITLAB_SHELL_VERSION=$(<GITLAB_SHELL_VERSION)
+    - export GITALY_VERSION=$(<GITALY_SERVER_VERSION)
+    - export GITLAB_WORKHORSE_VERSION=$(<GITLAB_WORKHORSE_VERSION)
+    - echo "${CI_ENVIRONMENT_URL}" > review_app_url.txt
+    - source scripts/utils.sh
+    - install_api_client_dependencies_with_apk
+    - source scripts/review_apps/review-apps.sh
+  script:
+    - check_kube_domain
+    - ensure_namespace
+    - install_tiller
+    - install_external_dns
+    - download_chart
+    - date
+    - deploy || (display_deployment_debug && exit 1)
+  artifacts:
+    paths: [review_app_url.txt]
+    expire_in: 2 days
+    when: always
+
+review-deploy:
+  extends:
+    - .review-deploy-base
+    - .only-review
+    - .only:changes-code-qa
+
+schedule:review-deploy:
+  extends:
+    - .review-deploy-base
+    - .only-review-schedules
+
+.base-review-stop:
+  extends:
+    - .review-workflow-base
+    - .only-review
+    - .only:changes-code-qa
+  environment:
+    action: stop
+  variables:
+    GIT_STRATEGY: none
+  before_script:
+    # We don't clone the repo by using GIT_STRATEGY: none and only download the
+    # single script we need here so it's much faster than cloning.
+    - apk add --update openssl
+    - wget $CI_PROJECT_URL/raw/$CI_COMMIT_SHA/scripts/review_apps/review-apps.sh
+    - wget $CI_PROJECT_URL/raw/$CI_COMMIT_SHA/scripts/utils.sh
+    - source utils.sh
+    - source review-apps.sh
+
+review-stop-failed-deployment:
+  extends: .base-review-stop
+  stage: prepare
+  script:
+    - delete_failed_release
 
 review-stop:
-  extends:
-    - review-cleanup
-    - .review:rules:review-stop
-  environment:
-    name: review/${CI_COMMIT_REF_SLUG}${SCHEDULE_TYPE}  # No separator for SCHEDULE_TYPE so it's compatible as before and looks nice without it
-    action: stop
-  resource_group: review/${CI_COMMIT_REF_SLUG}${SCHEDULE_TYPE}  # CI_ENVIRONMENT_SLUG is not available here and we want this to be the same as the environment
-  before_script:
-    - source ./scripts/utils.sh
-    - source ./scripts/review_apps/review-apps.sh
-    - !reference [".use-kube-context", before_script]
-  script:
-    - retry delete_helm_release
-
-.base-review-checks:
-  extends:
-    - .default-retry
-  image: ${REVIEW_APPS_IMAGE}
-  stage: prepare
-  before_script:
-    - source scripts/utils.sh
-    - setup_gcloud
-    - !reference [".use-kube-context", before_script]
-
-review-k8s-resources-count-checks:
-  extends:
-    - .base-review-checks
-    - .review:rules:review-k8s-resources-count-checks
-  needs:
-    - job: review-cleanup
-      optional: true
-  environment:
-    name: review/k8s-resources-count-checks
-    action: verify
-  script:
-    - scripts/review_apps/k8s-resources-count-checks.sh || (scripts/slack review-apps-monitoring "☠️ \`${CI_JOB_NAME}\` failed! ☠️ See ${CI_JOB_URL} - <https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/review-apps.md#review-k8s-resources-count-checks-job-failed|📗 RUNBOOK 📕>" warning "GitLab Bot" && exit 1);
-
-review-gcp-quotas-checks:
-  extends:
-    - .base-review-checks
-    - .review:rules:review-gcp-quotas-checks
-  needs: []
-  environment:
-    name: review/gcp-quotas-checks
-    action: verify
-  script:
-    - ruby scripts/review_apps/gcp-quotas-checks.rb || (scripts/slack review-apps-monitoring "☠️ \`${CI_JOB_NAME}\` failed! ☠️ See ${CI_JOB_URL} - <https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/review-apps.md#review-gcp-quotas-checks-job-failed|📗 RUNBOOK 📕>" warning "GitLab Bot" && exit 1);
-
-start-review-app-pipeline:
-  extends:
-    - .review:rules:start-review-app-pipeline
-  resource_group: review/${CI_COMMIT_REF_SLUG}${SCHEDULE_TYPE}  # CI_ENVIRONMENT_SLUG is not available here and we want this to be the same as the environment
+  extends: .base-review-stop
   stage: review
-  needs:
-    - job: e2e-test-pipeline-generate
-    - job: build-assets-image
-      artifacts: false
-  # We do not want to have ALL global variables passed as trigger variables,
-  # as they cannot be overridden. See this issue for more context:
-  #
-  # https://gitlab.com/gitlab-org/gitlab/-/issues/387183
-  inherit:
-    variables:
-      - CHROME_VERSION
-      - REGISTRY_GROUP
-      - REGISTRY_HOST
-      - REVIEW_APPS_DOMAIN
-      - REVIEW_APPS_GCP_PROJECT
-      - REVIEW_APPS_GCP_REGION
-      - REVIEW_APPS_IMAGE
-      - RUBY_VERSION
+  when: manual
+  allow_failure: true
+  script:
+    - delete_release
 
-  # These variables are set in the pipeline schedules.
-  # They need to be explicitly passed on to the child pipeline.
-  # https://docs.gitlab.com/ee/ci/pipelines/multi_project_pipelines.html#pass-cicd-variables-to-a-downstream-pipeline-by-using-the-variables-keyword
+.review-qa-base:
+  extends:
+    - .review-docker
+    - .only-review
+    - .only:changes-code-qa
+  stage: qa
+  allow_failure: true
   variables:
-    # This is needed by `review-build-cng-env` (`.gitlab/ci/review-apps/main.gitlab-ci.yml`).
-    PARENT_PIPELINE_ID: $CI_PIPELINE_ID
-    SCHEDULE_TYPE: $SCHEDULE_TYPE
-    DAST_RUN: $DAST_RUN
-    SKIP_MESSAGE: Skipping review-app due to mr containing only quarantine changes!
-  trigger:
-    strategy: depend
-    include:
-      - artifact: review-app-pipeline.yml
-        job: e2e-test-pipeline-generate
+    QA_ARTIFACTS_DIR: "${CI_PROJECT_DIR}/qa"
+    QA_CAN_TEST_GIT_PROTOCOL_V2: "false"
+    QA_DEBUG: "true"
+    GITLAB_USERNAME: "root"
+    GITLAB_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
+    GITLAB_ADMIN_USERNAME: "root"
+    GITLAB_ADMIN_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
+    GITHUB_ACCESS_TOKEN: "${REVIEW_APPS_QA_GITHUB_ACCESS_TOKEN}"
+    EE_LICENSE: "${REVIEW_APPS_EE_LICENSE}"
+  needs: ["review-deploy"]
+  dependencies: ["review-deploy"]
+  artifacts:
+    paths:
+      - ./qa/gitlab-qa-run-*
+    expire_in: 7 days
+    when: always
+  before_script:
+    - '[[ ! -d "ee/" ]] || export GITLAB_EDITION="ee"'
+    - export QA_IMAGE="${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab/gitlab-${GITLAB_EDITION}-qa:${CI_COMMIT_REF_SLUG}"
+    - export CI_ENVIRONMENT_URL="$(cat review_app_url.txt)"
+    - echo "${CI_ENVIRONMENT_URL}"
+    - echo "${QA_IMAGE}"
+    - source scripts/utils.sh
+    - install_api_client_dependencies_with_apk
+    - gem install gitlab-qa --no-document ${GITLAB_QA_VERSION:+ --version ${GITLAB_QA_VERSION}}
+
+review-qa-smoke:
+  extends: .review-qa-base
+  script:
+    - gitlab-qa Test::Instance::Smoke "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}"
+
+review-qa-all:
+  extends: .review-qa-base
+  when: manual
+  parallel: 5
+  script:
+    - export KNAPSACK_REPORT_PATH=knapsack/master_report.json
+    - export KNAPSACK_TEST_FILE_PATTERN=qa/specs/features/**/*_spec.rb
+    - gitlab-qa Test::Instance::Any "${QA_IMAGE}" "${CI_ENVIRONMENT_URL}" -- --format RspecJunitFormatter --out tmp/rspec-${CI_JOB_ID}.xml --format html --out tmp/rspec.htm --color --format documentation
+
+.review-performance-base:
+  extends: .review-docker
+  stage: qa
+  allow_failure: true
+  before_script:
+    - export CI_ENVIRONMENT_URL="$(cat review_app_url.txt)"
+    - echo "${CI_ENVIRONMENT_URL}"
+    - mkdir -p gitlab-exporter
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - mkdir -p sitespeed-results
+  script:
+    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results "${CI_ENVIRONMENT_URL}"
+  after_script:
+    - mv sitespeed-results/data/performance.json performance.json
+  artifacts:
+    paths:
+      - sitespeed-results/
+    reports:
+      performance: performance.json
+
+review-performance:
+  extends:
+    - .review-performance-base
+    - .only-review
+    - .only:changes-code-qa
+  needs: ["review-deploy"]
+  dependencies: ["review-deploy"]
+  before_script:
+    - export CI_ENVIRONMENT_URL="$(cat review_app_url.txt)"
+    - echo "${CI_ENVIRONMENT_URL}"
+    - mkdir -p gitlab-exporter
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - mkdir -p sitespeed-results
+  script:
+    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results "${CI_ENVIRONMENT_URL}"
+  after_script:
+    - mv sitespeed-results/data/performance.json performance.json
+  artifacts:
+    paths:
+      - sitespeed-results/
+    reports:
+      performance: performance.json
+
+schedule:review-performance:
+  extends:
+    - .review-performance-base
+    - .only-review-schedules
+  needs: ["schedule:review-deploy"]
+  dependencies: ["schedule:review-deploy"]
+
+parallel-spec-reports:
+  extends:
+    - .default-tags
+    - .default-only
+    - .only-review
+    - .only:changes-code-qa
+  image: ruby:2.6-alpine
+  stage: post-qa
+  dependencies: ["review-qa-all"]
+  variables:
+    NEW_PARALLEL_SPECS_REPORT: qa/report-new.html
+    BASE_ARTIFACT_URL: "${CI_PROJECT_URL}/-/jobs/${CI_JOB_ID}/artifacts/file/qa/"
+  allow_failure: true
+  when: manual
+  artifacts:
+    when: always
+    paths:
+      - qa/report-new.html
+      - qa/gitlab-qa-run-*
+    reports:
+      junit: qa/gitlab-qa-run-*/**/rspec-*.xml
+  script:
+    - apk add --update build-base libxml2-dev libxslt-dev && rm -rf /var/cache/apk/*
+    - gem install nokogiri --no-document
+    - cd qa/gitlab-qa-run-*/gitlab-*
+    - ARTIFACT_DIRS=$(pwd |rev| awk -F / '{print $1,$2}' | rev | sed s_\ _/_)
+    - cd -
+    - '[[ -f $NEW_PARALLEL_SPECS_REPORT ]] || echo "{}" > ${NEW_PARALLEL_SPECS_REPORT}'
+    - scripts/merge-html-reports ${NEW_PARALLEL_SPECS_REPORT} ${BASE_ARTIFACT_URL}${ARTIFACT_DIRS} qa/gitlab-qa-run-*/**/rspec.htm
 
 danger-review:
   extends:
+    - .default-tags
     - .default-retry
-    - .ruby-node-cache
-    - .review:rules:danger
+    - .default-cache
+    - .default-only
+    - .except:refs-master-tags-stable-deploy
+  image: registry.gitlab.com/gitlab-org/gitlab-build-images:danger
   stage: test
-  needs: []
-  before_script:
-    - source scripts/utils.sh
-    - bundle_install_script "--with danger"
-    - yarn_install_script
+  dependencies: []
+  only:
+    variables:
+      - $DANGER_GITLAB_API_TOKEN
   script:
-    # ${DANGER_DANGERFILE} is used by Jihulab for customizing danger support: https://jihulab.com/gitlab-cn/gitlab/-/blob/main-jh/jh/.gitlab-ci.yml
-    - >
-      if [ -z "$DANGER_GITLAB_API_TOKEN" ]; then
-        run_timed_command danger_as_local
-      else
-        danger_id=$(echo -n ${DANGER_GITLAB_API_TOKEN} | md5sum | awk '{print $1}' | cut -c5-10)
-        run_timed_command "bundle exec danger --fail-on-errors=true --verbose --danger_id=\"${danger_id}\" --dangerfile=\"${DANGER_DANGERFILE:-Dangerfile}\""
-      fi
-
-danger-review-local:
-  extends:
-    - danger-review
-    - .review:rules:danger-local
-  script:
-    - run_timed_command danger_as_local
+    - git version
+    - node --version
+    - yarn install --frozen-lockfile --cache-folder .yarn-cache --prefer-offline
+    - danger --fail-on-errors=true

.gitlab/ci/setup.gitlab-ci.yml

@@ -2,172 +2,46 @@
 # rubygems.org in the future.
 cache gems:
   extends:
+    - .default-tags
     - .default-retry
-    - .ruby-cache
+    - .default-cache
     - .default-before_script
-    - .setup:rules:cache-gems
-  stage: prepare
-  needs: []
+    - .only:variables-canonical-dot-com
+    - .only:changes-code-backstage-qa
+  stage: test
+  dependencies: ["setup-test-env"]
+  needs: ["setup-test-env"]
   variables:
-    BUNDLE_WITHOUT: ""
-    BUNDLE_WITH: "production:development:test"
     SETUP_DB: "false"
   script:
-    - echo -e "\e[0Ksection_start:`date +%s`:bundle-package[collapsed=true]\r\e[0KPackaging gems"
-    - bundle config set cache_all true
-    - run_timed_command "bundle package --all-platforms"
-    - echo -e "\e[0Ksection_end:`date +%s`:bundle-package\r\e[0K"
+    - bundle package --all --all-platforms
   artifacts:
     paths:
       - vendor/cache
-    expire_in: 31d
+  only:
+    refs:
+      - master
+      - tags
 
-.predictive-job:
+.minimal-job:
   extends:
+    - .default-tags
     - .default-retry
-  needs: []
-
-.absolutely-predictive-job:
-  extends:
-    - .predictive-job
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}alpine:edge
-  variables:
-    GIT_STRATEGY: none
-
-dont-interrupt-me:
-  extends:
-    - .absolutely-predictive-job
-    - .setup:rules:dont-interrupt-me
-  stage: sync
-  interruptible: false
-  script:
-    - echo "This jobs makes sure this pipeline won't be interrupted! See https://docs.gitlab.com/ee/ci/yaml/#interruptible."
+    - .default-only
+    - .only:changes-code-backstage
+  dependencies: []
 
 gitlab_git_test:
-  extends:
-    - .predictive-job
-    - .setup:rules:gitlab_git_test
-  stage: test
+  extends: .minimal-job
   script:
     - spec/support/prepare-gitlab-git-test-for-commit --check-for-changes
 
-verify-ruby-3.0:
-  extends:
-    - .absolutely-predictive-job
-    - .setup:rules:verify-ruby-3.0
-  stage: prepare
+no_ee_check:
+  extends: .minimal-job
   script:
-    - echo 'Please remove label ~"pipeline:run-in-ruby2" so we do test against Ruby 3.0 (default version) before merging the merge request'
-    - exit 1
-
-verify-tests-yml:
-  extends:
-    - .setup:rules:verify-tests-yml
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-alpine3.16
-  stage: test
-  needs: []
-  script:
-    - source scripts/utils.sh
-    - install_tff_gem
-    - scripts/verify-tff-mapping
-
-verify-approvals:
-  extends:
-    - .predictive-job
-    - .setup:rules:jh-contribution
-  script:
-    - source scripts/utils.sh
-    - install_gitlab_gem
-    - tooling/bin/find_app_sec_approval
-
-generate-frontend-fixtures-mapping:
-  extends:
-    - .setup:rules:generate-frontend-fixtures-mapping
-    - .use-pg13
-    - .rails-cache
-  needs: ["setup-test-env"]
-  stage: prepare
-  before_script:
-    - !reference [.default-before_script, before_script]
-    - source ./scripts/rspec_helpers.sh
-    - section_start "gitaly-test-spawn" "Spawning Gitaly"; scripts/gitaly-test-spawn; section_end "gitaly-test-spawn";  # Do not use 'bundle exec' here
-  script:
-    - generate_frontend_fixtures_mapping
-  artifacts:
-    expire_in: 7d
-    paths:
-      - ${FRONTEND_FIXTURES_MAPPING_PATH}
-
-detect-tests:
-  extends: .rails:rules:detect-tests
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-slim
-  needs: []
-  stage: prepare
-  variables:
-    RSPEC_TESTS_MAPPING_ENABLED: "true"
-  before_script:
-    - apt-get update && apt-get install -y curl  # Not present in ruby-slim, so we add it manually
-  script:
-    - source ./scripts/utils.sh
-    - source ./scripts/rspec_helpers.sh
-    - install_gitlab_gem
-    - install_tff_gem
-    - install_activesupport_gem
-    - retrieve_tests_mapping
-    - retrieve_frontend_fixtures_mapping
-    - |
-      if [ -n "$CI_MERGE_REQUEST_IID" ]; then
-        mkdir -p $(dirname "$RSPEC_CHANGED_FILES_PATH")
-
-        tooling/bin/predictive_tests
-
-        filter_rspec_matched_foss_tests ${RSPEC_MATCHING_TESTS_PATH} ${RSPEC_MATCHING_TESTS_FOSS_PATH};
-        filter_rspec_matched_ee_tests ${RSPEC_MATCHING_TESTS_PATH} ${RSPEC_MATCHING_TESTS_EE_PATH};
-
-        echoinfo "Changed files: $(cat $RSPEC_CHANGED_FILES_PATH)";
-        echoinfo "Related FOSS RSpec tests: $(cat $RSPEC_MATCHING_TESTS_FOSS_PATH)";
-        echoinfo "Related EE RSpec tests: $(cat $RSPEC_MATCHING_TESTS_EE_PATH)";
-        echoinfo "Related JS files: $(cat $RSPEC_MATCHING_JS_FILES_PATH)";
-      fi
-  artifacts:
-    expire_in: 7d
-    paths:
-      - ${FRONTEND_FIXTURES_MAPPING_PATH}
-      - ${RSPEC_CHANGED_FILES_PATH}
-      - ${RSPEC_MATCHING_JS_FILES_PATH}
-      - ${RSPEC_MATCHING_TESTS_EE_PATH}
-      - ${RSPEC_MATCHING_TESTS_FOSS_PATH}
-      - ${RSPEC_MATCHING_TESTS_PATH}
-      - ${RSPEC_VIEWS_INCLUDING_PARTIALS_PATH}
-
-detect-previous-failed-tests:
-  extends:
-    - detect-tests
-    - .rails:rules:detect-previous-failed-tests
-  variables:
-    PREVIOUS_FAILED_TESTS_DIR: tmp/previous_failed_tests/
-  script:
-    - source ./scripts/utils.sh
-    - source ./scripts/rspec_helpers.sh
-    - retrieve_failed_tests "${PREVIOUS_FAILED_TESTS_DIR}" "oneline" "previous"
-  artifacts:
-    expire_in: 7d
-    paths:
-      - ${PREVIOUS_FAILED_TESTS_DIR}
-
-e2e-test-pipeline-generate:
-  extends:
-    - .qa-job-base
-    - .predictive-job
-    - .qa:rules:determine-e2e-tests
-  stage: prepare
-  variables:
-    ENV_FILE: $CI_PROJECT_DIR/qa_tests_vars.env
-    COLORIZED_LOGS: "true"
-  script:
-    - bundle exec rake "ci:detect_changes[$ENV_FILE]"
-    - cd $CI_PROJECT_DIR && scripts/generate-e2e-pipeline
-  artifacts:
-    expire_in: 1 day
-    paths:
-      - '*-pipeline.yml'
+    - scripts/no-ee-check
+  only:
+    variables:
+      - $CI_PROJECT_NAME == "gitlab-foss"
+      - $CI_PROJECT_NAME == "gitlab-ce"  # Support former project name for forks/mirrors
+      - $CI_PROJECT_NAME == "gitlabhq"  # Support former project name for dev

.gitlab/ci/static-analysis.gitlab-ci.yml

@@ -1,219 +0,0 @@
-.static-analysis-base:
-  extends:
-    - .default-retry
-    - .default-before_script
-  stage: lint
-  needs: []
-  variables:
-    SETUP_DB: "false"
-    ENABLE_SPRING: "1"
-    # Disable warnings in browserslist which can break on backports
-    # https://github.com/browserslist/browserslist/blob/a287ec6/node.js#L367-L384
-    BROWSERSLIST_IGNORE_OLD_DATA: "true"
-    GRAPHQL_SCHEMA_APOLLO_FILE: "tmp/tests/graphql/gitlab_schema_apollo.graphql"
-
-update-static-analysis-cache:
-  extends:
-    - .static-analysis-base
-    - .rubocop-job-cache-push
-    - .shared:rules:update-cache
-  stage: prepare
-  script:
-    # Silence cop offenses for rules with "grace period".
-    # This will notify Slack if offenses were silenced.
-    # For the moment we only cache `tmp/rubocop_cache` so we don't need to run all the tasks.
-    - run_timed_command "fail_on_warnings bundle exec rake rubocop:check:graceful"
-
-static-analysis:
-  extends:
-    - .static-analysis-base
-    - .static-analysis-cache
-    - .static-analysis:rules:static-analysis
-  parallel: 2
-  script:
-    - yarn_install_script
-    - fail_on_warnings scripts/static-analysis
-
-static-analysis as-if-foss:
-  extends:
-    - static-analysis
-    - .static-analysis:rules:static-analysis-as-if-foss
-    - .as-if-foss
-
-static-verification-with-database:
-  extends:
-    - .static-analysis-base
-    - .rubocop-job-cache
-    - .static-analysis:rules:static-verification-with-database
-    - .use-pg13
-  script:
-    - bundle exec rake lint:static_verification_with_database
-  variables:
-    SETUP_DB: "true"
-
-generate-apollo-graphql-schema:
-  extends:
-    - .static-analysis-base
-    - .frontend:rules:default-frontend-jobs
-  image:
-    name: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images:apollo
-    entrypoint: [""]
-  needs: ['graphql-schema-dump']
-  variables:
-    USE_BUNDLE_INSTALL: "false"
-  script:
-    - apollo client:download-schema --config=config/apollo.config.js ${GRAPHQL_SCHEMA_APOLLO_FILE}
-  artifacts:
-    name: graphql-schema-apollo
-    paths:
-      - "${GRAPHQL_SCHEMA_APOLLO_FILE}"
-
-generate-apollo-graphql-schema as-if-foss:
-  extends:
-    - generate-apollo-graphql-schema
-    - .frontend:rules:eslint-as-if-foss
-    - .as-if-foss
-  needs: ['graphql-schema-dump as-if-foss']
-
-eslint:
-  extends:
-    - .static-analysis-base
-    - .yarn-cache
-    - .frontend:rules:default-frontend-jobs
-  needs: ['generate-apollo-graphql-schema']
-  variables:
-    USE_BUNDLE_INSTALL: "false"
-  script:
-    - yarn_install_script
-    - run_timed_command "yarn run lint:eslint:all"
-
-eslint as-if-foss:
-  extends:
-    - eslint
-    - .frontend:rules:eslint-as-if-foss
-    - .as-if-foss
-  needs: ['generate-apollo-graphql-schema as-if-foss']
-
-haml-lint:
-  extends:
-    - .static-analysis-base
-    - .ruby-cache
-    - .static-analysis:rules:haml-lint
-  script:
-    - run_timed_command "bundle exec haml-lint --parallel app/views"
-  artifacts:
-    expire_in: 31d
-    when: always
-    paths:
-      - tmp/feature_flags/
-
-haml-lint ee:
-  extends:
-    - "haml-lint"
-    - .static-analysis:rules:haml-lint-ee
-  script:
-    - run_timed_command "bundle exec haml-lint --parallel ee/app/views"
-
-rubocop:
-  extends:
-    - .static-analysis-base
-    - .rubocop-job-cache
-    - .static-analysis:rules:rubocop
-  needs:
-    - job: detect-tests
-      optional: true
-  variables:
-    RUBOCOP_TARGET_FILES: "tmp/rubocop_target_files.txt"
-  script:
-    - |
-      # For non-merge request, or when RUN_ALL_RUBOCOP is 'true', run all RuboCop rules
-      if [ -z "${CI_MERGE_REQUEST_IID}" ] || [ "${RUN_ALL_RUBOCOP}" == "true" ]; then
-        # Silence cop offenses for rules with "grace period".
-        # We won't notify Slack if offenses were silenced to avoid frequent messages.
-        # Job `update-static-analysis-cache` takes care of Slack notifications every 2 hours.
-        unset CI_SLACK_WEBHOOK_URL
-        run_timed_command "fail_on_warnings bundle exec rake rubocop:check:graceful"
-      else
-        cat "${RSPEC_CHANGED_FILES_PATH}" | ruby -e 'print $stdin.read.split(" ").select { |f| File.exist?(f) }.join(" ")' > "$RUBOCOP_TARGET_FILES"
-        # Skip running RuboCop if there's no target files
-        if [ -s "${RUBOCOP_TARGET_FILES}" ]; then
-          run_timed_command "fail_on_warnings bundle exec rubocop --parallel --force-exclusion $(cat ${RUBOCOP_TARGET_FILES})"
-        else
-          echoinfo "Nothing interesting changed for RuboCop. Skipping."
-        fi
-      fi
-
-qa:metadata-lint:
-  extends:
-    - .static-analysis-base
-    - .static-analysis:rules:qa:metadata-lint
-  before_script:
-    - !reference [.default-before_script, before_script]
-    - cd qa/
-    - bundle_install_script
-  script:
-    - run_timed_command "bundle exec bin/qa Test::Instance::All http://localhost:3000 --test-metadata-only"
-    - cd ..
-    - run_timed_command "./scripts/qa/testcases-check qa/tmp/test-metadata.json"
-    - run_timed_command "./scripts/qa/quarantine-types-check qa/tmp/test-metadata.json"
-  variables:
-    USE_BUNDLE_INSTALL: "false"
-    SETUP_DB: "false"
-    QA_EXPORT_TEST_METRICS: "false"
-    # Disable warnings in browserslist which can break on backports
-    # https://github.com/browserslist/browserslist/blob/a287ec6/node.js#L367-L384
-    BROWSERSLIST_IGNORE_OLD_DATA: "true"
-  artifacts:
-    expire_in: 31d
-    when: always
-    paths:
-      - qa/tmp/
-
-feature-flags-usage:
-  extends:
-    - .static-analysis-base
-    - .rubocop-job-cache
-    - .static-analysis:rules:rubocop
-  script:
-    # We need to disable the cache for this cop since it creates files under tmp/feature_flags/*.used,
-    # the cache would prevent these files from being created.
-    - run_timed_command "fail_on_warnings bundle exec rubocop --only Gitlab/MarkUsedFeatureFlags --cache false"
-  artifacts:
-    expire_in: 31d
-    when: always
-    paths:
-      - tmp/feature_flags/
-
-semgrep-appsec-custom-rules:
-  stage: lint
-  extends:
-    - .semgrep-appsec-custom-rules:rules
-  image: returntocorp/semgrep
-  needs: []
-  script:
-    # Required to avoid a timeout https://github.com/returntocorp/semgrep/issues/5395
-    - git fetch origin master
-    # Include/exclude list isn't ideal https://github.com/returntocorp/semgrep/issues/5399
-    - |
-      semgrep ci --gitlab-sast --metrics off --config $CUSTOM_RULES_URL \
-        --include app --include lib --include workhorse \
-        --exclude '*_test.go' --exclude spec --exclude qa > gl-sast-report.json || true
-  variables:
-    CUSTOM_RULES_URL: https://gitlab.com/gitlab-com/gl-security/appsec/sast-custom-rules/-/raw/main/appsec-pings/rules.yml
-  artifacts:
-    paths:
-      - gl-sast-report.json
-
-ping-appsec-for-sast-findings:
-  stage: lint
-  image: alpine:latest
-  extends:
-    - .ping-appsec-for-sast-findings:rules
-  variables:
-    # Project Access Token bot ID for /gitlab-com/gl-security/appsec/sast-custom-rules
-    BOT_USER_ID: 13559989
-  needs:
-    - semgrep-appsec-custom-rules
-  script:
-    - apk add jq curl
-    - scripts/process_custom_semgrep_results.sh

.gitlab/ci/test-metadata.gitlab-ci.yml

@@ -1,51 +1,67 @@
 .tests-metadata-state:
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}
+  extends:
+    - .default-only
+    - .only:changes-code-backstage
+  variables:
+    TESTS_METADATA_S3_BUCKET: "gitlab-ce-cache"
   before_script:
     - source scripts/utils.sh
+  cache:
+    key: tests_metadata
+    paths:
+      - knapsack/
+      - rspec_flaky/
   artifacts:
     expire_in: 31d
     paths:
       - knapsack/
-      - rspec/
-      - crystalball/
-    when: always
+      - rspec_flaky/
+      - rspec_profiling/
 
 retrieve-tests-metadata:
-  extends:
-    - .tests-metadata-state
-    - .test-metadata:rules:retrieve-tests-metadata
-  # We use a smaller image for this job only (update-tests-metadata compiles some gems)
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}ruby:${RUBY_VERSION}-slim
+  extends: .tests-metadata-state
   stage: prepare
+  cache:
+    policy: pull
   script:
-    - apt-get update && apt-get install -y curl  # Not present in ruby-slim, so we add it manually
-    - install_gitlab_gem
-    - source ./scripts/rspec_helpers.sh
+    - source scripts/rspec_helpers.sh
     - retrieve_tests_metadata
 
 update-tests-metadata:
-  extends:
-    - .tests-metadata-state
-    - .test-metadata:rules:update-tests-metadata
+  extends: .tests-metadata-state
   stage: post-test
-  dependencies:
-    - retrieve-tests-metadata
-    - generate-frontend-fixtures-mapping
-    - setup-test-env
-    - rspec migration pg13
-    - rspec-all frontend_fixture
-    - rspec unit pg13
-    - rspec integration pg13
-    - rspec system pg13
-    - rspec background_migration pg13
-    - rspec-ee migration pg13
-    - rspec-ee unit pg13
-    - rspec-ee integration pg13
-    - rspec-ee system pg13
-    - rspec-ee background_migration pg13
+  cache:
+    policy: push
   script:
-    - run_timed_command "retry gem install fog-aws mime-types activesupport rspec_profiling postgres-copy --no-document"
-    - source ./scripts/rspec_helpers.sh
-    - test -f "${FLAKY_RSPEC_SUITE_REPORT_PATH}" || echo -e "\e[31m" 'Consider add ~"pipeline:run-all-rspec" to run full rspec jobs' "\e[0m"
+    - retry gem install fog-aws mime-types activesupport rspec_profiling postgres-copy --no-document
+    - source scripts/rspec_helpers.sh
     - update_tests_metadata
-    - update_tests_mapping
+  only:
+    refs:
+      - schedules
+    variables:
+      # Only update the Knapsack metadata on GitLab.com/gitlab-org/gitlab
+      - $CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_PATH == "gitlab-org/gitlab"
+
+flaky-examples-check:
+  extends:
+    - .default-tags
+    - .default-retry
+    - .default-only
+    - .only:changes-code-backstage
+  image: ruby:2.6-alpine
+  stage: post-test
+  variables:
+    NEW_FLAKY_SPECS_REPORT: rspec_flaky/report-new.json
+  allow_failure: true
+  only:
+    refs:
+      - merge_requests
+  artifacts:
+    expire_in: 30d
+    paths:
+      - rspec_flaky/
+  script:
+    - '[[ -f $NEW_FLAKY_SPECS_REPORT ]] || echo "{}" > ${NEW_FLAKY_SPECS_REPORT}'
+    - scripts/merge-reports ${NEW_FLAKY_SPECS_REPORT} rspec_flaky/new_*_*.json
+    - scripts/detect-new-flaky-examples $NEW_FLAKY_SPECS_REPORT

.gitlab/ci/test-on-gdk/main.gitlab-ci.yml

@@ -1,129 +0,0 @@
-include:
-  - local: .gitlab/ci/qa-common/main.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/rules.gitlab-ci.yml
-  - local: .gitlab/ci/qa-common/variables.gitlab-ci.yml
-
-.run-tests:
-  stage: test
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-bullseye-ruby-${RUBY_VERSION}:bundler-2.3-chrome-${CHROME_VERSION}-docker-${DOCKER_VERSION}
-  services:
-    - docker:${DOCKER_VERSION}-dind
-  tags:
-    - e2e
-  before_script:
-    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
-    - sysctl -n -w fs.inotify.max_user_watches=524288
-    - echo "SUITE_RAN=true" > suite_status.env
-  variables:
-    DOCKER_DRIVER: overlay2
-    DOCKER_HOST: tcp://docker:2375
-    QA_GDK_IMAGE: "${CI_REGISTRY}/${CI_PROJECT_PATH}/gitlab-qa-gdk:master"
-    QA_GENERATE_ALLURE_REPORT: "true"
-    QA_CAN_TEST_PRAEFECT: "false"
-    QA_INTERCEPT_REQUESTS: "false"
-    TEST_LICENSE_MODE: $QA_TEST_LICENSE_MODE
-    EE_LICENSE: $QA_EE_LICENSE
-    GITHUB_ACCESS_TOKEN: $QA_GITHUB_ACCESS_TOKEN
-    GITLAB_QA_ADMIN_ACCESS_TOKEN: $QA_ADMIN_ACCESS_TOKEN
-    RSPEC_REPORT_OPTS: "--format QA::Support::JsonFormatter --out tmp/rspec-${CI_JOB_ID}.json --format RspecJunitFormatter --out tmp/rspec-${CI_JOB_ID}.xml --format html --out tmp/rspec-${CI_JOB_ID}.htm --color --format documentation"
-  timeout: 2 hours
-  artifacts:
-    when: always
-    paths:
-      - test_output
-      - logs
-    expire_in: 7 days
-    reports:
-      junit: test_output/**/rspec-*.xml
-      dotenv: suite_status.env
-  script:
-    - echo -e "\e[0Ksection_start:`date +%s`:pull_image\r\e[0KPull GDK QA image"
-    - docker pull ${QA_GDK_IMAGE}
-    - echo -e "\e[0Ksection_end:`date +%s`:pull_image\r\e[0K"
-    - echo -e "\e[0Ksection_start:`date +%s`:launch_gdk_and_tests\r\e[0KLaunch GDK and run QA tests"
-    - cd qa && bundle install --jobs=$(nproc) --retry=3 --quiet
-    - mkdir -p $CI_PROJECT_DIR/test_output $CI_PROJECT_DIR/logs/gdk $CI_PROJECT_DIR/logs/gitlab
-    # This command matches the permissions of the user that runs GDK inside the container.
-    - chown -R 1000:1000 $CI_PROJECT_DIR/test_output $CI_PROJECT_DIR/logs $CI_PROJECT_DIR/qa/knapsack
-    - |
-      docker run --rm --name gdk --add-host gdk.test:127.0.0.1 --shm-size=2gb \
-        --env-file <(bundle exec rake ci:env_var_name_list) \
-        --volume /var/run/docker.sock:/var/run/docker.sock:z \
-        --volume $CI_PROJECT_DIR/test_output:/home/gdk/gdk/gitlab/qa/tmp:z \
-        --volume $CI_PROJECT_DIR/logs/gdk:/home/gdk/gdk/log \
-        --volume $CI_PROJECT_DIR/logs/gitlab:/home/gdk/gdk/gitlab/log \
-        --volume $CI_PROJECT_DIR/qa/knapsack:/home/gdk/gdk/gitlab/qa/knapsack \
-        ${QA_GDK_IMAGE} "${CI_COMMIT_SHA}" "$RSPEC_REPORT_OPTS $TEST_GDK_TAGS --tag ~requires_praefect"
-    # The above image's launch script takes two arguments only - first one is the commit sha and the second one Rspec Args
-  allow_failure: true
-  after_script:
-    - |
-      if [ "$CI_JOB_STATUS" == "failed" ]; then
-        echo "SUITE_FAILED=true" >> suite_status.env
-      fi
-
-download-knapsack-report:
-  extends:
-    - .download-knapsack-report
-    - .rules:download-knapsack
-
-test-on-gdk-smoke:
-  extends:
-    - .run-tests
-  parallel: 2
-  variables:
-    TEST_GDK_TAGS: "--tag smoke"
-  rules:
-    - when: always
-
-test-on-gdk-full:
-  extends:
-    - .run-tests
-  parallel: 5
-  rules:
-    - when: manual
-
-# ==========================================
-# Post test stage
-# ==========================================
-e2e-test-report:
-  extends:
-    - .e2e-test-report
-    - .rules:report:allure-report
-  variables:
-    ALLURE_RESULTS_GLOB: test_output/allure-results
-
-upload-knapsack-report:
-  extends:
-    - .upload-knapsack-report
-    - .rules:report:process-results
-  variables:
-    QA_KNAPSACK_REPORT_FILE_PATTERN: $CI_PROJECT_DIR/test_output/knapsack/*/*.json
-
-export-test-metrics:
-  extends:
-    - .export-test-metrics
-    - .rules:report:process-results
-  variables:
-    QA_METRICS_REPORT_FILE_PATTERN: $CI_PROJECT_DIR/test_output/test-metrics-*.json
-
-relate-test-failures:
-  extends:
-    - .relate-test-failures
-    - .rules:report:process-results
-  variables:
-    QA_RSPEC_JSON_FILE_PATTERN: $CI_PROJECT_DIR/test_output/rspec-*.json
-
-generate-test-session:
-  extends:
-    - .generate-test-session
-    - .rules:report:process-results
-  variables:
-    QA_RSPEC_JSON_FILE_PATTERN: $CI_PROJECT_DIR/test_output/rspec-*.json
-
-notify-slack:
-  extends:
-    - .notify-slack
-    - .rules:report:process-results
-  variables:
-    QA_RSPEC_XML_FILE_PATTERN: $CI_PROJECT_DIR/test_output/rspec-*.xml

.gitlab/ci/vendored-gems.gitlab-ci.yml

@@ -1,103 +0,0 @@
-vendor mail-smtp_pool:
-  extends:
-    - .vendor:rules:mail-smtp_pool
-  needs: []
-  trigger:
-    include: vendor/gems/mail-smtp_pool/.gitlab-ci.yml
-    strategy: depend
-
-vendor attr_encrypted:
-  extends:
-    - .vendor:rules:attr_encrypted
-  needs: []
-  trigger:
-    include: vendor/gems/attr_encrypted/.gitlab-ci.yml
-    strategy: depend
-
-vendor microsoft_graph_mailer:
-  extends:
-    - .vendor:rules:microsoft_graph_mailer
-  needs: []
-  trigger:
-    include: vendor/gems/microsoft_graph_mailer/.gitlab-ci.yml
-    strategy: depend
-
-vendor ipynbdiff:
-  extends:
-    - .vendor:rules:ipynbdiff
-  needs: []
-  trigger:
-    include: vendor/gems/ipynbdiff/.gitlab-ci.yml
-    strategy: depend
-
-vendor omniauth-azure-oauth2:
-  extends:
-    - .vendor:rules:omniauth-azure-oauth2
-  needs: []
-  trigger:
-    include: vendor/gems/omniauth-azure-oauth2/.gitlab-ci.yml
-    strategy: depend
-
-vendor omniauth_crowd:
-  extends:
-    - .vendor:rules:omniauth_crowd
-  needs: []
-  trigger:
-    include: vendor/gems/omniauth_crowd/.gitlab-ci.yml
-    strategy: depend
-
-vendor omniauth-gitlab:
-  extends:
-    - .vendor:rules:omniauth-gitlab
-  needs: []
-  trigger:
-    include: vendor/gems/omniauth-gitlab/.gitlab-ci.yml
-    strategy: depend
-
-vendor omniauth-salesforce:
-  extends:
-    - .vendor:rules:omniauth-salesforce
-  needs: []
-  trigger:
-    include: vendor/gems/omniauth-salesforce/.gitlab-ci.yml
-    strategy: depend
-
-vendor devise-pbkdf2-encryptable:
-  extends:
-    - .vendor:rules:devise-pbkdf2-encryptable
-  needs: []
-  trigger:
-    include: vendor/gems/devise-pbkdf2-encryptable/.gitlab-ci.yml
-    strategy: depend
-
-vendor bundler-checksum:
-  extends:
-    - .vendor:rules:bundler-checksum
-  needs: []
-  trigger:
-    include: vendor/gems/bundler-checksum/.gitlab-ci.yml
-    strategy: depend
-
-vendor gitlab_active_record:
-  extends:
-    - .vendor:rules:gitlab_active_record
-  needs: []
-  trigger:
-    include: vendor/gems/gitlab_active_record/.gitlab-ci.yml
-    strategy: depend
-
-vendor cloud_profiler_agent:
-  extends:
-    - .vendor:rules:cloud_profiler_agent
-  needs: []
-  trigger:
-    include: vendor/gems/cloud_profiler_agent/.gitlab-ci.yml
-    strategy: depend
-
-vendor sidekiq-reliable-fetch:
-  extends:
-    - .vendor:rules:sidekiq-reliable-fetch
-  needs: []
-  trigger:
-    include: vendor/gems/sidekiq-reliable-fetch/.gitlab-ci.yml
-    strategy: depend

.gitlab/ci/workhorse.gitlab-ci.yml

@@ -1,49 +0,0 @@
-workhorse:verify:
-  extends: .workhorse:rules:workhorse
-  image: ${GITLAB_DEPENDENCY_PROXY_ADDRESS}golang:${GO_VERSION}
-  stage: test
-  needs: []
-  script:
-    - go version
-    - make -C workhorse  # test build
-    - make -C workhorse verify
-
-.workhorse:test:
-  extends: .workhorse:rules:workhorse
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/debian-${DEBIAN_VERSION}-ruby-${RUBY_VERSION}-golang-${GO_VERSION}-rust-${RUST_VERSION}:rubygems-${RUBYGEMS_VERSION}-git-2.36-exiftool-12.60
-  variables:
-    GITALY_ADDRESS: "tcp://127.0.0.1:8075"
-  stage: test
-  needs:
-    - setup-test-env
-  before_script:
-    - go version
-    - scripts/gitaly-test-build
-  script:
-    - make -C workhorse test
-
-workhorse:test go:
-  extends: .workhorse:test
-  parallel:
-    matrix:
-      - GO_VERSION: ["1.18", "1.19"]
-  script:
-    - make -C workhorse test-coverage
-  coverage: '/\d+.\d+%/'
-  artifacts:
-    paths:
-      - workhorse/coverage.html
-
-workhorse:test fips:
-  extends: .workhorse:test
-  parallel:
-    matrix:
-      - GO_VERSION: ["1.18", "1.19"]
-  image: ${REGISTRY_HOST}/${REGISTRY_GROUP}/gitlab-build-images/ubi-${UBI_VERSION}-ruby-${RUBY_VERSION}-golang-${GO_VERSION}-rust-${RUST_VERSION}:rubygems-${RUBYGEMS_VERSION}-git-2.36-exiftool-12.60
-  variables:
-    FIPS_MODE: 1
-
-workhorse:test race:
-  extends: .workhorse:test
-  script:
-    - make -C workhorse test-race

.gitlab/ci/yaml.gitlab-ci.yml

@@ -1,40 +1,14 @@
-# Yamllint of yaml files.
-
+# Yamllint of *.yml for .gitlab-ci.yml.
 # This uses rules from project root `.yamllint`.
-lint-yaml:
+lint-ci-gitlab:
   extends:
+    - .default-tags
     - .default-retry
-    - .yaml-lint:rules
-  image: pipelinecomponents/yamllint:latest
-  stage: lint
-  needs: []
+    - .default-only
+  only:
+    changes:
+      - "**/*.yml"
+  image: sdesbure/yamllint:latest
+  dependencies: []
   script:
-    - yamllint --strict -f colored .
-
-# The jobs below will not use the configuration present in `.yamllint` (it's because of the -d option)
-#
-# Docs: https://yamllint.readthedocs.io/en/stable/configuration.html#custom-configuration-without-a-config-file
-
-lint-pipeline-yaml:
-  extends:
-    - .default-retry
-    - .lint-pipeline-yaml:rules
-  image: pipelinecomponents/yamllint:latest
-  stage: lint
-  needs: []
-  variables:
-    LINT_PATHS: .gitlab-ci.yml .gitlab/ci lib/gitlab/ci/templates data/deprecations data/removals data/whats_new
-  script:
-    - 'yamllint -d "{extends: default, rules: {line-length: disable, document-start: disable}}" $LINT_PATHS'
-
-lint-metrics-yaml:
-  extends:
-    - .default-retry
-    - .lint-metrics-yaml:rules
-  image: pipelinecomponents/yamllint:latest
-  stage: lint
-  needs: []
-  variables:
-    LINT_PATHS: config/metrics
-  script:
-    - 'yamllint --strict -f colored -d "{extends: default, rules: {line-length: disable, document-start: disable, indentation: {spaces: 2, indent-sequences: whatever}}}" $LINT_PATHS'
+    - yamllint .gitlab-ci.yml .gitlab/ci lib/gitlab/ci/templates changelogs

.gitlab/issue_templates/AI Project Proposal.md

@@ -1,147 +0,0 @@
-<!--
-HOW TO USE THIS TEMPLATE
-To propose an AI experiment, focus on completing the “Experiment” section first. As you refine the idea and gather feedback on your experiment, use the “Feature release” section to define how it will evolve as a Beta or GA capability. It's important that we link experiment to feature release. Feel free to add sections, but keep the existing ones.
-
-You can choose how to get started with this template. For example, the proposal can start as an issue, and then be promoted to an epic to house all the work related to the experiment/prototype and feature release. If you prefer to start with an epic, you have to manually apply the proposal template. Regardless, if the experiment is eventually prioritized for development, the template content will need to appear in a top-level epic so it can be tracked alongside other prioritized AI experiments.
-
-TITLE FORMAT
-🤖 [AI Proposal] {Need/outcome} {Beneficiary} {Job/Small Job}
-
-The title should be something that is easily understood that quickly communicates the intent of the project allowing team members to easily understand and recognize the expected work that will be done. A proposal title should combine the beneficiary of the feature/UI, the job it will allow them to accomplish (see https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd), and their expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the proposal so that anyone can understand it at a glance. (e.g. {Reduce the effort} {for security teams} {when prioritizing business-critical risks in their assets}).
--->
-
-# Experiment
-
-This section should be completed prior to work on the Experiment beginning.
-
-# [Experiment](https://docs.gitlab.com/ee/policy/alpha-beta-support.html#experiment)
-
-##  Problem to be solved
-
-### User problem
-_What user problem will this solve?_
-
-### Solution hypothesis
-_Why do you believe this AI solution is a good way to solve this problem?_
-
-### Assumption
-_What assumptions are you making about this problem and the solution?_
-
-### Personas
-_What [personas](https://about.gitlab.com/handbook/product/personas/#list-of-user-personas) have this problem, who is the intended user?_
-
-## Proposal
-<!-- Explain the proposed changes, including details around usage and business drivers. -->
-
-### Success
-_How will you measure whether this experiment is a success?_
-
-
-# Feature release
-<!-- DO NOT REMOVE THIS SECTION
-Although the initial focus is on the “Experiment” section, do not remove this “Feature release” section. It's important that we link experiment to feature release. Fill this section as you progress.
--->
-### Main Job story
-_What job to be done will this solve?_
-<!-- What is the [Main Job story](https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/#how-to-write-a-jtbd) that this proposal was derived from? (e.g. When I am on triage rotation, I want to address all the business-critical risks in my assets, So I can minimize the likelihood of my organization being compromised by a security breach.) -->
-
-## Proposal updates/additions
-<!-- Explain any changes or updates to the original proposal from the experiment, including details around usage, business drivers, and reasonings that drove the updates/additions. -->
-
-### Problem validation
-_What validation exists that customers have this problem?_
-<!-- Refer to https://about.gitlab.com/handbook/product/ux/ux-research/research-in-the-AI-space/#guideline-1-problem-validation --- to help identify and understand user needs -->
-
-### Business objective
-_What business objective will be achieved with this proposal?_
-<!-- Objectives (from a business point of view) that will be achieved upon completion. (For instance, Increase engagement by making the experience efficient while reducing the chances of users overlooking high-priority items. -->
-
-### Confidence
-_Has this proposal been derived from research?_
-<!-- How well do we understand the user's problem and their need? Refer to https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#confidence to assess confidence -->
-
-| Confidence        | Research                       |
-| ----------------- | ------------------------------ |
-| [High/Medium/Low] | [research/insight issue](Link) |
-
-### Requirements
-_What tasks or actions should the user be capable of performing with this feature?_
-<!-- Requirements can be taken from existing features or design issues used to build this proposal. Any related issues should be linked with this issue in the Feature/solution issues section below. They are more granular validated needs, goals, and additional details that the proposal encompasses. -->
-
-> ⚠️ Related feature and research issues should be linked in the related issues section (Delete this line when this is done)
-
-#### The user needs to be able to:
-- ...
-- ...
-
-## Checklist
-
-### Experiment
-<details> <summary> Issue information </summary>
-
-- [ ] Add information to the issue body about:
-    - [ ] The user problem being solved
-    - [ ] Your assumptions
-    - [ ] Who it's for, list of personas impacted
-    - [ ] Your proposal
-- [ ] Add relevant designs to the Design Management area of the issue if available
-- [ ] Confirm that an unexpected outage of this feature will not negatively impact the application or other features
-- [ ] Add a feature flag so that this feature can be quickly disabled if/when needed
-- [ ] If this experiment introduces a new service or data store, ensure it is not processing or storing [red data](https://about.gitlab.com/handbook/security/data-classification-standard.html#data-classification-levels) without a security and if needed legal review
-  - *NOTE*: We recommend using one of the already adopted models or data stores. If you need to use something else, be aware that using other models or data stores will require additional review during the feature stage for operational fitness and compliance.
-- [ ] Ensure this issue has the ~wg-ai-integration label to ensure visibility to various teams working on this
-
-</details>
-
-### Feature release
-<details> <summary> Issue information </summary>
-
-- [ ] Add information to the issue body about:
-    - [ ] Your proposal
-    - [ ] The Job Statement it's expected to satisfy
-    - [ ] Details about the user problem and provide any research or problem validation
-    - [ ] List the personas impacted by the proposal.
-- [ ] Add all relevant solution validation issues to the Linked items section that shows this proposal will solve the customer problem, or details explaining why it's not possible to provide that validation.
-- [ ] Add relevant designs to the Design Management area of the issue.
-- [ ] You have adhered to our [Definition of Done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#definition-of-done) standards
-- [ ] Ensure this issue has the ~wg-ai-integration label to ensure visibility to various teams working on this
-
-</details>
-
-<details> <summary> Technical needs </summary>
-
-- [ ] Please consider the operational aspects of the feature you are creating. A list of things to think about is in: https://gitlab.com/gitlab-org/gitlab/-/issues/403859. We will be improving this process in the future: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117637#note_1353253349. 
-- [ ] @ mention your [AppSec Stable Counterpart](https://about.gitlab.com/handbook/product/categories/) and read the [AI secure coding guidelines](https://docs.gitlab.com/ee/development/secure_coding_guidelines.html#artificial-intelligence-ai-features)
-
-1. Work estimate and skills needs to build an ML viable feature: To build any ML feature depending on the work, there are many personas that contribute including, Data Scientist, NLP engineer, ML Engineer, MLOps Engineer, ML Infra engineers, and Fullstack engineer to integrate the ML Services with Gitlab. Post-prototype we would assess the skills needed to build a production-grade ML feature for the prototype.
-2. Data Limitation: We would like to upfront validate if we have viable data for the feature including whether we can use the DataOps pipeline of ModelOps or create a custom one. We would want to understand the training data, test data, and feedback data to dial up the accuracy and the limitations of the data.
-3. Model Limitation: We would want to understand if we can use an open-source pre-trained model, tune and customize it or start a model from scratch as well. Further, we would assess based on the ModelOps model evaluation framework which would be the right model to use based on the use case.
-4. Cost, Scalability, Reliability: We would want to estimate the cost of hosting, serving, inference of the model, and the full end-to-end infrastructure including monitoring and observability.
-5. Legal and Ethical Framework: We would want to align with legal and ethical framework like any other ModelOps features to cover across the nine principles of responsible ML and any legal support needed.
-
-</details>
-
-<details> <summary> Dependency needs </summary>
-
-- [ ] Please consider the operational aspects of the service you are creating. A list of things to think about is in: https://gitlab.com/gitlab-org/gitlab/-/issues/403859. We will be improving this process in the future: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117637#note_1353253349. 
-
-</details>
-
-<details> <summary> Legal needs </summary>
-
-- [ ]  TBD
-
-</details>
-
-## Additional resources
-- If you'd like help with technical validation, or would like to discuss UX considerations for AI mention the AI Assisted group using `@gitlab-org/modelops/applied-ml`.
-- Read about our [AI Integration strategy](https://internal-handbook.gitlab.io/handbook/product/ai-strategy/ai-integration-effort/)
-- Slack channels
-    - `#wg_ai_integration` - Slack channel for the working group and the high level alignment on getting AI ready for Production (Development, Product, UX, Legal, etc.) But from the other channels fell free to reach out and post progress here
-    - `#ai_integration_dev_lobby` - Channel for all implementation related topics and discussions of actual AI features (e.g. explain the code)
-    - `#ai_enablement_team` - Channel for the AI Enablement Team which is building the base for all features (experimentation API, Abstraction Layer, Embeddings, etc.)
-
-
-/label ~wg-ai-integration
-/cc @tmccaslin @hbenson @wayne @pedroms @jmandell
-/confidential

.gitlab/issue_templates/Acceptance Testing.md

@@ -1,100 +0,0 @@
-## Details
-- **Feature Toggle Name**: `FEATURE_NAME`
-- **Required GitLab Version**: `vX.X`
-
---------------------------------------------------------------------------------
-
-## 1. Preparation
-
-- [ ] **Controllers and workers**:
-  1. Please link to dashboards of the workers, and the controllers and actions that can be impacted
-  2. ...
-  3. ...
-
-## 2. Development Trial
-
-#### Check Dev Server Versions
-- [ ] GitLab: https://dev.gitlab.org/help
-
-#### Enable on `dev.gitlab.org`:
-- [ ] `/chatops feature set FEATURE_NAME true --dev` in [`#dev-gitlab`](https://gitlab.slack.com/messages/C6WQ87MU3)
-
-Then leave running while monitoring and performing some testing through web, api or SSH.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Dev Sentry](https://sentry.gitlab.net/gitlab/devgitlaborg/?query=is%3Aunresolved)
-
-## 3. Staging Trial
-
-#### Check Staging Server Versions
-- [ ] GitLab: https://staging.gitlab.com/help
-
-#### Enable on `staging.gitlab.com`
-- [ ] `/chatops run feature set FEATURE_NAME true --staging` in [`#development`](https://gitlab.slack.com/messages/C02PF508L/)
-
-Then leave running while monitoring for at least **15 minutes** while performing some testing through web, api or SSH.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
-
-## 4. Production Server Version Check
-
-- [ ] GitLab: https://gitlab.com/help
-
-## 5. Initial Impact Check
-
-- [ ] Enable for a subset of users, when using percentage gates: 1%.
-
-Then leave running while monitoring for at least **15 minutes** while performing some testing through web, api or SSH.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
-
-## 6. Low Impact Check
-
-- [ ] Enable for a bigger subset of users, when using percentage gates: 10%.
-
-Then leave running while monitoring for at least **30 minutes** while performing some testing through web, api or SSH.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
-
-## 7. Mid Impact Trial
-
-- [ ] Enable for a big subset of users, when using percentage gates: 50%.
-
-Then leave running while monitoring for at least **12 hours** while performing some testing through web, api or SSH.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
-
-## 8. Full Impact Trial
-
-- [ ] Enable for all users: `/chatops run feature set FEATURE_NAME true
-
-Then leave running while monitoring for at least **1 week**.
-
-#### Monitor
-
-- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
-- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
-- [ ] [Check for errors in GitLab Dev Sentry](https://sentry.gitlab.net/gitlab/devgitlaborg/?query=is%3Aunresolved)
-
-#### Success?
-
-- [ ] Remove the feature gate from the code, and close this issue with that MR.

.gitlab/issue_templates/Acceptance_Testing.md

@@ -0,0 +1,100 @@
+## Details
+- **Feature Toggle Name**: `FEATURE_NAME`
+- **Required GitLab Version**: `vX.X`
+
+--------------------------------------------------------------------------------
+
+## 1. Preparation
+
+- [ ] **Controllers and workers**:
+  1. Please link to dashboards of the workers, and the controllers and actions that can be impacted
+  2. ...
+  3. ...
+
+## 2. Development Trial
+
+#### Check Dev Server Versions
+- [ ] GitLab: https://dev.gitlab.org/help
+
+#### Enable on `dev.gitlab.org`:
+- [ ] `/chatops feature set FEATURE_NAME true --dev` in [`#dev-gitlab`](https://gitlab.slack.com/messages/C6WQ87MU3)
+
+Then leave running while monitoring and performing some testing through web, api or SSH.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Dev Sentry](https://sentry.gitlab.net/gitlab/devgitlaborg/?query=is%3Aunresolved)
+
+## 2. Staging Trial
+
+#### Check Staging Server Versions
+- [ ] GitLab: https://staging.gitlab.com/help
+
+#### Enable on `staging.gitlab.com`
+- [ ] `/chatops run feature set FEATURE_NAME true --staging` in [`#development`](https://gitlab.slack.com/messages/C02PF508L/)
+
+Then leave running while monitoring for at least **15 minutes** while performing some testing through web, api or SSH.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
+
+## 4. Production Server Version Check
+
+- [ ] GitLab: https://gitlab.com/help
+
+## 5. Initial Impact Check
+
+- [ ] Enable for a subset of users, when using percentage gates: 1%.
+
+Then leave running while monitoring for at least **15 minutes** while performing some testing through web, api or SSH.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
+
+## 6. Low Impact Check
+
+- [ ] Enable for a bigger subset of users, when using percentage gates: 10%.
+
+Then leave running while monitoring for at least **30 minutes** while performing some testing through web, api or SSH.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
+
+## 7. Mid Impact Trial
+
+- [ ] Enable for a big subset of users, when using percentage gates: 50%.
+
+Then leave running while monitoring for at least **12 hours** while performing some testing through web, api or SSH.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Sentry](https://sentry.gitlab.net/gitlab/gitlabcom/?query=is%3Aunresolved)
+
+## 8. Full Impact Trial
+
+- [ ] Enable for all users: `/chatops run feature set FEATURE_NAME true
+
+Then leave running while monitoring for at least **1 week**.
+
+#### Monitor
+
+- [ ] [Monitor Using Grafana](https://dashboards.gitlab.net)
+- [ ] [Inspect logs in ELK](https://log.gitlab.net/app/kibana)
+- [ ] [Check for errors in GitLab Dev Sentry](https://sentry.gitlab.net/gitlab/devgitlaborg/?query=is%3Aunresolved)
+
+#### Success?
+
+- [ ] Remove the feature gate from the code, and close this issue with that MR.

.gitlab/issue_templates/Actionable Insight - Exploration needed.md

@@ -1,32 +0,0 @@
-<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/product/ux/ux-research-training/research-insights/#actionable-insights 
-
-This issue template is for an actionable insight that requires further exploration.-->
-
-### Insight
-<!-- Describe the insight itself: often the problem, finding, or observation.-->
-
-### Supporting evidence
-<!-- Describe why the problem is happening, or more details behind the finding or observation. Try to include quotes or specific data collected. Feel free to link the Actionable insight from Dovetail here if applicable instead of retyping details. -->
-
-### Action
-<!--Since this is an actionable insight that requires further exploration, ensure the action is algned to that. Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: conduct, explore, redesign, etc. -->
-
-### Resources
- <!--Add resources as links below or as related issues. -->
-
-- :dove: [Dovetail project](Paste URL for Dovetail project here)
-- :mag: [Research issue](Paste URL for research issue here)
-- :footprints: [Follow-up issue or epic](Paste URL for follow-up issue or epic here)
-
-### Tasks
- <!--Fill out these tasks in order to consider an Actionable Insight complete. Actionable Insights are created as confidential by default, but can be made non-confidential if the insight does not include information about competitors from a Competitor Evaluation or any other confidential information. -->
-- [ ] Assign this issue to the appropriate Product Manager, Product Designer, or UX Researcher.
-- [ ] Add the appropriate `Group` (such as `~"group::source code"`) label to the issue.  This helps identify and track actionable insights at the group level.
-- [ ] Link this issue back to the original research issue in the GitLab UX Research project and the Dovetail project.
-- [ ] Adjust confidentiality of this issue if applicable
-
-
-
-/confidential
-/label ~"Actionable Insight::Exploration needed"
-

.gitlab/issue_templates/Actionable Insight - Product change.md

@@ -1,33 +0,0 @@
-<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/product/ux/ux-research-training/research-insights/#actionable-insights 
-
-This issue template is for an actionable insight that requires a change in the product.-->
-
-### Insight
-<!-- Describe the insight itself: often the problem, finding, or observation.-->
-
-### Supporting evidence
-<!-- Describe why the problem is happening, or more details behind the finding or observation. Try to include quotes or specific data collected. Feel free to link the Actionable insight from Dovetail here if applicable instead of retyping details. -->
-
-### Action
-<!--Since this is an actionable insight that requires a change in the product, ensure the action is algned to that. Describe the next step or action that needs to take place as a result of the research. The action should be clearly defined, achievable, and directly tied back to the insight. Make sure to use directive terminology, such as: change, update, add/remove, etc. -->
-
-### Resources
- <!--Add resources as links below or as related issues. -->
-
-- :dove: [Dovetail project](Paste URL for Dovetail project here)
-- :mag: [Research issue](Paste URL for research issue here)
-- :footprints: [Follow-up issue or epic](Paste URL for follow-up issue or epic here)
-
-### Tasks
- <!--Fill out these tasks in order to consider an Actionable Insight complete. Actionable Insights are created as confidential by default, but can be made non-confidential if the insight does not include information about competitors from a Competitor Evaluation or any other confidential information. -->
-- [ ] Assign this issue to the appropriate Product Manager, Product Designer, or UX Researcher.
-- [ ] Add the appropriate `Group` (such as `~"group::source code"`) label to the issue.  This helps identify and track actionable insights at the group level.
-- [ ] Link this issue back to the original research issue in the GitLab UX Research project and the Dovetail project.
-- [ ] Adjust confidentiality of this issue if applicable
-
-
-
-/confidential
-/label ~"Actionable Insight::Product change"
-/label ~"SUS"
-

.gitlab/issue_templates/Audit Event Proposal.md

@@ -1,19 +0,0 @@
-<!-- Audit Event documentation: See https://docs.gitlab.com/ee/administration/audit_events.html -->
-<!-- Streaming Audit Event documentation: See https://docs.gitlab.com/ee/administration/audit_event_streaming.html -->
-
-## Audit need
-
-<!-- Describe the real-world use case for the audit event you want to introduce, and explain the closest thing that GitLab already captures. -->
-
-## Proposal
-
-<!-- Describe the audit event you are proposing should be added, including any details of what should be captured, how, and why. -->
-
-### Streaming-only event or normal event?
-
-<!-- Should this event be a streaming-only audit event or also logged to GitLab's database? Consider the
-volume of data that will be generated by the event when answering this. -->
-
-/label ~"Category:Audit Events"
-/label ~"type::feature"
-/label ~"group::compliance"

.gitlab/issue_templates/Broken Master - Flaky.md

@@ -1,30 +0,0 @@
-<!---
-This issue template is for a master pipeline is failing for a flaky reason that cannot be reliably reproduced.
-
-Please read the below documentations for a workflow of triaging and resolving broken master.
-
-- https://about.gitlab.com/handbook/engineering/workflow/#triage-broken-master
-- https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/master-broken.md
-- https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/testing_guide/flaky_tests.md
---->
-
-### Summary
-
-<!-- Link to the failing master build and add the build failure output in the below code block section. -->
-
-### Steps to reproduce
-
-<!-- If the pipeline failure is reproducible, provide steps to recreate the issue locally. Please use an ordered list. -->
-
-Please refer to [Flaky tests documentation](https://docs.gitlab.com/ee/development/testing_guide/flaky_tests.html) to
-learn more about how to reproduce them.
-
-### Proposed Resolution
-
-<!-- Describe the proposed change to restore master stability. -->
-
-Please refer to the [Resolution guidance](https://about.gitlab.com/handbook/engineering/workflow/#resolution-of-broken-master) to learn more about resolution of broken master.
-
-Once the flaky failure has been fixed on the default branch, open merge requests to cherry-pick the fix to the active stable branches.
-
-/label ~"type::maintenance" ~"failure::flaky-test" ~"priority::3" ~"severity::3"

.gitlab/issue_templates/Broken Master - Non-flaky.md

@@ -1,24 +0,0 @@
-<!---
-This issue template is for a master pipeline is failing for a non-flaky reason.
-
-Please read the below documentations for a workflow of triaging and resolving broken master.
-
-- https://about.gitlab.com/handbook/engineering/workflow/#triage-broken-master
-- https://gitlab.com/gitlab-org/quality/engineering-productivity/team/-/blob/main/runbooks/master-broken.md
---->
-
-### Summary
-
-<!-- Link to the failing master build and add the build failure output in the below code block section. -->
-
-### Steps to reproduce
-
-<!-- If the pipeline failure is reproducible, provide steps to recreate the issue locally. Please use an ordered list. -->
-
-### Proposed Resolution
-
-<!-- Describe the proposed change to restore master stability. -->
-
-Please refer to the [Resolution guidance](https://about.gitlab.com/handbook/engineering/workflow/#resolution-of-broken-master) to learn more about resolution of broken master.
-
-/label ~"master:broken" ~"Engineering Productivity" ~"priority::1" ~"severity::1" ~"type::maintenance" ~"maintenance::pipelines"

.gitlab/issue_templates/Bug.md

@@ -2,55 +2,49 @@
 Please read this!
 
 Before opening a new issue, make sure to search for keywords in the issues
-filtered by the "regression" or "type::bug" label:
+filtered by the "regression" or "bug" label:
 
 - https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=regression
-- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=type::bug
+- https://gitlab.com/gitlab-org/gitlab/issues?label_name%5B%5D=bug
 
 and verify the issue you're about to submit isn't a duplicate.
 --->
 
 ### Summary
 
-<!-- Summarize the bug encountered concisely. -->
+(Summarize the bug encountered concisely)
 
 ### Steps to reproduce
 
-<!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. -->
+(How one can reproduce the issue - this is very important)
 
 ### Example Project
 
-<!-- If possible, please create an example project here on GitLab.com that exhibits the problematic 
-behavior, and link to it here in the bug report. If you are using an older version of GitLab, this 
-will also determine whether the bug is fixed in a more recent version. -->
+(If possible, please create an example project here on GitLab.com that exhibits the problematic behavior, and link to it here in the bug report)
+
+(If you are using an older version of GitLab, this will also determine whether the bug is fixed in a more recent version)
 
 ### What is the current *bug* behavior?
 
-<!-- Describe what actually happens. -->
+(What actually happens)
 
 ### What is the expected *correct* behavior?
 
-<!-- Describe what you should see instead. -->
+(What you should see instead)
 
 ### Relevant logs and/or screenshots
 
-<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
- as it's tough to read otherwise. -->
+(Paste any relevant logs - please use code blocks (```) to format console output,
+logs, and code as it's tough to read otherwise.)
 
 ### Output of checks
 
-<!-- If you are reporting a bug on GitLab.com, uncomment below -->
-
-<!-- This bug happens on GitLab.com -->
-<!-- /label ~"reproduced on GitLab.com" -->
+(If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com)
 
 #### Results of GitLab environment info
 
-<!--  Input any relevant GitLab environment information if needed. -->
-
 <details>
 <summary>Expand for output related to GitLab environment info</summary>
-
 <pre>
 
 (For installations with omnibus-gitlab package run and paste the output of:
@@ -64,8 +58,6 @@ will also determine whether the bug is fixed in a more recent version. -->
 
 #### Results of GitLab application Check
 
-<!--  Input any relevant GitLab application check information if needed. -->
-
 <details>
 <summary>Expand for output related to the GitLab application check</summary>
 <pre>
@@ -83,6 +75,6 @@ will also determine whether the bug is fixed in a more recent version. -->
 
 ### Possible fixes
 
-<!-- If you can, link to the line of code that might be responsible for the problem. -->
+(If you can, link to the line of code that might be responsible for the problem)
 
-/label ~"type::bug"
+/label ~bug

.gitlab/issue_templates/Coding style proposal.md

@@ -0,0 +1,16 @@
+## Description of the proposal
+
+<!--
+Please describe the proposal and add a link to the source (for example, http://www.betterspecs.org/).
+-->
+
+- [ ] Mention the proposal in the next backend weekly call and the #backend channel to encourage contribution
+- [ ] Proceed with the proposal once 50% of the maintainers have weighed in, and 80% of the votes are :+1:
+- [ ] Once approved, mention it again in the next backend weekly call and the #backend channel
+
+
+/label ~"development guidelines"
+/label ~"Style decision"
+/label ~documentation
+
+/cc @gitlab-org/maintainers/rails-backend

.gitlab/issue_templates/Default.md

@@ -1,13 +0,0 @@
-Before raising an issue to the GitLab issue tracker, please read through our guide for finding help to determine the best place to post:
-
-* https://about.gitlab.com/getting-help/
-
-If you are experiencing an issue when using GitLab.com, your first port of call should be the Community Forum. Your issue may have already been reported there by another user. Please check:
-
-* https://forum.gitlab.com/
-
-If you feel that your issue can be categorized as a reproducible bug or a feature proposal, please use one of the issue templates provided and include as much information as possible.
-
-Thank you for helping to make GitLab a better product.
-
-<!-- template sourced from https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Default.md -->

.gitlab/issue_templates/Deprecations.md

@@ -1,101 +0,0 @@
-For guidance on the overall deprecations, removals and breaking changes workflow, please visit [Breaking changes, deprecations, and removing features](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes)
-
-<!-- Use this template as a starting point for deprecations. -->
-
-### Deprecation Summary
-
-<!--
-This should contain a brief description of the feature or functionality that is deprecated. The description should clearly state the potential impact of the deprecation to end users.
-
-It is recommended that you link to the documentation.
-
-The description of the deprecation should state what actions the user should take to rectify the behavior. If the deprecation is scheduled for an upcoming release, the content should remain in the deprecations documentation page until it has been completed. For example, if a deprecation is announced in 14.9 and scheduled to be completed in 15.0, the same content would be included in the documentation for 14.9, 14.10, and 15.0.
-
-**If this issue proposes a breaking change outside a major release XX.0, you need to get approval from your manager and request collaboration from Product Operations on communication. Be sure to follow the guidance [here](https://about.gitlab.com/handbook/product/gitlab-the-product/#deprecations-removals-and-breaking-changes.)** 
-
--->
-
-### Breaking Change
-
-<!-- Does this MR contain a breaking change? If yes:
-- Add the ~"breaking change" label to this issue.
-- Add instructions for how users can update their workflow. -->
-
-### Affected Topology
-
-<!--
-Who is affected by this deprecation, Self-managed users, SaaS users, or both? This is especially important when nearing the annual major release where breaking changes and removals are typically introduced. These changes might be seen on GitLab.com before the official release date.
--->
-
-### Affected Tier
-
-<!--
-Which tier is this feature available in?
-
-* Free
-* Premium
-* Ultimate
--->
-
-### Checklists
-
-**Labels**
-
-- [ ] This issue is labeled ~deprecation, and with the relevant `~devops::`, `~group::`, and `~Category:` labels.
-- [ ] This issue is labeled  ~"breaking change" if the removal of the deprecated item will be a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes).
-
-**Timeline**
-
-Please add links to the relevant merge requests.
-
-- As soon as possible, but no later than the third milestone preceding the major release (for example, given the following release schedule: `14.8, 14.9, 14.10, 15.0` – `14.8` is the third milestone preceding the major release):
-    - [ ] A [deprecation announcement entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement) has been created so the deprecation will appear in release posts and on the [general deprecation page](https://docs.gitlab.com/ee/update/deprecations).
-    - [ ] Documentation has been updated to mark the feature as [deprecated](https://docs.gitlab.com/ee/development/documentation/versions.html#deprecations-and-removals).
-- [ ] On or before the major milestone: A [removal entry](https://about.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement-1) has been created so the removal will appear on the [removals by milestones](https://docs.gitlab.com/ee/update/removals) page and be announced in the release post.
-- On the major milestone:
-    - [ ] The deprecated item has been removed.
-    - [ ] If the removal of the deprecated item is a [breaking change](https://about.gitlab.com/handbook/product/gitlab-the-product/#examples-of-breaking-changes), the merge request is labeled ~"breaking change".
-
-**Mentions**
-
-- [ ] Your stage's stable counterparts have been `@mentioned`  on this issue. For example, Customer Support, Customer Success (Technical Account Manager), Product Marketing Manager.
-  - To see who the stable counterparts are for a product team visit [product categories](https://about.gitlab.com/handbook/product/categories/)
-       - If there is no stable counterpart listed for Sales/CS please mention `@timtams`
-       - If there is no stable counterpart listed for Support please mention `@gitlab-com/support/managers`
-       - If there is no stable counterpart listed for Marketing please mention `@cfoster3`
-- [ ] Your GPM has been `@mentioned` so that they are aware of planned deprecations. The goal is to have reviews happen at least two releases before the final removal of the feature or introduction of a breaking change.
-
-### Deprecation Milestone
-
-<!-- In which milestone will this deprecation be announced ? -->
-
-### Planned Removal Milestone
-
-<!-- In which milestone will the feature or functionality be removed and announced? -->
-
-### Links
-
-<!--
-Add links to any relevant documentation or code that will provide additional details or clarity regarding the planned change.
-
-This issue is the main SSOT for the deprecations and removals process. Be sure to link all
-issues and MRs related to this deprecation/removal to this issue. This can include removal
-issues that were created ahead of time, and the MRs doing the actual deprecation/removal work.
--->
-
-<!-- Label reminders - you should have one of each of the following labels.
-Use the following resources to find the appropriate labels:
-- https://gitlab.com/gitlab-org/gitlab/-/labels
-- https://about.gitlab.com/handbook/product/categories/features/
--->
-
-<!-- Populate the Section, Group, and Category -->
-/label ~devops:: ~group: ~Category:
-
-<!-- Choose the Pricing Tier(s) -->
-/label  ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
-
-<!-- Identifies that this Issue is related to deprecating a feature -->
-/label ~"deprecation"
-
-<!-- Add the ~"breaking change" label to this issue if necessary -->

.gitlab/issue_templates/Design Sprint.md

@@ -1,210 +0,0 @@
-<!-- Title: Design Sprint -->
-
-This template outlines a sample set-up process, activities and deliverables for running a Remote Design Sprint. The specific activities and deliverables should be customized based on your objectives and timeline. 
-
-Please refer to the [Remote Design Sprint Handbook page](#anchor-tag-to-handbook-page) for additional recommendations.
-
-## Design Sprint Focus
-* [ ] Have you [determined that a Design Sprint is appropriate for this project](#anchor-tag-to-handbook-page)?
-<!-- What is the focus of the [Design Sprint](https://about.gitlab.com/handbook/product/product-processes/#design-sprint)? What problem area will you be solving for and who is the target user? -->
-
-## Objectives
-
-<!-- Try to describe the objectives of the Sprint in detail. eg "We want to introduce a new feature but we are unsure that we are thinking about the solution from the customer's perspective and through the Sprint we want to rethink the solution, prototype it and validate it with our customers" or "We are unhappy with the direction of one of our categories and we want to explore new directions with different stakeholders, reach to one solution and test it with users" or "Among the team we have different visions for a specific category and we want to work towards a solution we all support and test it with users".  --> 
-
-## Outputs
-
-- [ ] A User testing flow.
-- [ ] A Prototype to be tested with users.
-- [ ] User testing analysis. 
-- [ ] (If the solution is viable) An epic or issue that describes the direction in details and the next steps
-- [ ] Necessary updates to the Handbook.
-
-## Design Sprint Details
-
-| Start | End |
-| ------ | ------ |
-| YYYY-MM-DD | YYYY-MM-DD |
-| TT:TT PST | TT:TT PST |
-
-
-### WHEN 
-
-**Start date:**
-
-**End date:**
-
-**Reference time zone:**
-
-### WHERE
-
-**Zoom link:**
-
-### WHO
-
-   - `Name` `gitlab handle` - Facilitator 
-   - `Name` `gitlab handle` - Decider (usually the Product Manager)
-   - `Name` `gitlab handle` - Co-decider (optional)
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Sprint team member
-   - `Name` `gitlab handle` - Co-facilitator (optional)
-
-## Tools
-Here is the list of tools for the Sprint preparation, collaboration and documentation. Prior to the Sprint make sure you have access to all of the following:
-
-*  **GitLab**<br/>
-Each Sprint day outcomes and material will be documented in a separate issue under the Design Sprint epic. 
-
-* **Mural** (You can join as anonymous but we need to be able to identify input against names, so please create an account beforehand.<br/>
-We will use Mural for most of the Sprint collaboration. Some of the things we will do in Mural: 
-    * Create artifacts like affinity diagrams from participants' input
-    * Use post-its to comment on each other's points and to add notes
-    * Vote on ideas and solutions
-    * Create the first draft of the prototype.
-The Mural link to the collaboration project will be provided in the issue before the start of the Design Sprint.
-
-* **Video and/or screen recording tool** (Loom, Quicktime, Zoom or another tool you are using).<br/>
-As part of the pre-Sprint homework, you will be asked to record a short Lightning Walkthrough video. You can use any tool you feel comfortable with as long as it can capture your screen, mouse pointer and your audio.
-
-* **A4/Letter sized paper (preferably white blank), Sharpies/Pens** (please don't use a pencil because it doesn't create enough contrast for photos).<br/>
-Day 2 of the sprint involves some (async) ideation via sketching so you will need a writing utensil (Sharpies are preferred because they force you to draw at a lower fidelity because the small details aren't necessary at this point) and some paper. This is the most fun part of the Sprint where you get into a design thinking mindset and can appeal to your creative self. Don't worry, it's not about artistry, it's about ideas and collaboration.
-
-* **Camera (phone or other) or scanner**<br/>
-You will need to upload sketches as images for the facilitator to prepare the material before the next sync meeting. You can take a photo with your phone or use a scanner if available.
-
-* **Post-it notes (Optional)**<br/>
-If you enjoy taking notes using post-it notes make sure you have available some of them as well. The upside is that they will make you feel more like you are in a workshop and will help the ideas flow (I find that typing is distracting while ideating). The downside is that you will have to digitalise the ones you want to share with the team in Mural.
-
-## Artefacts & Pre-Read Material
-
-<!-- If there is material that will be useful for the participants to read before the Design Sprint add here. -->
-
-### Handbook pages
-<!-- Add a link to the category vision from the handbook -->
-
-### Competitor resources
-<!-- Add any solutions by competitors that are relevant to the Design Sprint topic and could be used as source of inspiration. -->
-
-
-### Articles on Design Sprints
-  * [The Design Sprint](https://www.gv.com/sprint/)
-  * [The Ultimate Guide To Remote Design Sprints](https://drive.google.com/file/d/16bwrAqHVf8qxovd87Q7LdzqwAgy7a6Rx/view?usp=sharing)
-
-## Asyncronus tasks
-
-### Design Sprint preparation
-
-<!-- Replace the roles with GitLab handles to assign to specific participants -->
-
-- [ ] Finalise participant list - `decider` and `facilitator`
-- [ ] Create [participation form](https://docs.google.com/forms/d/e/1FAIpQLSc0_BNltvRW8yXXaJd8sIKzgDmrSGqILMfkoCJrAj6sFcsMcg/viewform?usp=sf_link) and send to participants (**deadline**: [date]) - `facilitator` 
-- [ ] Create a dedicated Slack channel and add participants - `facilitator`
-- [ ] Promote this issue to an epic - `facilitator`
-- [ ] Create issues under the epic for the pre-workshop tasks: Expert interviews ([example](https://gitlab.com/groups/gitlab-org/configure/-/epics/3#note_332412524)), Lightning walkthroughs and How might we.. notetaking assignment ([example](https://gitlab.com/gitlab-org/configure/general/-/issues/52)), Voting How might we... notes assignment ([example](https://gitlab.com/gitlab-org/configure/general/-/issues/54)) - `facilitator` 
-- [ ] Create sync meetings in calendar and invite all participants (**deadline**: [date]) - `decider` or `facilitator` 
-- [ ] Block 2 hours for Sprint activities in calendar for the Sprint week - `all participants`
-- [ ] Prepare material and tools (eg. presentation templates, Google folders, Instructions videos etc) and Mural board from the [Mural template ](https://app.mural.co/invitation/mural/gitlab2474/1586990879319?sender=jmandell0210&key=03c25e92-9a43-4a3d-8907-6f0c3b094ab8) - facilitator 
-- [ ] Finalize Agenda - `facilitator` 
-- [ ] Run a test with material and tools - `facilitator` 
-- [ ] Start user recruiting for prototype user testing (EOD 1) - `facilitator` or `decider`
-
-### Pre-Sprint activities (Homework exercises)
-
-Each exercise should be explained and documented in a separate issue. You can use the example issues above as templates.
-
-- [ ] Fill form and submit (**deadline**: [date]) - `all participants except the facilitator`
-- [ ] Expert interview analysis - `facilitator`
-- [ ] Lightning walkthrough videos (**deadline**: [date]) - `all participants except the facilitator`
-- [ ] How might we... notetaking assignment (**deadline**: [date]) - `all participants except the facilitator`
-- [ ] Voting How might we... notes assignment (**deadline**: [date]) - `all participants except the facilitator`
-- [ ] Add all required material to the Mural board (**deadline**: [date]) - `facilitator`
-
-### During Sprint activities
-
-- [ ] Organise user testing sessions - `facilitator` or `decider`
-- [ ] Create the Prototype to be tested and task list (End of Day 3) - `Product designer` or `Front end developer`
-- [ ] Run user testing sessions - `facilitator` or `decider`
-
-### Post-Sprint activities
-
-- [ ] Create a feedback issue for the Design Sprint - `facilitator` or `decider` 
-- [ ] Analyse user testing results - `facilitator` or `decider`
-- [ ] Create report and share with the Design Sprint participants and wider team - `facilitator` or `decider`
-
-## Personas
-
-Deciding which persona we are focusing on will be part of the Day 1 discussions in the workshop. The personas we are going to consider are:
-
-<!-- Choose which personas could be target users so that you choose from this list during the Sprint. Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
-
-* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
-* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
-* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
-* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
-* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
-* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
-* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
-* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
-* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
-* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
-* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
-* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
-* [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
-* [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director)
-* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
-* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
-
--->
-
-## Agenda
-### Day 1
-
- |  Activity  | Duration | Tool  | Description  |
-|---|---|---|---|
-|  Warm-up exercise  |  5 mins | Mural  |  Write 1 post-it answering the questions: <br/>"My name is…"<br/>"My role is…"<br/>“Something about myself you may not know is…”<br/>"My wish for this workshop is…" |
-| Summarise the async activities & complete Map | 20 mins | Mural  |  The Map is intended to show the focus of the Sprint and doesn't need to be complete or detailed. Steps:<br/>  Go through the Map and the top voted How might we’s tree as a warm-up/reminder. <br/> • Make appropriate adjustments and additions to the map based on the reviews from the team. <br/> • Add the most voted HMWs to the most relevant area on the Map. If a HMW can go to more than one place, add it to the most left area. |
-| Long term goals/Deciding the Sprint goal | 15 mins | Mural  | • Long term goal: Everyone spends 5 minutes in silence and writes one (max 2) long term goal post-it note for the Sprint. (5 mins ) <br/> • One by one everyone will read their goal aloud to the team. (5 mins) <br/> Everyone besides the decider will vote on the goal of the Sprint (1 dot). (4 minutes) <br/> The decider then makes the final decision on the long term goal of the Sprint. (1 min) |
- | Sprint questions | 20 mins | Mural | • Referencing the Long Term goal, everyone will write 2-3 post-it note Sprint questions for the biggest challenges they think might stop us from achieving our long term goal (what might hold us back or hinder us from achieving this goal). The questions should start with “Can we...” (similarly to the HMW). (7 mins) <br/> • One by one everyone will read their Sprint questions aloud to the team. (5 mins) <br/> • Everyone (including the decider) votes on the top 3 questions they think we should focus on as Sprint challenges (3 dots). (5 mins) <br/> • Separate the 3 most voted questions and keep them on the side. (1 min) <br/> • Finally, the decider chooses one Sprint question that will be the question we will focus on more during the Sprint by placing a green smiley sticker on it. (1 min) <br/> • Move the long term goal and the Sprint questions to the dedicated Mural space, highlighting the ultimate Sprint question that the decider chose. (1 min) |
-| Recap day. <br/> Short intro to next day and share the video with the next day exercise instructions. | 5 mins | Mural, Zoom | Summarise activities of the day and decisions. Brief walkthrough of the next day's activities and wrap up the day. |
-
-### Day 2
-  |  Activity  | Duration | Tool  | Description  |
-|---|---|---|---|
-|  Summary of Day 1 outcomes | 5 mins | Mural | Go through the previous day's activities, the Long term goal and the top voted Sprint questions, highlighting the ultimate Sprint question, and summarise the concept solution sketching homework exercise. |
-|  Concept gallery review | 20 mins | Mural | • Everyone takes some time to read through and look at every aspect of each of the sketches in the Concept Gallery. The concept sketches are anonymous to avoid bias (15 mins). <br/> • The team will then vote on their favorite concepts and/or components of a concept via the red dots. When they see something that interests them and they think it will help solve the long term goal/challenges they can add one or more dots. They can use as many red dots as they want. Be frivolous when adding dots but if you really like or think something is important, add more to draw attention to it (5 mins).<br/> Note: If anyone has any questions about a concept sketch create a red sticky and write that question down placing it under the concept sketches. |
-|  Speed critique | 5 mins | Mural | • The facilitator walks through each of the concepts, briefly summarizing each concept (to the best of their ability) with a focus on the areas that have been dotted. <br/> • During this time the facilitator will also try to answer any of the red post-it questions. <br/> • When the facilitator believes they’ve reached the end of their summary for that concept, ask the team if there was a concept that was voted on but not discussed or if the point of the red dot vote was missed in the discussion.
-|  Straw Poll | ~15 mins | Mural | • All the participants, besides the Decider, vote using the larger green dot by adding their initials to it and placing it on the concept sketch they believe is the best one that will best fulfill the long term goal and challenges of this sprint and is worthy of being prototyped (2 mins) <br/> • Each participant will create a post-it note that explains their reasoning for choosing the concept. (5 mins) <br/> • Each participant will then get 1 minute to read through their post-it and attempt to sell their preferred concept to the Decider and the other participants. (5-10 mins) |
-| Super Vote (The Decider) | 10 mins | Mural | • The Decider makes their final decision of which of the concepts is the one to move forward with. <br/> • The decider can discuss their thought process and any questions with the rest of the participants. <br/> • They will get 2 green smiley stickers to vote with. Placing one on the concept they want to move forward with and the second, optional smiley, can be used to mark any other area of any other concept they think should also be incorporated into the prototype. |
-
-
-### Day 3
- |  Activity  | Duration | Tool  | Description  |
-|---|---|---|---|
-| User test flow | 25 mins | Mural | • Each participant writes (on separate post-its) 6 steps/actions that represent a step of a flow (you can think of a high-level prototype flow) from start to finish. Place them in the appropriate location on the User Test section. (10 mins) <br/> • Each participant takes 1 minute to walk the team through their flows one-by-one (5-10 mins total). Note: It's best to have the Decider go last. <br/> • Voting: All the Sprint participants get one red dot (the Decider gets 2) to vote on the flow row they think is the best foundation for the prototype. <br/> • After everyone has voted the Decider will vote on the row they think is best with one dot using the second dot to, optionally, vote on an element of another flow they think should be incorporated into the prototype. (5 mins) <br/> • If the second dot is used copy the specific sticky into the main flow voted by the Decider. | 
-| Storyboard | 45 mins | Mural | • Copy the winning flow from the User Test Flow exercise to the Storyboard/Prototype section placing each individual post-it note into its own container. <br/> • Look at the sketch concepts and move over any relevant screens that fulfill the needs of the sticky note in that container. You can move the entire concept or screen capture cut/paste parts of concepts. Note: Don’t add any unnecessary details or ideas that aren’t needed for the end result prototype <br/> • Fill in the details that are required for each step described in the sticky. |
-| Recap day | 5 mins | Mural, Zoom | Summarise activities of the day and decisions. Brief walkthrough of the next day's activities and wrap up the day. |
-
-### Day 4
- |  Activity  | Duration | Tool  | Description  |
-|---|---|---|---|
-| Validate Prototype | 30 mins | Mural | • Go through the Prototype created by the Product designer or Front end developer and discuss any inaccuracies or missing content. |
-| Wrap up the Sprint | 15 mins | Zoom, GitLab | • Recap the Sprint and discuss next steps. Create user testing issues. |
-
-### Day 5
- |  Activity  | Duration | Tool  | Description  |
-|---|---|---|---|
-| Prototype testing with 5 users | ~45 mins | Figma or code/Zoom | • Test the prototype with users. |
-
-## Ground Rules
-*  Honor the Facilitator's directions. They're the guide for the entire process.
-*  Minimise distractions: During the week you will need to dedicate some hours to the Sprint for async tasks and sync video conferences. During this time we recommend blocking time in your calendar and having devices or apps with notifications turned off during that time. 
-*  All opinions are valid and are equally important, however, the Decider has the ultimate, final decision.
-*  Everyone is an active participant in a sync activity (with the exception of the Observers).
-*  One conversation at a time.
-*  Document as much as you can: We should have concrete outputs to share with broader team. Also interesting ideas or fixes should be documented to be transferred in issues for our backlog.
-*  Stick to scheduled breaks during sync calls. The Facilitator will guide each session and set break times.
-*  The Sprint is one of the few chances we get to work so closely together. Have fun!

.gitlab/issue_templates/Doc_cleanup.md

@@ -1,38 +0,0 @@
-<!--
-* Use this template for documentation issues identified
-* by [Vale](https://docs.gitlab.com/ee/development/documentation/testing.html#vale)
-* or [markdownlint](https://docs.gitlab.com/ee/development/documentation/testing.html#markdownlint).
-* This template is meant to describe work for first-time contributors or
-* for work during Hackathons.
-*
-* Feature development work should not use this template. Use the Feature Request template instead.
--->
-
-## Hi community contributors! :wave:
-
-Do you want to work on this issue?
-
-- **If the issue is unassigned**, in a comment, type `@docs-hackathon I would like to work on this issue` and a writer will assign it to you.
-
-  To be fair to others, do not ask for more than three issues at a time.
-
-- **If the issue is assigned to someone already**, choose another issue. Do not open a merge request for this issue if you are not assigned.
-
-## To resolve the issue
-
-[Follow these instructions to create a merge request](https://docs.gitlab.com/ee/development/documentation/workflow.html#how-to-update-the-docs).
-
-- Don't submit your merge request until after the Hackathon has started.
-- Try to address the issue in a single merge request.
-- Try to stick to the scope of the issue. If you see other improvements that can be made in the file, open a separate merge request.
-- When you create the merge request, select the **Documentation** merge request description template.
-- In the merge request's description, add a link to this issue.
-- Follow the [commit message guidelines](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html#commit-messages-guidelines).
-  Use three to five words for your commit message, start with message with a capital letter, and do **not** end it in a period.
-  Other commit messages can cause the pipeline to fail.
-
-Thank you again for contributing to the GitLab documentation! :tada:
-
-## Documentation issue
-
-/labels ~"documentation" ~"docs-only" ~"documentation" ~"docs::improvement" ~"type::maintenance" ~"maintenance::refactor" ~"Seeking community contributions"  ~"quick win" ~"Technical Writing"

.gitlab/issue_templates/Documentation.md

@@ -24,8 +24,8 @@
 * Any concepts, procedures, reference info we could add to make it easier to successfully use GitLab?
 * Include use cases, benefits, and/or goals for this work.
 * If adding content: What audience is it intended for? (What roles and scenarios?)
-  For ideas, see personas at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ or the persona labels at
-  https://gitlab.com/groups/gitlab-org/-/labels?subscribed=&search=persona%3A
+  For ideas, see personas at https://design.gitlab.com/research/personas or the persona labels at
+  https://gitlab.com/groups/gitlab-org/-/labels?utf8=%E2%9C%93&subscribed=&search=persona%3A
 -->
 
 ### Proposal

.gitlab/issue_templates/Dogfooding.md

@@ -1,17 +0,0 @@
-<!--Lightweight issue template to encourage Dogfooding and educate team members about the importance of Dogfooding -->
-
-/label ~"dogfooding" ~"group::" ~"section::"  ~"Category:"
-
-## Feature to Dogfood
-<!--Link to Description of feature (Documentation, Epic, Opportunity Canvas, etc.) -->
-
-## Goals
-<!--Level of Dogfooding you are looking for: problem validation, testing, production usage, etc  -->
-
-## Progress Tracker
-<!--List of tasks (e.g. a table with columns, project, status, issue links similar to what is [done here](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/8499))-->
-
-## Why Dogfooding is Important
-- https://about.gitlab.com/handbook/values/#dogfooding
-- https://about.gitlab.com/handbook/product/product-processes/#dogfood-everything
-- https://about.gitlab.com/handbook/engineering/#dogfooding

.gitlab/issue_templates/Empty state.md

@@ -1,80 +0,0 @@
-<!-- Before implementing a new empty state solution, make sure to read the 
-Empty State region docs in Pajamas: https://design.gitlab.com/regions/empty-states -->
-
-## Description
-
-<!-- Describe the solution you're proposing for your empty state region. 
-Include links to user research (if applicable). -->
-
-## Location
-
-<!-- Provide a link and location of the new empty state solution. 
-For example: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues -->
-
-## Use case
-
-<!-- What is the use case for the solution you're proposing? 
-Read the Empty State docs and select the use case below: https://design.gitlab.com/regions/empty-states -->
-
-- [ ] Blank content
-- [ ] Empty search results
-- [ ] Configuration required
-- [ ] Higher tier
-
-## Checklist
-
-<!-- Follow the steps below that correspond with the use case selected above. 
-Follow the steps to complete this issue -->
-
-### Blank content
-
-- [ ] The solution follows the `Blank content` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#blank-content).
-- [ ] Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking. 
-
-### Empty search results
-
-- [ ] The solution follows the `Empty search results` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#empty-search-results).
-- [ ] Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking. 
-
-### Configuration required
-
-- [ ] The solution follows the `Configuration required` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#configuration-required).
-- [ ] Ask a [Growth product manager or Designer](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to review your solution.
-- [ ] Is your solution introducing a new empty states or modifying an existing one?
-   - [ ] Introducing a new empty state: Follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking. 
-   - [ ] Modifying an existing empty state: Follow the [`Experimentation` process](#experimentation) below. _Note_: If the empty state you want to replace hasn't been updated in a long time, doesn't pitch the value of the feature, or does not contain a next step action CTA,  then we recommend you skip the experimentation process to implement and add tracking to your new empty state.
-
-<!-- IF experimentation -->
-#### Experimentation
-
-- [ ] Collaborate with a [Growth product manager](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to help you determine if you can validate your solution through an experiment on SaaS. 
-- [ ] If an experiment is possible, create an issue using the [experiment idea template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Idea) and follow the template intructions. Otherwise, follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
-- [ ] Ask a [Growth product manager or Designer](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to review your experiment set-up. 
-- [ ] Implement and monitor the experiment following the [implementation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/experiment_guide/gitlab_experiment.md#implement-an-experiment).
-- [ ] Review and discuss the findings.
-- [ ] Add the findings to the [Growth experimentation knowledge](https://about.gitlab.com/direction/growth/#growth-experiments-knowledge-base---concluded-experiments).
-
-### Higher tier
-
-- [ ] The solution follows the `Higher tier` specifications [in Pajamas](https://design.gitlab.com/regions/empty-states#higher-tier).
-- [ ] Ask a Product Manager or Designer from the [Conversion group](https://about.gitlab.com/handbook/engineering/development/growth/conversion/#group-members) to review your solution. 
-- [ ] Is your solution introducing a new empty states or modifying an existing one?
-   - [ ] Introducing a new empty state: follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking. 
-   - [ ] Modifying an existing empty state, follow the [`Experimentation` process](#experimentation) below.
-
-<!-- IF experimentation -->
-#### Experimentation
-
-- [ ] Collaborate with a [Growth product manager](https://about.gitlab.com/handbook/engineering/development/growth/#stable-counterparts) to help you determine if you can validate your solution through an experiment on SaaS. 
-- [ ] If an experiment is possible, create an issue using the [experiment idea template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Idea) and follow the template intructions. Otherwise, follow the instructions from the [`After merge` section](#after-merge) below to add Snowplow tracking.
-- [ ] Add a ~"Category:Conversion Experiment" label to the experiment idea issue.
-- [ ] Ask a Product Manager or Designer from the [Conversion group](https://about.gitlab.com/handbook/engineering/development/growth/conversion/#group-members) to review your experiment set-up. 
-- [ ] Implement and monitor the experiment following the [implementation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/experiment_guide/gitlab_experiment.md#implement-an-experiment) .
-- [ ] Review and discuss the findings.
-- [ ] Add the findings to the [Growth experimentation knowledge](https://about.gitlab.com/direction/growth/#growth-experiments-knowledge-base---concluded-experiments).
-
-
-## After merge
-
-- [ ] Use the `Snowplow event tracking` [issue template](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Snowplow%20event%20tracking) and open an issue to add Snowplow event tracking to your new empty state solution. 
-  - [ ] Add your ~devops:: and ~group:: labels to the new issue. 

.gitlab/issue_templates/Experiment Idea.md

@@ -1,48 +0,0 @@
-## Experiment summary
-
-We believe that... {describe your hypothesis in one sentence}
-
-To verify that, we will... {describe your test in one sentence}
-
-And we’ll measure the impact on... {metrics}
-
-## Hypothesis
-<!-- The hypothesis represents the high-level thought process in creating the experiment but does not need to be proven in one experiment. For example, you could have a hypothesis that “users would benefit from more easily being able to start a trial” and your first experiment could fail, that doesn’t void your hypothesis only indicates you may need to think of a new iterative experiment that would still align with your hypothesis. -->
-
-## Business problem
-<!-- Where the hypothesis is focused on the user/customer, the business problem represents why/how an experiment in this area could positively impact the business. For example, trials represent a significant way for GitLab to produce valuable leads for the sales team. -->
-
-## Supporting data
-<!-- Why should we run this experiment? What’s the potential impact? Show supporting data that’s both qualitative and quantitative. Quantitative example, we generate 30,000 sign ups a month and 900 trails within 90 days (3%) with a close rate of 10% and an IACV of $400.  If we’re able to increase our trial volume by 10% percent (990 trials a month) we will generate an additional $3,600 IACV if our close rates remain constant. Qualitative example, in searching Zendesk I was able to find 10 support tickets in the last 30 days that referenced difficulties with starting a trial due to the user not being an admin. (all numbers are hypothetical and only listed for the purpose of having an example) -->
-
-## Expected outcome
-<!-- What is the expected outcome of this experiment, what metric are we trying to move? Are there any metrics we know we do not want to impact? For example, we want to impact IACV by increasing the rate at which users start trials within 30 days but we also want to ensure we don't increase the churn rate for users who've recently purchased. -->
-
-## Experiment design & implementation
-<!-- What is the experiment we’re going to run? How long do you believe it will need to run to reach significance? For example, our experiment would be to allow non-admins to request a trial through their admin, to detect a 10% change from our baseline conversion rate we’ll need a sample size of 57,000 (source Optimizely), with our current sign up rate of 30,000 a month this experiment will need to run for ~2 months. (all numbers are hypothetical and only listed for the purpose of having an example) -->
-
-## ICE score
-
-<!-- See https://about.gitlab.com/handbook/product/growth/#growth-ideation-and-prioritization -->
-
-| Impact | Confidence | Ease | Score |
-| ------ | ------ | ------ | ------ |
-| value 1 |  value 2 |  value 3 | Average(1:3) |
-
-## Known assumptions
-<!-- This is an area to call out known assumptions in the experiment, this is especially helpful for any future colleagues that join the team so they understand other potential influences and how they were accounted for. This section is also helpful in framing possible scenarios and to keep the door open for the next steps. For example, we’re hoping our experiment will increase the number of people that start a trial but we’re assuming the conversion rate to paid and IACV will remain the same. This is a known assumption and depending on the results of the experiment could impact the direction we take on any future iterations. -->
-
-## Results, lessons learned, next steps
-<!-- What were the results of the experiment? Was the experiment a success or a failure? Based on the results should we remove the code or advocate that it become a permanent part of the experience for all users? Are there future experiments the team is going to run based off these results (include a link to new issue)? For example, our trial experiment was successful we increased the trial create rate by 10% but we saw a 1% drop in our close rate which means our net impact on IACV was negative $360 (990 * 0.09 * 400 compared tot he control of 900 * 0.1 * 400). Our next experiment (link) will focus on increasing the value once a user starts a trial. (all numbers are hypothetical and only listed for the purpose of having an example) -->
-
-
-## Checklist
-
-* [ ] Fill in the experiment summary and write more about the details of the experiment in the rest of the issue description. Some of these may be filled in through time (the "Result, learnings, next steps" section for example) but at least the experiment summary should be filled in right from the start.
-* [ ] Add the label of the `group::` that will work on this experiment (if known).
-* [ ] Mention the Product Manager, Engineering Manager, and at least one Product Designer from the group that owns the part of the product that the experiment will affect.
-* [ ] Fill in the values in the [ICE score table](#ice-score) ping other team members for the values you aren’t confident about (i.e. engineering should almost always fill out the ease section). Add the ~"ICE Score Needed" label to indicate that the score is incomplete.
-* [ ] Replace the ~"ICE Score Needed" with an ICE low/medium/high score label once all values in the ICE table have been added.
-* [ ] Mention the [at]gitlab-core-team team and ask for their feedback.
-
-/label ~"workflow::validation backlog" ~"experiment idea"

.gitlab/issue_templates/Experiment Implementation.md

@@ -1,25 +0,0 @@
-<!-- Title suggestion: Experiment Implementation: [description] -->
-
-# Experiment Summary
-<!-- Quick rundown of what is being done -->
-
-# Design
-<!-- This should include the contexts that determine the reproducibility (stickiness) of an experiment. This means that if you want the same behavior for a user, the context would be user, or if you want all users when viewing a specific project, the context would be the project being viewed, etc. -->
-
-# Rollout strategy
-<!-- This is currently called A/B test, which isn't accurate for multi-variants. Let's call this rollout strategy. It should outline the percentages for variants and if there's more than one step to this, each of those steps and the timing for those steps (e.g. 30 days after initial rollout). -->
-
-# Inclusions and exclusions
-<!-- These would be the rules for which given context (and are limited to context or resolvable at experiment time details) is included or excluded from the test. An example of this would be to only run an experiment on groups less than N number of days old. -->
-
-# Segmentation 
-<!-- Rules for always saying context with these criteria always get this variant. For instance, if you want to always give groups less than N number of days old the experiment experience, they are specified here. This is different from the exclusion rules above. -->
-
-# Tracking Details
-
-- [json schema](https://gitlab.com/gitlab-org/iglu/-/blob/master/public/schemas/com.gitlab/gitlab_experiment/jsonschema/0-3-0) used in `gitlab-experiment` tracking.
-- see [event schema](https://docs.gitlab.com/ee/development/snowplow/index.html#event-schema) for a guide.
-
-| sequence | activity | category | action | label | property | value |
-| -------- | -------- | ------ | ----- | ------- | -------- | ----- |
-|  |  |  |  |  |  |  |

.gitlab/issue_templates/Experiment Rollout.md

@@ -1,120 +0,0 @@
-<!-- Title suggestion: [Experiment Rollout] feature-flag-name - description of experiment -->
-
-## Summary
-
-This issue tracks the rollout and status of an experiment through to removal.
-
-1. Feature flag name: `<feature-flag-name>`
-1. Epic or issue link: `<issue or epic link>`
-
-This is an experiment rollout issue
-using the scoped [experiment label](https://about.gitlab.com/handbook/engineering/development/growth/experimentation/#experiment-rollout-issue). 
-As well as defining the experiment rollout and cleanup, this issue incorporates the relevant 
-[`Feature Flag Roll Out`](https://gitlab.com/gitlab-org/gitlab/-/edit/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md) steps. 
-
-## Owners
-
-- Team: `group::TEAM_NAME`
-- Most appropriate slack channel to reach out to: `#g_TEAM_NAME`
-- Best individual to reach out to: NAME
-- Product manager (PM): NAME
-
-### Stakeholders
-
-<!--
-Are there any other stages or teams involved that need to be kept in the loop?
-
-- PM: Name
-- Group: `group::TEAM_NAME`
-- The Support Team
-- The Delivery Team
--->
-
-## Expectations
-
-### What are we expecting to happen?
-
-<!-- Describe the expected outcome when rolling out this experiment. -->
-
-### What might happen if this goes wrong?
-
-<!-- Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
-
-### What can we monitor to detect problems with this?
-
-<!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
-
-## Tracked data
-<!-- brief description or link to issue or Sisense dashboard -->
-
-Note: you can use the [CXL calculator](https://cxl.com/ab-test-calculator/) to determine if your experiment has reached significance. The calculator includes an estimate for how much longer an experiment must run for before reaching significance.
-
-## Rollout plan
-<!-- Add an overview and method for modifying the feature flag -->
-
-- Runtime in days, or until we expect to reach statistical significance: `30`
-- We will roll this out behind a feature flag and expose this to `<rollout-percentage>`% of actors to start then ramp it up from there.
-
-`/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
-
-### Status
-
-
-#### Preferred workflow
-
-The issue should be assigned to the Product manager (PM) or Engineer (Eng) as follows:
-
-1. PM determines and manages the status of the experiment (assign this issue to the PM)
-1. PM asks for initial rollout on production, or changes to the status (assign to an Eng)
-1. Eng changes the status using `chatops` (reassign to the PM)
-1. When concluded, PM updates the 'Roll Out Steps' and adds a milestone (assigns to an Eng)
-
-The current status and history can be viewed using the: 
-
-- [API](https://gitlab.com/api/v4/experiments) (GitLab team members)
-- [Feature flag log](https://gitlab.com/gitlab-com/gl-infra/feature-flag-log/-/issues?scope=all&utf8=%E2%9C%93&state=all) (GitLab team members)
-- [Experiment rollout board](https://gitlab.com/groups/gitlab-org/-/boards/1352542)
-
-In this rollout issue, ensure the scoped `experiment::` label is kept accurate.
-
-### Experiment Results
-<!-- update when experiment in/validated, set the scoped `~experiment::` status accordingly -->
-
-## Roll Out Steps
-
-- [ ] [Confirm that end-to-end tests pass with the feature flag enabled](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/feature_flags.html#confirming-that-end-to-end-tests-pass-with-a-feature-flag-enabled). If there are failing tests, contact the relevant [stable counterpart in the Quality department](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors) to collaborate in updating the tests or confirming that the failing tests are not caused by the changes behind the enabled feature flag.
-- [ ] Enable on staging (`/chatops run feature set <feature-flag-name> true --staging`)
-- [ ] Test on staging
-- [ ] Ensure that documentation has been updated
-- [ ] Enable on GitLab.com for individual groups/projects listed above and verify behaviour  (`/chatops run feature set --project=gitlab-org/gitlab <feature-flag-name> true`)
-- [ ] Coordinate a time to enable the flag with the SRE oncall and release managers
-  - In `#production` mention `@sre-oncall` and `@release-managers`. Once an SRE on call and Release Manager on call confirm, you can proceed with the rollout
-- [ ] Announce on the issue an estimated time this will be enabled on GitLab.com
-- [ ] Enable on GitLab.com by running chatops command in `#production` (`/chatops run feature set <feature-flag-name> true`)
-- [ ] Cross post chatops Slack command to `#support_gitlab-com` ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#where-to-run-commands)) and in your team channel
-- [ ] Announce on the issue that the flag has been enabled
-- [ ] Remove experiment code and feature flag and add changelog entry - a separate [cleanup issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Experiment%20Successful%20Cleanup) might be required
-- [ ] After the flag removal is deployed, [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
-- [ ] Assign to the product manager to update the [knowledge base](https://about.gitlab.com/direction/growth/#growth-insights-knowledge-base) (if applicable)
-
-## Rollback Steps
-
-- [ ] This feature can be disabled by running the following Chatops command:
-
-```
-/chatops run feature set <feature-flag-name> false
-```
-
-## Experiment Successful Cleanup Concerns
-
-_Items to be considered if candidate experience is to become a permanent part of GitLab_
-
-<!-- 
-Add a list of items raised during MR review or otherwise that may need further thought/consideration
-before becoming permanent parts of the product.
-
-Example: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/70451#note_727246104
--->
-
-/label ~"feature flag" ~"devops::growth" ~"growth experiment" ~"experiment-rollout" ~Engineering ~"workflow::scheduling" ~"experiment::pending"
-/milestone %"Next 1-3 releases" 

.gitlab/issue_templates/Experiment Successful Cleanup.md

@@ -1,25 +0,0 @@
-<!-- Title suggestion: [Experiment Name] Successful Cleanup -->
-
-## Summary
-
-The experiment is currently rolled out to 100% of users and has been deemed a success.
-The changes need to become an official part of the product.
-
-## Steps
-
-- [ ] Determine whether the feature should apply to SaaS and/or self-managed
-- [ ] Determine whether the feature should apply to EE - and which tiers - and/or Core
-- [ ] Determine if tracking should be kept as is, removed, or modified.
-- [ ] Determine if any UX experiences need to be "polished" i.e. updated to further improve the end user experience. This task should be completed by the designated UX counterpart. 
-   - [ ] (placeholder for UX polish work that needs to be completed for this cleanup issue to be considered completed) 
-- [ ] Ensure any relevant documentation has been updated.
-- [ ] Determine whether there are other concerns that need to be considered before removing the feature flag.
-   - These are typically captured in the `Experiment Successful Cleanup Concerns` section of the rollout issue.
-- [ ] Consider changes to any `feature_category:` introduced by the experiment if ownership is changing (PM for Growth and PM for the new category as DRIs)
-- [ ] Check to see if the experiment introduced new design assets. Add them to the appropriate repos and document them if needed.
-- [ ] Optional: Migrate experiment to a default enabled [feature flag](https://docs.gitlab.com/ee/development/feature_flags) for one milestone and add a changelog. Converting to a feature flag can be skipped at the ICs discretion if risk is deemed low with consideration to both SaaS and (if applicable) self managed
-- [ ] In the next milestone, [remove the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) if applicable
-- [ ] After the flag removal is deployed, [clean up the feature/experiment feature flags](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
-- [ ] Ensure the corresponding [Experiment Rollout](https://gitlab.com/groups/gitlab-org/-/boards/1352542?label_name[]=devops%3A%3Agrowth&label_name[]=growth%20experiment&label_name[]=experiment-rollout) issue is updated
-
-/label ~"type::maintenance" ~"workflow::scheduling" ~"growth experiment" ~"feature flag"

.gitlab/issue_templates/Feature Flag Cleanup.md

@@ -1,51 +0,0 @@
-<!-- Title suggestion: [Feature flag] Cleanup <feature-flag-name> -->
-
-## Summary
-
-This issue is to cleanup the `<feature-flag-name>` feature flag, after the feature flag has been enabled by default for an appropriate amount of time in production.
-
-<!-- Short description of what the feature is about and link to relevant other issues. -->
-
-## Owners
-
-- Team: NAME_OF_TEAM
-- Most appropriate slack channel to reach out to: `#g_TEAM_NAME`
-- Best individual to reach out to: NAME
-- PM: NAME
-
-## Stakeholders
-
-<!--
-Are there any other stages or teams involved that need to be kept in the loop?
-
-- Name of a PM
-- The Support Team
-- The Delivery Team
--->
-
-## Expectations
-
-### What might happen if this goes wrong?
-
-<!-- Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
-
-### Cleaning up the feature flag
-
-<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
-- [ ] Create a merge request to remove `<feature-flag-name>` feature flag. Ask for review and merge it.
-    - [ ] Remove all references to the feature flag from the codebase.
-    - [ ] Remove the YAML definitions for the feature from the repository.
-    - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
-- [ ] Ensure that the cleanup MR has been deployed to both production and canary.
-      If the merge request was deployed before [the code cutoff](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
-      the feature can be officially announced in a release blog post.
-    - [ ] `/chatops run auto_deploy status <merge-commit-of-cleanup-mr>`
-- [ ] Close [the feature issue](ISSUE LINK) to indicate the feature will be released in the current milestone.
-- [ ] If not already done, clean up the feature flag from all environments by running these chatops command in `#production` channel:
-    - [ ] `/chatops run feature delete <feature-flag-name> --dev`
-    - [ ] `/chatops run feature delete <feature-flag-name> --staging`
-    - [ ] `/chatops run feature delete <feature-flag-name>`
-- [ ] Close this rollout issue.
-
-
-/label ~"feature flag" ~"type::maintenance" ~"maintenance::removal"

.gitlab/issue_templates/Feature Flag Roll Out.md

@@ -1,200 +1,45 @@
 <!-- Title suggestion: [Feature flag] Enable description of feature -->
 
-<!--
-Set the main issue link: The main issue is the one that describes the problem to solve,
-the one this feature flag is being added for. For example:
+## What
 
-[main-issue]: https://gitlab.com/gitlab-org/gitlab/-/issues/123456
--->
-
-[main-issue]: MAIN-ISSUE-LINK
-
-## Summary
-
-This issue is to rollout [the feature][main-issue] on production,
-that is currently behind the `<feature-flag-name>` feature flag.
-
-<!-- Short description of what the feature is about and link to relevant other issues. -->
+Remove the `:feature_name` feature flag ...
 
 ## Owners
 
 - Team: NAME_OF_TEAM
 - Most appropriate slack channel to reach out to: `#g_TEAM_NAME`
 - Best individual to reach out to: NAME
-- PM: NAME
-
-## Stakeholders
-
-<!--
-Are there any other stages or teams involved that need to be kept in the loop?
-
-- Name of a PM
-- The Support Team
-- The Delivery Team
--->
 
 ## Expectations
 
-### What are we expecting to happen?
-
-<!-- Describe the expected outcome when rolling out this feature -->
-
-### When is the feature viable?
-
-<!-- What are the settings we need to configure in order to have this feature viable? -->
-
-<!--
-Example below:
-
-1. Enable service ping collection
-   `ApplicationSetting.first.update(usage_ping_enabled: true)`
--->
+### What are we expecting to happen?
 
 ### What might happen if this goes wrong?
 
-<!-- Should the feature flag be turned off? Any MRs that need to be rolled back? Communication that needs to happen? What are some things you can think of that could go wrong - data loss or broken pages? -->
-
 ### What can we monitor to detect problems with this?
 
 <!-- Which dashboards from https://dashboards.gitlab.net are most relevant? -->
-_Consider mentioning checks for 5xx errors or other anomalies like an increase in redirects
-(302 HTTP response status)_
 
-### What can we check for monitoring production after rollouts?
+## Beta groups/projects
 
-_Consider adding links to check for Sentry errors, Production logs for 5xx, 302s, etc._
+If applicable, any groups/projects that are happy to have this feature turned on early. Some organizations may wish to test big changes they are interested in with a small subset of users ahead of time for example.
 
-## Rollout Steps
+- `gitlab-org/gitlab` project
+- `gitlab-org`/`gitlab-com` groups
+- ...
 
-Note: Please make sure to run the chatops commands in the slack channel that gets impacted by the command.
+## Roll Out Steps
 
-### Rollout on non-production environments
+- [ ] Enable on staging
+- [ ] Test on staging
+- [ ] Ensure that documentation has been updated
+- [ ] Enable on GitLab.com for individual groups/projects listed above and verify behaviour
+- [ ] Coordinate a time to enable the flag with `#production` and `#g_delivery` on slack.
+- [ ] Announce on the issue an estimated time this will be enabled on GitLab.com
+- [ ] Enable on GitLab.com by running chatops command in `#production`
+- [ ] Cross post chatops slack command to `#support_gitlab-com` and in your team channel
+- [ ] Announce on the issue that the flag has been enabled
+- [ ] Remove feature flag and add changelog entry
+- [ ] After the flag removal is deployed, [clean up the feature flag](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) by running chatops command in `#production` channel
 
-- [ ] Verify the MR with the feature flag is merged to master.
-- Verify that the feature MRs have been deployed to non-production environments with:
-    - [ ] `/chatops run auto_deploy status <merge-commit-of-your-feature>`
-- [ ] Enable the feature globally on non-production environments.
-    - [ ] `/chatops run feature set <feature-flag-name> true --dev --staging --staging-ref`
-    - If the feature flag causes QA end-to-end tests to fail:
-      - [ ] Disable the feature flag on staging to avoid blocking [deployments](https://about.gitlab.com/handbook/engineering/deployments-and-releases/deployments/).
-- [ ] Verify that the feature works as expected. Posting the QA result in this issue is preferable.
-      The best environment to validate the feature in is [staging-canary](https://about.gitlab.com/handbook/engineering/infrastructure/environments/#staging-canary)
-      as this is the first environment deployed to. Note you will need to make sure you are configured to use canary as outlined [here](https://about.gitlab.com/handbook/engineering/infrastructure/environments/canary-stage/)
-      when accessing the staging environment in order to make sure you are testing appropriately.
-
-For assistance with QA end-to-end test failures, please reach out via the `#quality` Slack channel. Note that QA test failures on staging-ref [don't block deployments](https://about.gitlab.com/handbook/engineering/infrastructure/environments/staging-ref/#how-to-use-staging-ref).  
-
-### Specific rollout on production
-
-For visibility, all `/chatops` commands that target production should be executed in the `#production` slack channel and cross-posted (with the command results) to the responsible team's slack channel (`#g_TEAM_NAME`).
-
-- Ensure that the feature MRs have been deployed to both production and canary.
-    - [ ] `/chatops run auto_deploy status <merge-commit-of-your-feature>`
-- Depending on the [type of actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors) you are using, pick one of these options:
-  - If you're using **project-actor**, you must enable the feature on these entries:
-    - [ ] `/chatops run feature set --project=gitlab-org/gitlab,gitlab-org/gitlab-foss,gitlab-com/www-gitlab-com <feature-flag-name> true`
-  - If you're using **group-actor**, you must enable the feature on these entries:
-    - [ ] `/chatops run feature set --group=gitlab-org,gitlab-com <feature-flag-name> true`
-  - If you're using **user-actor**, you must enable the feature on these entries:
-    - [ ] `/chatops run feature set --user=<your-username> <feature-flag-name> true`
-- [ ] Verify that the feature works on the specific entries. Posting the QA result in this issue is preferable.
-
-### Preparation before global rollout
-
-- [ ] Set a milestone to the rollout issue to signal for enabling and removing the feature flag when it is stable.
-- [ ] Check if the feature flag change needs to be accompanied with a
-  [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
-  Cross link the issue here if it does.
-- [ ] Ensure that you or a representative in development can be available for at least 2 hours after feature flag updates in production.
-  If a different developer will be covering, or an exception is needed, please inform the oncall SRE by using the `@sre-oncall` Slack alias.
-- [ ] Ensure that documentation has been updated ([More info](https://docs.gitlab.com/ee/development/documentation/feature_flags.html#features-that-became-enabled-by-default)).
-- [ ] Leave a comment on [the feature issue][main-issue] announcing estimated time when this feature flag will be enabled on GitLab.com.
-- [ ] Ensure that any breaking changes have been announced following the [release post process](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes) to ensure GitLab customers are aware.
-- [ ] Notify `#support_gitlab-com` and your team channel ([more guidance when this is necessary in the dev docs](https://docs.gitlab.com/ee/development/feature_flags/controls.html#communicate-the-change)).
-- [ ] Ensure that the feature flag rollout plan is reviewed by another developer familiar with the domain.
-
-### Global rollout on production
-
-For visibility, all `/chatops` commands that target production should be executed in the `#production` slack channel and cross-posted (with the command results) to the responsible team's slack channel (`#g_TEAM_NAME`).
-
-- [ ] [Incrementally roll out](https://docs.gitlab.com/ee/development/feature_flags/controls.html#process) the feature.
-  - [ ] Between every step wait for at least 15 minutes and monitor the appropriate graphs on https://dashboards.gitlab.net.
-  - If the feature flag in code has [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform **actor-based** rollout.
-    - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage> --actors`
-  - If the feature flag in code does **NOT** have [an actor](https://docs.gitlab.com/ee/development/feature_flags/#feature-actors), perform time-based rollout (**random** rollout).
-    - [ ] `/chatops run feature set <feature-flag-name> <rollout-percentage> --random`
-  - Enable the feature globally on production environment.
-    - [ ] `/chatops run feature set <feature-flag-name> true`
-- [ ] Observe appropriate graphs on https://dashboards.gitlab.net and verify that services are not affected.
-- [ ] Leave a comment on [the feature issue][main-issue] announcing that the feature has been globally enabled.
-- [ ] Wait for [at least one day for the verification term](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release).
-
-### (Optional) Release the feature with the feature flag
-
-If you're still unsure whether the feature is [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
-but want to release it in the current milestone, you can change the default state of the feature flag to be enabled.
-To do so, follow these steps:
-
-- [ ] Create a merge request with the following changes. Ask for review and merge it.
-    - [ ] Set the `default_enabled` attribute in [the feature flag definition](https://docs.gitlab.com/ee/development/feature_flags/#feature-flag-definition-and-validation) to `true`.
-    - [ ] Review [what warrants a changelog entry](https://docs.gitlab.com/ee/development/changelog.html#what-warrants-a-changelog-entry) and decide if [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog) is needed.
-- [ ] Ensure that the default-enabling MR has been included in the release package.
-      If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
-      the feature can be officially announced in a release blog post.
-    - [ ] `/chatops run release check <merge-request-url> <milestone>`
-- [ ] Consider cleaning up the feature flag from all environments by running these chatops command in `#production` channel. Otherwise these settings may override the default enabled.
-    - [ ] `/chatops run feature delete <feature-flag-name> --dev --staging --staging-ref --production`
-- [ ] Close [the feature issue][main-issue] to indicate the feature will be released in the current milestone.
-- [ ] Set the next milestone to this rollout issue for scheduling [the flag removal](#release-the-feature).
-- [ ] (Optional) You can [create a separate issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) for scheduling the steps below to [Release the feature](#release-the-feature).
-    - [ ] Set the title to "[Feature flag] Cleanup `<feature-flag-name>`".
-    - [ ] Execute the `/copy_metadata <this-rollout-issue-link>` quick action to copy the labels from this rollout issue.
-    - [ ] Link this rollout issue as a related issue.
-    - [ ] Close this rollout issue.
-
-**WARNING:** This approach has the downside that it makes it difficult for us to
-[clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up) the flag.
-For example, on-premise users could disable the feature on their GitLab instance. But when you
-remove the flag at some point, they suddenly see the feature as enabled and they can't roll it back
-to the previous behavior. To avoid this potential breaking change, use this approach only for urgent
-matters.
-
-### Release the feature
-
-After the feature has been [deemed stable](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release),
-the [clean up](https://docs.gitlab.com/ee/development/feature_flags/controls.html#cleaning-up)
-should be done as soon as possible to permanently enable the feature and reduce complexity in the
-codebase.
-
-You can either [create a follow-up issue for Feature Flag Cleanup](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Feature%20Flag%20Cleanup) or use the checklist below in this same issue.
-
-<!-- The checklist here is to help stakeholders keep track of the feature flag status -->
-- [ ] Create a merge request to remove `<feature-flag-name>` feature flag. Ask for review and merge it.
-    - [ ] Remove all references to the feature flag from the codebase.
-    - [ ] Remove the YAML definitions for the feature from the repository.
-    - [ ] Create [a changelog entry](https://docs.gitlab.com/ee/development/feature_flags/#changelog).
-- [ ] Ensure that the cleanup MR has been included in the release package.
-      If the merge request was deployed before [the monthly release was tagged](https://about.gitlab.com/handbook/engineering/releases/#self-managed-releases-1),
-      the feature can be officially announced in a release blog post.
-    - [ ] `/chatops run release check <merge-request-url> <milestone>`
-- [ ] Close [the feature issue][main-issue] to indicate the feature will be released in the current milestone.
-- [ ] Clean up the feature flag from all environments by running these chatops command in `#production` channel:
-    - [ ] `/chatops run feature delete <feature-flag-name> --dev --staging --staging-ref --production`
-- [ ] Close this rollout issue.
-
-## Rollback Steps
-
-- [ ] This feature can be disabled by running the following Chatops command:
-
-```
-/chatops run feature set <feature-flag-name> false
-```
-
-<!-- A feature flag can also be used for rolling out a bug fix or a maintenance work.
-In this scenario, labels must be related to it, for example; ~"type::feature", ~"type::bug" or ~"type::maintenance".
-Please use /copy_metadata to copy the labels from the issue you're rolling out. -->
-
-/label ~group::
 /label ~"feature flag"
-/assign me
-/due in 1 month

.gitlab/issue_templates/Feature Proposal - basic.md

@@ -1,19 +0,0 @@
-<!-- This template is a great use for issues that are feature::additions or technical tasks for larger issues.-->
-
-### Proposal
-
-<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
-
-<!-- Consider adding related issues and epics to this issue. You can also reference the Feature Proposal Template (https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md) for additional details to consider adding to this issue. Additionally, as a data oriented organization, when your feature exits planning breakdown, consider adding the `What does success look like, and how can we measure that?` section.
--->
-
-<!-- Label reminders
-Use the following resources to find the appropriate labels:
-- Use only one tier label choosing the lowest tier this is intended for
-- https://gitlab.com/gitlab-org/gitlab/-/labels
-- https://about.gitlab.com/handbook/product/categories/features/
--->
-
-/label ~group:: ~section:: ~Category:
-/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
-/label ~"type::feature" ~"feature::addition" ~documentation

.gitlab/issue_templates/Feature Proposal - lean.md

@@ -1,58 +0,0 @@
-<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator:  https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab.
-
-The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). -->
-
-### Release notes
-
-<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
-
-### Problem to solve
-
-<!-- What is the user problem you are trying to solve with this issue? -->
-
-### Proposal
-
-<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
-
-### Intended users
-
-<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
-
-Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
-
-* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
-* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
-* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
-* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
-* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
-* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
-* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
-* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
-* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
-* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
-* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
-* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
-* [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
-* [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director)
-* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
-* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
--->
-
-### Feature Usage Metrics
-
-<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
-
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
-
--->
-
-<!-- Label reminders
-Use the following resources to find the appropriate labels:
-- Use only one tier label choosing the lowest tier this is intended for
-- https://gitlab.com/gitlab-org/gitlab/-/labels
-- https://about.gitlab.com/handbook/product/categories/features/
--->
-
-/label ~group:: ~section:: ~Category:
-/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
-/label ~"type::feature" ~documentation ~direction

.gitlab/issue_templates/Feature proposal - detailed.md

@@ -1,134 +0,0 @@
-<!-- The first section "Release notes" is required if you want to have your release post blog MR auto generated. Currently in BETA, details on the **release post item generator** can be found in the handbook:  https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator and this video: https://www.youtube.com/watch?v=rfn9ebgTwKg. The next four sections: "Problem to solve", "Intended users", "User experience goal", and "Proposal", are strongly recommended in your first draft, while the rest of the sections can be filled out during the problem validation or breakdown phase. However, keep in mind that providing complete and relevant information early helps our product team validate the problem and start working on a solution. -->
-
-### Release notes
-
-<!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " -->
-
-### Problem to solve
-
-<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
-
-### Intended users
-
-<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
-
-Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
-
-* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
-* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
-* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
-* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
-* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
-* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
-* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
-* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
-* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
-* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
-* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
-* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
-* [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
-* [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director)
-* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
-* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
-
--->
-
-### User experience goal
-
-<!-- What is the single user experience workflow this problem addresses?
-For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>"
-https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ -->
-
-### Proposal
-
-<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
-
-### Further details
-
-<!-- Include use cases, benefits, goals, or any other details that will help us understand the problem better. -->
-
-### Permissions and Security
-
-<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?
-Consider adding checkboxes and expectations of users with certain levels of membership https://docs.gitlab.com/ee/user/permissions.html
-* [ ] Add expected impact to members with no access (0)
-* [ ] Add expected impact to Guest (10) members
-* [ ] Add expected impact to Reporter (20) members
-* [ ] Add expected impact to Developer (30) members
-* [ ] Add expected impact to Maintainer (40) members
-* [ ] Add expected impact to Owner (50) members
-
-Please consider performing a threat model for the code changes that are introduced as part of this feature. To get started, refer to our Threat Modeling handbook page https://about.gitlab.com/handbook/security/threat_modeling/#threat-modeling.
-
-Don't hesitate to reach out to the Application Security Team (`@gitlab-com/gl-security/appsec`) to discuss any security concerns.
--->
-
-### Documentation
-
-<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/workflow.html#for-a-product-change
-
-* Add all known Documentation Requirements in this section. See https://docs.gitlab.com/ee/development/documentation/workflow.html
-* If this feature requires changing permissions, update the permissions document. See https://docs.gitlab.com/ee/user/permissions.html -->
-
-### Availability & Testing
-
-<!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier.
-
-What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing?
-
-Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance.
-* Unit test changes
-* Integration test changes
-* End-to-end test change
-
-See the Quality Engineering quad planning and test planning processes and reach out to your counterpart Software Engineer in Test for assistance. 
-Quad Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/quad-planning 
-Test Planning: https://about.gitlab.com/handbook/engineering/quality/quality-engineering/test-engineering/#test-planning -->
-
-### Available Tier
-
-<!-- This section should be used for setting the appropriate tier that this feature will belong to. Pricing can be found here: https://about.gitlab.com/pricing/
-
-* Free
-* Premium/Silver
-* Ultimate/Gold
--->
-
-### Feature Usage Metrics
-
-<!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it?
-
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
-
--->
-
-### What does success look like, and how can we measure that?
-
-<!--
-Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.
-
-Create tracking issue using the Snowplow event tracking template. See https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Snowplow%20event%20tracking.md
--->
-
-### What is the type of buyer?
-
-<!-- What is the buyer persona for this feature? See https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/buyer-persona/
-In which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#three-tiers -->
-
-### Is this a cross-stage feature?
-
-<!-- Communicate if this change will affect multiple Stage Groups or product areas. We recommend always start with the assumption that a feature request will have an impact into another Group. Loop in the most relevant PM and Product Designer from that Group to provide strategic support to help align the Group's broader plan and vision, as well as to avoid UX and technical debt. https://about.gitlab.com/handbook/product/#cross-stage-features -->
-
-### What is the competitive advantage or differentiation for this feature?
-
-### Links / references
-
-<!-- Label reminders - you should have one of each of the following labels.
-Use the following resources to find the appropriate labels:
-- Use only one tier label choosing the lowest tier this is intended for
-- https://gitlab.com/gitlab-org/gitlab/-/labels
-- https://about.gitlab.com/handbook/product/categories/features/
--->
-/label ~group:: ~section:: ~Category:
-/label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate"
-/label ~"type::feature" ~documentation ~direction

.gitlab/issue_templates/Feature proposal.md

@@ -0,0 +1,52 @@
+### Problem to solve
+
+<!-- What problem do we solve? -->
+
+### Intended users
+
+<!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
+
+* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
+* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
+* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
+* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
+* [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer)
+* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
+* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
+* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
+
+Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
+
+### Further details
+
+<!-- Include use cases, benefits, and/or goals (contributes to our vision?) -->
+
+### Proposal
+
+<!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey -->
+
+### Permissions and Security
+
+<!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?-->
+
+### Documentation
+
+<!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html
+Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
+If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. -->
+
+### Testing
+
+<!-- What risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ -->
+
+### What does success look like, and how can we measure that?
+
+<!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. -->
+
+### What is the type of buyer? 
+
+<!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers -->
+
+### Links / references
+
+/label ~feature

.gitlab/issue_templates/Fulfillment Group UX Issue.md

@@ -1,59 +0,0 @@
-<!-- This issue template can be used as a starting point for a UX Issue. This is not a feature request, rather an issue that is being created for a product designer to solve a problem.
-
-The goal of this template is to ensure we have captured all the information available to the product designer so they can approach the problem creatively and efficiently. Please add links to SSOT if this informatin exists elsewhere. -->
-
-### Who will use this solution?
-
-<!-- If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later.
-
-Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
-
-* [Cameron (Compliance Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#cameron-compliance-manager)
-* [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager)
-* [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead)
-* [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer)
-* [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer)
-* [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)
-* [Sidney (Systems Administrator)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sidney-systems-administrator)
-* [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst)
-* [Rachel (Release Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#rachel-release-manager)
-* [Alex (Security Operations Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#alex-security-operations-engineer)
-* [Simone (Software Engineer in Test)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#simone-software-engineer-in-test)
-* [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops)
-* [Ingrid (Infrastructure Operator)](https://about.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator)
-* [Dakota (Application Development Director)](https://about.gitlab.com/handbook/product/personas/#dakota-application-development-director)
-* [Dana (Data Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#dana-data-analyst)
-* [Eddie (Content Editor)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#eddie-content-editor)
-
--->
-
-
-### What problem do they have?
-
-
-### When do they have the problem?
-
-
-### Where in the app do they have the problem and at what frequency (if known)?
-
-
-### Why will a design help them?
-
-
-### What is the JTBD and/or Tasks?
-
-
-### Is this problem supported by user research (please link relevant research issue/s)?
-
-
-### Known technical constraints
-
-
-### How does this help the business?
-
-
-
-
-
-/label ~"group::" ~"section::"  ~"Category:"  ~UX
-

.gitlab/issue_templates/Geo Replicate a new Git repository type.md

@@ -1,800 +0,0 @@
-<!--
-
-This template is based on a model named `CoolWidget`.
-
-To adapt this template, find and replace the following tokens:
-
-- `CoolWidget`
-- `Cool Widget`
-- `cool_widget`
-- `coolWidget`
-
-If your Model's pluralized form is non-standard, i.e. it doesn't just end in `s`, then find and replace the following tokens *first*:
-
-- `CoolWidgets`
-- `Cool Widgets`
-- `cool_widgets`
-- `coolWidgets`
-
--->
-
-## Replicate Cool Widgets - Repository
-
-This issue is for implementing Geo replication and verification of Cool Widgets.
-
-For more background, see [Geo self-service framework](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo/framework.md).
-
-In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md).
-
-There are three main sections below. It is a good idea to structure your merge requests this way as well:
-
-1. Modify database schemas to prepare to add Geo support for Cool Widgets
-1. Implement Geo support of Cool Widgets behind a feature flag
-1. Release Geo support of Cool Widgets
-
-It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
-
-You can look into the following example for implementing replication/verification for a new Git repository type:
-- [Add snippet repository verification](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56596)
-
-### Modify database schemas to prepare to add Geo support for Cool Widgets
-
-#### Add the registry table to track replication and verification state
-
-Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo.md#tracking-database) independent of the main database. It is used to track the replication and verification state of all replicables. Every Model has a corresponding "registry" table in the Geo tracking database.
-
-- [ ] Create the migration file in `ee/db/geo/migrate`:
-
-  ```shell
-  bin/rails generate migration CreateCoolWidgetRegistry --database geo
-  ```
-
-- [ ] Replace the contents of the migration file with the following. Note that we cannot add a foreign key constraint on `cool_widget_id` because the `cool_widgets` table is in a different database. The application code must handle logic such as propagating deletions.
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.1]
-    def change
-      create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
-        t.bigint :cool_widget_id, null: false
-        t.datetime_with_timezone :created_at, null: false
-        t.datetime_with_timezone :last_synced_at
-        t.datetime_with_timezone :retry_at
-        t.datetime_with_timezone :verified_at
-        t.datetime_with_timezone :verification_started_at
-        t.datetime_with_timezone :verification_retry_at
-        t.integer :state, default: 0, null: false, limit: 2
-        t.integer :verification_state, default: 0, null: false, limit: 2
-        t.integer :retry_count, default: 0, limit: 2, null: false
-        t.integer :verification_retry_count, default: 0, limit: 2, null: false
-        t.boolean :checksum_mismatch, default: false, null: false
-        t.boolean :force_to_redownload, default: false, null: false
-        t.boolean :missing_on_primary, default: false, null: false
-        t.binary :verification_checksum
-        t.binary :verification_checksum_mismatched
-        t.text :verification_failure, limit: 255
-        t.text :last_sync_failure, limit: 255
-
-        t.index :cool_widget_id, name: :index_cool_widget_registry_on_cool_widget_id, unique: true
-        t.index :retry_at
-        t.index :state
-        # To optimize performance of CoolWidgetRegistry.verification_failed_batch
-        t.index :verification_retry_at,
-          name: :cool_widget_registry_failed_verification,
-          order: "NULLS FIRST",
-          where: "((state = 2) AND (verification_state = 3))"
-        # To optimize performance of CoolWidgetRegistry.needs_verification_count
-        t.index :verification_state,
-          name: :cool_widget_registry_needs_verification,
-          where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
-        # To optimize performance of CoolWidgetRegistry.verification_pending_batch
-        t.index :verified_at,
-          name: :cool_widget_registry_pending_verification,
-          order: "NULLS FIRST",
-          where: "((state = 2) AND (verification_state = 0))"
-      end
-    end
-  end
-  ```
-
-- [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
-
-- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`ee/db/geo/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/geo/docs):
-
-  ```yaml
-  table_name: cool_widget_registry
-  description: Description example
-  introduced_by_url: Merge request link
-  milestone: Milestone example
-  feature_categories:
-   - Feature category example
-  classes:
-   - Class example
-  gitlab_schema: gitlab_geo
-  ```
-
-- [ ] Run Geo tracking database migrations:
-
-  ```shell
-  bin/rake db:migrate:geo
-  ```
-
-- [ ] Be sure to commit the relevant changes in `ee/db/geo/structure.sql` and the file under `ee/db/geo/schema_migrations`
-
-### Add verification state to the Model
-
-The Geo primary site needs to checksum every replicable so secondaries can verify their own checksums. To do this, Geo requires the Model to have an associated table to track verification state.
-
-- [ ] Create the migration file in `db/migrate`:
-
-  ```shell
-  bin/rails generate migration CreateCoolWidgetStates
-  ```
-
-- [ ] Replace the contents of the migration file with:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.1]
-    VERIFICATION_STATE_INDEX_NAME = "index_cool_widget_states_on_verification_state"
-    PENDING_VERIFICATION_INDEX_NAME = "index_cool_widget_states_pending_verification"
-    FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
-    NEEDS_VERIFICATION_INDEX_NAME = "index_cool_widget_states_needs_verification"
-
-    enable_lock_retries!
-
-    def up
-      create_table :cool_widget_states, id: false do |t|
-        t.datetime_with_timezone :verification_started_at
-        t.datetime_with_timezone :verification_retry_at
-        t.datetime_with_timezone :verified_at
-        t.references :cool_widget, primary_key: true, default: nil, index: false, foreign_key: { on_delete: :cascade }
-        t.integer :verification_state, default: 0, limit: 2, null: false
-        t.integer :verification_retry_count, default: 0, limit: 2, null: false
-        t.binary :verification_checksum, using: 'verification_checksum::bytea'
-        t.text :verification_failure, limit: 255
-
-        t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-        t.index :verified_at,
-          where: "(verification_state = 0)",
-          order: { verified_at: 'ASC NULLS FIRST' },
-          name: PENDING_VERIFICATION_INDEX_NAME
-        t.index :verification_retry_at,
-          where: "(verification_state = 3)",
-          order: { verification_retry_at: 'ASC NULLS FIRST' },
-          name: FAILED_VERIFICATION_INDEX_NAME
-        t.index :verification_state,
-          where: "(verification_state = 0 OR verification_state = 3)",
-          name: NEEDS_VERIFICATION_INDEX_NAME
-      end
-    end
-
-    def down
-      drop_table :cool_widget_states
-    end
-  end
-  ```
-
-- [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
-
-- [ ] If `cool_widgets` is a high-traffic table, follow [the database documentation to use `with_lock_retries`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/migration_style_guide.md#when-to-use-the-helper-method)
-
-- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
-
-  ```yaml
-  ---
-  table_name: cool_widget_states
-  description: Separate table for cool widget verification states
-  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
-  milestone: 'XX.Y'
-  feature_categories:
-   - geo_replication
-  classes:
-   - Geo::CoolWidgetState
-  gitlab_schema: gitlab_main
-  ```
-
-- [ ] Run database migrations:
-
-  ```shell
-  bin/rake db:migrate
-  ```
-
-- [ ] Be sure to commit the relevant changes in `db/structure.sql` and the file under `db/schema_migrations`
-
-That's all of the required database changes.
-
-### Implement Geo support of Cool Widgets behind a feature flag
-
-#### Step 1. Implement replication and verification
-
-- [ ] Add the following lines to the `cool_widget` model to accomplish some important tasks:
-  - Include `::Geo::ReplicableModel` in the `CoolWidget` class, and specify the Replicator class `with_replicator Geo::CoolWidgetReplicator`.
-  - Include the `::Geo::VerifiableModel` concern.
-  - Delegate verification related methods to the `cool_widget_state` model.
-  - For verification, override some scopes to use the `cool_widget_states` table instead of the model table.
-  - Implement the `verification_state_object` method to return the object that holds
-    the verification details
-  - Override some methods to use the `cool_widget_states` table in verification-related queries.
-
-  Pay some attention to method `pool_repository`. Not every repository type uses repository pooling. As Geo prefers to use repository snapshotting, it can lead to data loss. Make sure to overwrite `pool_repository` so it returns nil for repositories that do not have pools.
-
-  At this point the `CoolWidget` class should look like this:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CoolWidget < ApplicationRecord
-    ...
-    include ::Geo::ReplicableModel
-    include ::Geo::VerifiableModel
-
-    delegate(*::Geo::VerificationState::VERIFICATION_METHODS, to: :cool_widget_state)
-
-    with_replicator Geo::CoolWidgetReplicator
-
-    has_one :cool_widget_state, autosave: false, inverse_of: :cool_widget, class_name: 'Geo::CoolWidgetState'
-
-    after_save :save_verification_details
-
-    # Override the `all` default if not all records can be replicated. For an
-    # example of an existing Model that needs to do this, see
-    # `EE::MergeRequestDiff`.
-    # scope :available_replicables, -> { all }
-
-    scope :available_verifiables, -> { joins(:cool_widget_state) }
-
-    scope :checksummed, -> {
-      joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil })
-    }
-
-    scope :not_checksummed, -> {
-      joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil })
-    }
-
-    scope :with_verification_state, ->(state) {
-      joins(:cool_widget_state)
-        .where(cool_widget_states: { verification_state: verification_state_value(state) })
-    }
-
-    def verification_state_object
-      cool_widget_state
-    end
-    ...
-
-    class_methods do
-      extend ::Gitlab::Utils::Override
-      ...
-
-      # @param primary_key_in [Range, CoolWidget] arg to pass to primary_key_in scope
-      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced
-      #         to this node, restricted by primary key
-      def replicables_for_current_secondary(primary_key_in)
-        # This issue template does not help you write this method.
-        #
-        # This method is called only on Geo secondary sites. It is called when
-        # we want to know which records to replicate. This is not easy to automate
-        # because for example:
-        #
-        # * The "selective sync" feature allows admins to choose which namespaces
-        #   to replicate, per secondary site. Most Models are scoped to a
-        #   namespace, but the nature of the relationship to a namespace varies
-        #   between Models.
-        # * The "selective sync" feature allows admins to choose which shards to
-        #   replicate, per secondary site. Repositories are associated with
-        #   shards. Most blob types are not, but Project Uploads are.
-        # * Remote stored replicables are not replicated, by default. But the
-        #   setting `sync_object_storage` enables replication of remote stored
-        #   replicables.
-        #
-        # Search the codebase for examples, and consult a Geo expert if needed.
-      end
-
-      override :verification_state_table_class
-      def verification_state_table_class
-        CoolWidgetState
-      end
-    end
-
-    # Geo checks this method in FrameworkRepositorySyncService to avoid
-    # snapshotting repositories using object pools
-    def pool_repository
-      nil
-    end
-
-    def cool_widget_state
-      super || build_cool_widget_state
-    end
-
-    ...
-  end
-  ```
-
-- [ ] Implement `CoolWidget.replicables_for_current_secondary` above.
-- [ ] Ensure `CoolWidget.replicables_for_current_secondary` is well-tested. Search the codebase for `replicables_for_current_secondary` to find examples of parameterized table specs. You may need to add more `FactoryBot` traits.
-- [ ] Add the following shared examples to `ee/spec/models/ee/cool_widget_spec.rb`:
-
-  ```ruby
-    include_examples 'a replicable model with a separate table for verification state' do
-      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is in `Geo::ReplicableModel.verifiables` scope
-      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `Geo::ReplicableModel.verifiables` scope
-    end
-  ```
-
-- [ ] Create `ee/app/replicators/geo/cool_widget_replicator.rb`. Implement the `#repository` method which should return a `<Repository>` instance, and implement the class method `.model` to return the `CoolWidget` class:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetReplicator < Gitlab::Geo::Replicator
-      include ::Geo::RepositoryReplicatorStrategy
-      extend ::Gitlab::Utils::Override
-
-      def self.model
-        ::CoolWidget
-      end
-
-      def self.git_access_class
-        ::Gitlab::GitAccessCoolWidget
-      end
-
-      def self.no_repo_message
-        git_access_class.error_message(:no_repo)
-      end
-
-      override :verification_feature_flag_enabled?
-      def self.verification_feature_flag_enabled?
-        # We are adding verification at the same time as replication, so we
-        # don't need to toggle verification separately from replication. When
-        # the replication feature flag is off, then verification is also off
-        # (see `VerifiableReplicator.verification_enabled?`)
-        true
-      end
-
-      override :housekeeping_enabled?
-      def self.housekeeping_enabled?
-        # Remove this method if the new Git repository type supports git
-        # repository housekeeping and the ::CoolWidget#git_garbage_collect_worker_klass
-        # is implemented. If the data type requires any action to be performed
-        # before running the housekeeping override the `before_housekeeping` method
-        # (see `RepositoryReplicatorStrategy#before_housekeeping`)
-        false
-      end
-
-      def repository
-        model_record.repository
-      end
-    end
-  end
-  ```
-
-- [ ] Make sure Geo push events are created. Usually it needs some change in the `app/workers/post_receive.rb` file. Example:
-
-  ```ruby
-  def replicate_cool_widget_changes(cool_widget)
-    if ::Gitlab::Geo.primary?
-      cool_widget.replicator.handle_after_update if cool_widget
-    end
-  end
-  ```
-
-  See `app/workers/post_receive.rb` for more examples.
-
-- [ ] Make sure the repository removal is also handled. You may need to add something like the following in the destroy service of the repository:
-
-  ```ruby
-  cool_widget.replicator.handle_after_destroy if cool_widget.repository
-  ```
-
-- [ ] Make sure a Geo secondary site can request and download Cool Widgets on the Geo primary site. You may need to make some changes to `Gitlab::GitAccessCoolWidget`. For example, see [this change for Group-level Wikis](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54914/diffs?commit_id=0f2b36f66697b4addbc69bd377ee2818f648dd33).
-
-- [ ] Make sure a Geo secondary site can replicate Cool Widgets where repository does not exist on the Geo primary site. The only way to know about this is to parse the error text. You may need to make some changes to `Gitlab::CoolWidgetReplicator.no_repo_message` to return the proper error message. For example, see [this change for Group-level Wikis](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74133).
-
-- [ ] Generate the feature flag definition files by running the feature flag commands and following the command prompts:
-
-  ```shell
-  bin/feature-flag --ee geo_cool_widget_replication --type development --group 'group::geo'
-  ```
-
-- [ ] Add this replicator class to the method `replicator_classes` in
-  `ee/lib/gitlab/geo.rb`:
-
-  ```ruby
-  REPLICATOR_CLASSES = [
-    ::Geo::PackageFileReplicator,
-    ::Geo::CoolWidgetReplicator
-  ]
-  ```
-
-- [ ] Create `ee/spec/replicators/geo/cool_widget_replicator_spec.rb` and perform the necessary setup to define the `model_record` variable for the shared examples:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetReplicator, feature_category: :geo_replication do
-    let(:model_record) { build(:cool_widget) }
-
-    include_examples 'a repository replicator'
-    include_examples 'a verifiable replicator'
-  end
-  ```
-
-- [ ] Create `ee/app/models/geo/cool_widget_registry.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetRegistry < Geo::BaseRegistry
-      include ::Geo::ReplicableRegistry
-      include ::Geo::VerifiableRegistry
-
-      MODEL_CLASS = ::CoolWidget
-      MODEL_FOREIGN_KEY = :cool_widget_id
-
-      belongs_to :cool_widget, class_name: 'CoolWidget'
-    end
-  end
-  ```
-
-- [ ] Update `REGISTRY_CLASSES` in `ee/app/workers/geo/secondary/registry_consistency_worker.rb`.
-- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/support/helpers/ee/geo_helpers.rb`.
-- [ ] Update `it 'creates missing registries for each registry class'` in `ee/spec/workers/geo/secondary/registry_consistency_worker_spec.rb`.
-- [ ] Add `cool_widget_registry` to `ActiveSupport::Inflector.inflections` in `config/initializers_before_autoloader/000_inflections.rb`.
-- [ ] Create `ee/spec/factories/geo/cool_widget_registry.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  FactoryBot.define do
-    factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
-      cool_widget # This association should have data, like a file or repository
-      state { Geo::CoolWidgetRegistry.state_value(:pending) }
-
-      trait :synced do
-        state { Geo::CoolWidgetRegistry.state_value(:synced) }
-        last_synced_at { 5.days.ago }
-      end
-
-      trait :failed do
-        state { Geo::CoolWidgetRegistry.state_value(:failed) }
-        last_synced_at { 1.day.ago }
-        retry_count { 2 }
-        retry_at { 2.hours.from_now }
-        last_sync_failure { 'Random error' }
-      end
-
-      trait :started do
-        state { Geo::CoolWidgetRegistry.state_value(:started) }
-        last_synced_at { 1.day.ago }
-        retry_count { 0 }
-      end
-
-      trait :verification_succeeded do
-        verification_checksum { 'e079a831cab27bcda7d81cd9b48296d0c3dd92ef' }
-        verification_state { Geo::CoolWidgetRegistry.verification_state_value(:verification_succeeded) }
-        verified_at { 5.days.ago }
-      end
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/models/geo/cool_widget_registry_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model, feature_category: :geo_replication do
-    let_it_be(:registry) { create(:geo_cool_widget_registry) }
-
-    specify 'factory is valid' do
-      expect(registry).to be_valid
-    end
-
-    include_examples 'a Geo framework registry'
-    include_examples 'a Geo verifiable registry'
-  end
-  ```
-
-- [ ] Add the following to `ee/spec/factories/cool_widgets.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  FactoryBot.modify do
-    factory :cool_widget do
-      trait :verification_succeeded do
-          with_file
-          verification_checksum { 'abc' }
-          verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-      end
-
-      trait :verification_failed do
-          with_file
-          verification_failure { 'Could not calculate the checksum' }
-          verification_state { CoolWidget.verification_state_value(:verification_failed) }
-      end
-    end
-  end
-  ```
-
-  If there is not an existing factory for the object in `spec/factories/cool_widgets.rb`, wrap the traits in `FactoryBot.create` instead of `FactoryBot.modify`.
-
-- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
-
-- [ ] Following [the example of Merge Request Diffs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309) add a `Geo::CoolWidgetState` model in `ee/app/models/geo/cool_widget_state.rb`:
-
-  ``` ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetState < ApplicationRecord
-      include ::Geo::VerificationStateDefinition
-
-      self.primary_key = :cool_widget_id
-
-      belongs_to :cool_widget, inverse_of: :cool_widget_state
-
-      validates :verification_failure, length: { maximum: 255 }
-      validates :verification_state, :cool_widget, presence: true
-    end
-  end
-  ```
-
-- [ ] Add a `factory` for `cool_widget_state`, in `ee/spec/factories/geo/cool_widget_states.rb`:
-
-  ``` ruby
-  # frozen_string_literal: true
-
-  FactoryBot.define do
-    factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
-      cool_widget
-
-      trait :checksummed do
-        verification_checksum { 'abc' }
-      end
-
-      trait :checksum_failure do
-        verification_failure { 'Could not calculate the checksum' }
-      end
-    end
-  end
-  ```
-
-- [ ] Add `[:geo_cool_widget_state, any]` to `skipped` in `spec/models/factories_spec.rb`
-
-#### Step 2. Implement metrics gathering
-
-Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus` for display in the UI, and sent to Prometheus:
-
-- [ ] Add the following fields to Geo Node Status example responses in `doc/api/geo_nodes.md`:
-  - `cool_widgets_count`
-  - `cool_widgets_checksum_total_count`
-  - `cool_widgets_checksummed_count`
-  - `cool_widgets_checksum_failed_count`
-  - `cool_widgets_synced_count`
-  - `cool_widgets_failed_count`
-  - `cool_widgets_registry_count`
-  - `cool_widgets_verification_total_count`
-  - `cool_widgets_verified_count`
-  - `cool_widgets_verification_failed_count`
-  - `cool_widgets_synced_in_percentage`
-  - `cool_widgets_verified_in_percentage`
-- [ ] Add the same fields to `GET /geo_nodes/status` example response in
-  `ee/spec/fixtures/api/schemas/public_api/v4/geo_node_status.json`.
-- [ ] Add the following fields to the `Sidekiq metrics` table in `doc/administration/monitoring/prometheus/gitlab_metrics.md`:
-  ```markdown
-  | `geo_cool_widgets` | Gauge | XX.Y | Number of Cool Widgets on primary | `url` |
-  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets to checksum on primary | `url` |
-  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets that successfully calculated the checksum on primary | `url` |
-  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets that failed to calculate the checksum on primary | `url` |
-  | `geo_cool_widgets_synced` | Gauge | XX.Y | Number of syncable Cool Widgets synced on secondary | `url` |
-  | `geo_cool_widgets_failed` | Gauge | XX.Y | Number of syncable Cool Widgets failed to sync on secondary | `url` |
-  | `geo_cool_widgets_registry` | Gauge | XX.Y | Number of Cool Widgets in the registry | `url` |
-  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets to attempt to verify on secondary | `url` |
-  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets successfully verified on secondary | `url` |
-  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets that failed verification on secondary | `url` |
-  ```
-- [ ] Run the rake task `geo:dev:ssf_metrics` and commit the changes to `ee/config/metrics/object_schemas/geo_node_usage.json`
-
-Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Sites` view, and Prometheus.
-
-#### Step 3. Implement the GraphQL API
-
-The GraphQL API is used by `Admin > Geo > Replication Details` views, and is directly queryable by administrators.
-
-- [ ] Add a new field to `GeoNodeType` in `ee/app/graphql/types/geo/geo_node_type.rb`:
-
-  ```ruby
-  field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
-        null: true,
-        resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node. '\
-                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
-        alpha: { milestone: '15.5' } # Update the milestone
-  ```
-
-- [ ] Add the new `cool_widget_registries` field name to the `expected_fields` array in `ee/spec/graphql/types/geo/geo_node_type_spec.rb`.
-- [ ] Create `ee/app/graphql/resolvers/geo/cool_widget_registries_resolver.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Resolvers
-    module Geo
-      class CoolWidgetRegistriesResolver < BaseResolver
-        type ::Types::Geo::GeoNodeType.connection_type, null: true
-
-        include RegistriesResolver
-      end
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/graphql/resolvers/geo/cool_widget_registries_resolver_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver, feature_category: :geo_replication do
-    it_behaves_like 'a Geo registries resolver', :geo_cool_widget_registry
-  end
-  ```
-
-- [ ] Create `ee/app/finders/geo/cool_widget_registry_finder.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetRegistryFinder
-      include FrameworkRegistryFinder
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/finders/geo/cool_widget_registry_finder_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetRegistryFinder, feature_category: :geo_replication do
-    it_behaves_like 'a framework registry finder', :geo_cool_widget_registry
-  end
-  ```
-
-- [ ] Create `ee/app/graphql/types/geo/cool_widget_registry_type.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Types
-    module Geo
-      # rubocop:disable Graphql/AuthorizeTypes because it is included
-      class CoolWidgetRegistryType < BaseObject
-        graphql_name 'CoolWidgetRegistry'
-
-        include ::Types::Geo::RegistryType
-
-        description 'Represents the Geo replication and verification state of a cool_widget'
-
-        field :cool_widget_id, GraphQL::Types::ID, null: false, description: 'ID of the Cool Widget.'
-      end
-      # rubocop:enable Graphql/AuthorizeTypes
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/graphql/types/geo/cool_widget_registry_type_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'], feature_category: :geo_replication do
-    it_behaves_like 'a Geo registry type'
-
-    it 'has the expected fields (other than those included in RegistryType)' do
-      expected_fields = %i[cool_widget_id]
-
-      expect(described_class).to have_graphql_fields(*expected_fields).at_least
-    end
-  end
-  ```
-
-- [ ] Add integration tests for providing CoolWidget registry data to the frontend via the GraphQL API, by duplicating and modifying the following shared examples in `ee/spec/requests/api/graphql/geo/registries_spec.rb`:
-
-  ```ruby
-  it_behaves_like 'gets registries for', {
-    field_name: 'coolWidgetRegistries',
-    registry_class_name: 'CoolWidgetRegistry',
-    registry_factory: :geo_cool_widget_registry,
-    registry_foreign_key_field_name: 'coolWidgetId'
-  }
-  ```
-
-- [ ] Update the GraphQL reference documentation:
-
-  ```shell
-  bundle exec rake gitlab:graphql:compile_docs
-  ```
-
-Individual Cool Widget replication and verification data should now be available via the GraphQL API.
-
-#### Step 4. Handle batch destroy
-
-If batch destroy logic is implemented for a replicable, then that logic must be "replicated" by Geo secondaries. The easiest way to do this is use `Geo::BatchEventCreateWorker` to bulk insert a delete event for each replicable.
-
-For example, if `FastDestroyAll` is used, then you may be able to [use `begin_fast_destroy` and `finalize_fast_destroy` hooks, like we did for uploads](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69763).
-
-Or if a special service is used to batch delete records and their associated data, then you probably need to [hook into that service, like we did for job artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79530).
-
-As illustrated by the above two examples, batch destroy logic cannot be handled automatically by Geo secondaries without restricting the way other teams perform batch destroys. It is up to you to produce `Geo::BatchEventCreateWorker` attributes before the records are deleted, and then enqueue `Geo::BatchEventCreateWorker` after the records are deleted.
-
-- [ ] Ensure that any batch destroy of this replicable is replicated to secondary sites
-- [ ] Regardless of implementation details, please verify in specs that when the parent object is removed, the new `Geo::Event` records are created:
-
-```ruby
-  describe '#destroy' do
-    subject { create(:cool_widget) }
-
-    context 'when running in a Geo primary node' do
-      let_it_be(:primary) { create(:geo_node, :primary) }
-      let_it_be(:secondary) { create(:geo_node) }
-
-      it 'logs an event to the Geo event log when bulk removal is used', :sidekiq_inline do
-        stub_current_geo_node(primary)
-
-        expect { subject.project.destroy! }.to change(Geo::Event.where(replicable_name: :cool_widget, event_name: :deleted), :count).by(1)
-
-        payload = Geo::Event.where(replicable_name: :cool_widget, event_name: :deleted).last.payload
-
-        expect(payload['model_record_id']).to eq(subject.id)
-        expect(payload['blob_path']).to eq(subject.relative_path)
-        expect(payload['uploader_class']).to eq('CoolWidgetUploader')
-      end
-    end
-  end
-```
-
-### Code Review
-
-When requesting review from database reviewers:
-
-- [ ] Include a comment mentioning that the change is based on a documented template.
-- [ ] `replicables_for_current_secondary` and `available_replicables` may differ per Model. If their queries are new, then add [query plans](https://docs.gitlab.com/ee/development/database_review.html#query-plans) to the MR description. An easy place to gather SQL queries is your GDK's `log/test.log` when running tests of these methods.
-
-### Release Geo support of Cool Widgets
-
-- [ ] In the rollout issue you created when creating the feature flag, modify the Roll Out Steps:
-  - [ ] Cross out any steps related to testing on production GitLab.com, because Geo is not running on production GitLab.com at the moment.
-  - [ ] Add a step to `Test replication and verification of Cool Widgets on a non-GDK-deployment. For example, using GitLab Environment Toolkit`.
-  - [ ] Add a step to `Ping the Geo PM and EM to coordinate testing`. For example, you might add steps to generate Cool Widgets, and then a Geo engineer may take it from there.
-- [ ] In `ee/config/feature_flags/development/geo_cool_widget_replication.yml`, set `default_enabled: true`
-- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `alpha` option for the released type:
-
-  ```ruby
-  field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
-        null: true,
-        resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node. '\
-                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
-        alpha: { milestone: '15.5' } # Update the milestone
-  ```
-
-- [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
-
-- [ ] Add a row for Cool Widgets to the `Data types` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#data-types)
-- [ ] Add a row for Cool Widgets to the `Limitations on replication/verification` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#limitations-on-replicationverification). If the row already exists, then update it to show that Replication and Verification is released in the current version.

.gitlab/issue_templates/Geo Replicate a new blob type.md

@@ -1,768 +0,0 @@
-<!--
-
-This template is based on a model named `CoolWidget`.
-
-To adapt this template, find and replace the following tokens:
-
-- `CoolWidget`
-- `Cool Widget`
-- `cool_widget`
-- `coolWidget`
-
-If your Model's pluralized form is non-standard, i.e. it doesn't just end in `s`, find and replace the following tokens *first*:
-
-- `CoolWidgets`
-- `Cool Widgets`
-- `cool_widgets`
-- `coolWidgets`
-
--->
-
-## Replicate Cool Widgets - Blob
-
-This issue is for implementing Geo replication and verification of Cool Widgets.
-
-For more background, see [Geo self-service framework](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo/framework.md).
-
-In order to implement and test this feature, you need to first [set up Geo locally](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md).
-
-There are three main sections below. It is a good idea to structure your merge requests this way as well:
-
-1. Modify database schemas to prepare to add Geo support for Cool Widgets
-1. Implement Geo support of Cool Widgets behind a feature flag
-1. Release Geo support of Cool Widgets
-
-It is also a good idea to first open a proof-of-concept merge request. It can be helpful for working out kinks and getting initial support and feedback from the Geo team. As an example, see the [Proof of Concept to replicate Pipeline Artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/56423).
-
-You can look into the following examples of MRs for implementing replication/verification for a new blob type:
-- [Add db changes](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60935) and [add verification for MR diffs using SSF](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309)
-- [Verify Terraform state versions](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58800)
-- [Verify LFS objects](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63981)
-
-### Modify database schemas to prepare to add Geo support for Cool Widgets
-
-#### Add the registry table to track replication and verification state
-
-Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/geo.md#tracking-database) independent of the main database. It is used to track the replication and verification state of all replicables. Every Model has a corresponding "registry" table in the Geo tracking database.
-
-- [ ] Create the migration file in `ee/db/geo/migrate`:
-
-  ```shell
-  bin/rails generate migration CreateCoolWidgetRegistry --database geo
-  ```
-
-- [ ] Replace the contents of the migration file with the following. Note that we cannot add a foreign key constraint on `cool_widget_id` because the `cool_widgets` table is in a different database. The application code must handle logic such as propagating deletions.
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.1]
-    def change
-      create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
-        t.bigint :cool_widget_id, null: false
-        t.datetime_with_timezone :created_at, null: false
-        t.datetime_with_timezone :last_synced_at
-        t.datetime_with_timezone :retry_at
-        t.datetime_with_timezone :verified_at
-        t.datetime_with_timezone :verification_started_at
-        t.datetime_with_timezone :verification_retry_at
-        t.integer :state, default: 0, null: false, limit: 2
-        t.integer :verification_state, default: 0, null: false, limit: 2
-        t.integer :retry_count, default: 0, limit: 2, null: false
-        t.integer :verification_retry_count, default: 0, limit: 2, null: false
-        t.boolean :checksum_mismatch, default: false, null: false
-        t.binary :verification_checksum
-        t.binary :verification_checksum_mismatched
-        t.text :verification_failure, limit: 255
-        t.text :last_sync_failure, limit: 255
-
-        t.index :cool_widget_id, name: :index_cool_widget_registry_on_cool_widget_id, unique: true
-        t.index :retry_at
-        t.index :state
-        # To optimize performance of CoolWidgetRegistry.verification_failed_batch
-        t.index :verification_retry_at,
-          name: :cool_widget_registry_failed_verification,
-          order: "NULLS FIRST",
-          where: "((state = 2) AND (verification_state = 3))"
-        # To optimize performance of CoolWidgetRegistry.needs_verification_count
-        t.index :verification_state,
-          name: :cool_widget_registry_needs_verification,
-          where: "((state = 2) AND (verification_state = ANY (ARRAY[0, 3])))"
-        # To optimize performance of CoolWidgetRegistry.verification_pending_batch
-        t.index :verified_at,
-          name: :cool_widget_registry_pending_verification,
-          order: "NULLS FIRST",
-          where: "((state = 2) AND (verification_state = 0))"
-      end
-    end
-  end
-  ```
-
-- [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
-
-- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`ee/db/geo/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/db/geo/docs):
-
-  ```yaml
-  table_name: cool_widget_registry
-  description: Description example
-  introduced_by_url: Merge request link
-  milestone: Milestone example
-  feature_categories:
-   - Feature category example
-  classes:
-   - Class example
-  gitlab_schema: gitlab_geo
-  ```
-
-- [ ] Run Geo tracking database migrations:
-
-  ```shell
-  bin/rake db:migrate:geo
-  ```
-
-- [ ] Be sure to commit the relevant changes in `ee/db/geo/structure.sql` and the file created under `ee/db/geo/schema_migrations`
-
-### Add verification state fields on the Geo primary site
-
-The Geo primary site needs to checksum every replicable so secondaries can verify their own checksums. To do this, Geo requires fields on the Model. Add verification state fields to a separate table. Consult a database expert if needed.
-
-#### Add verification state fields to a new table
-
-- [ ] Create the migration file in `db/migrate`:
-
-  ```shell
-  bin/rails generate migration CreateCoolWidgetStates
-  ```
-
-- [ ] Replace the contents of the migration file with:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CreateCoolWidgetStates < Gitlab::Database::Migration[2.1]
-    VERIFICATION_STATE_INDEX_NAME = "index_cool_widget_states_on_verification_state"
-    PENDING_VERIFICATION_INDEX_NAME = "index_cool_widget_states_pending_verification"
-    FAILED_VERIFICATION_INDEX_NAME = "index_cool_widget_states_failed_verification"
-    NEEDS_VERIFICATION_INDEX_NAME = "index_cool_widget_states_needs_verification"
-
-    enable_lock_retries!
-
-    def up
-      create_table :cool_widget_states, id: false do |t|
-        t.datetime_with_timezone :verification_started_at
-        t.datetime_with_timezone :verification_retry_at
-        t.datetime_with_timezone :verified_at
-        t.references :cool_widget,
-          primary_key: true,
-          default: nil,
-          index: false,
-          foreign_key: { on_delete: :cascade }
-        t.integer :verification_state, default: 0, limit: 2, null: false
-        t.integer :verification_retry_count, default: 0, limit: 2, null: false
-        t.binary :verification_checksum, using: 'verification_checksum::bytea'
-        t.text :verification_failure, limit: 255
-
-        t.index :verification_state, name: VERIFICATION_STATE_INDEX_NAME
-        t.index :verified_at,
-          where: "(verification_state = 0)",
-          order: { verified_at: 'ASC NULLS FIRST' },
-          name: PENDING_VERIFICATION_INDEX_NAME
-        t.index :verification_retry_at,
-          where: "(verification_state = 3)",
-          order: { verification_retry_at: 'ASC NULLS FIRST' },
-          name: FAILED_VERIFICATION_INDEX_NAME
-        t.index :verification_state,
-          where: "(verification_state = 0 OR verification_state = 3)",
-          name: NEEDS_VERIFICATION_INDEX_NAME
-      end
-    end
-
-    def down
-      drop_table :cool_widget_states
-    end
-  end
-  ```
-
-- [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
-
-- [ ] If `cool_widgets` is a high-traffic table, follow [the database documentation to use `with_lock_retries`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/migration_style_guide.md#when-to-use-the-helper-method)
-
-- [ ] Add the new table to the [database dictionary](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/database/database_dictionary.md) defined in [`db/docs/`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/db/docs):
-
-  ```yaml
-  ---
-  table_name: cool_widget_states
-  description: Separate table for cool widget verification states
-  introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/XXXXX
-  milestone: 'XX.Y'
-  feature_categories:
-   - geo_replication
-  classes:
-   - Geo::CoolWidgetState
-  gitlab_schema: gitlab_main
-  ```
-
-- [ ] Run database migrations:
-
-  ```shell
-  bin/rake db:migrate
-  ```
-
-- [ ] Be sure to commit the relevant changes in `db/structure.sql` and the file under `db/schema_migrations`
-
-That's all of the required database changes.
-
-### Implement Geo support of Cool Widgets behind a feature flag
-
-#### Step 1. Implement replication and verification
-
-- [ ] Add the following lines to the `cool_widget` model to accomplish some important tasks:
-  - Include `::Geo::ReplicableModel` in the `CoolWidget` class, and specify the Replicator class `with_replicator Geo::CoolWidgetReplicator`.
-  - Include the `::Geo::VerifiableModel` concern.
-  - Delegate verification related methods to the `cool_widget_state` model.
-  - For verification, override some scopes to use the `cool_widget_states` table instead of the model table.
-  - Implement the `verification_state_object` method to return the object that holds
-    the verification details
-  - Override some methods to use the `cool_widget_states` table in verification-related queries.
-
-  At this point the `CoolWidget` class should look like this:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  class CoolWidget < ApplicationRecord
-    ...
-    include ::Geo::ReplicableModel
-    include ::Geo::VerifiableModel
-
-    delegate(*::Geo::VerificationState::VERIFICATION_METHODS, to: :cool_widget_state)
-
-    with_replicator Geo::CoolWidgetReplicator
-
-    mount_uploader :file, CoolWidgetUploader
-
-    has_one :cool_widget_state, autosave: false, inverse_of: :cool_widget, class_name: 'Geo::CoolWidgetState'
-
-    after_save :save_verification_details
-
-    # Override the `all` default if not all records can be replicated. For an
-    # example of an existing Model that needs to do this, see
-    # `EE::MergeRequestDiff`.
-    # scope :available_replicables, -> { all }
-
-    scope :available_verifiables, -> { joins(:cool_widget_state) }
-
-    scope :checksummed, -> {
-      joins(:cool_widget_state).where.not(cool_widget_states: { verification_checksum: nil })
-    }
-
-    scope :not_checksummed, -> {
-      joins(:cool_widget_state).where(cool_widget_states: { verification_checksum: nil })
-    }
-
-    scope :with_verification_state, ->(state) {
-      joins(:cool_widget_state)
-        .where(cool_widget_states: { verification_state: verification_state_value(state) })
-    }
-
-    def verification_state_object
-      cool_widget_state
-    end
-    ...
-
-    class_methods do
-      extend ::Gitlab::Utils::Override
-      ...
-
-      # @param primary_key_in [Range, CoolWidget] arg to pass to primary_key_in scope
-      # @return [ActiveRecord::Relation<CoolWidget>] everything that should be synced
-      #         to this node, restricted by primary key
-      def replicables_for_current_secondary(primary_key_in)
-        # This issue template does not help you write this method.
-        #
-        # This method is called only on Geo secondary sites. It is called when
-        # we want to know which records to replicate. This is not easy to automate
-        # because for example:
-        #
-        # * The "selective sync" feature allows admins to choose which namespaces
-        #   to replicate, per secondary site. Most Models are scoped to a
-        #   namespace, but the nature of the relationship to a namespace varies
-        #   between Models.
-        # * The "selective sync" feature allows admins to choose which shards to
-        #   replicate, per secondary site. Repositories are associated with
-        #   shards. Most blob types are not, but Project Uploads are.
-        # * Remote stored replicables are not replicated, by default. But the
-        #   setting `sync_object_storage` enables replication of remote stored
-        #   replicables.
-        #
-        # Search the codebase for examples, and consult a Geo expert if needed.
-      end
-
-      override :verification_state_table_class
-      def verification_state_table_class
-        CoolWidgetState
-      end
-    end
-
-    def cool_widget_state
-      super || build_cool_widget_state
-    end
-
-    ...
-  end
-  ```
-
-- [ ] Implement `CoolWidget.replicables_for_current_secondary` above.
-- [ ] Ensure `CoolWidget.replicables_for_current_secondary` is well-tested. Search the codebase for `replicables_for_current_secondary` to find examples of parameterized table specs. You may need to add more `FactoryBot` traits.
-- [ ] Add the following shared examples to `ee/spec/models/ee/cool_widget_spec.rb`:
-
-  ```ruby
-    include_examples 'a replicable model with a separate table for verification state' do
-      let(:verifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is in `Geo::ReplicableModel.verifiables` scope
-      let(:unverifiable_model_record) { build(:cool_widget) } # add extra params if needed to make sure the record is NOT included in `Geo::ReplicableModel.verifiables` scope
-    end
-  ```
-
-- [ ] Create `ee/app/replicators/geo/cool_widget_replicator.rb`. Implement the `#carrierwave_uploader` method which should return a `CarrierWave::Uploader`, and implement the class method `.model` to return the `CoolWidget` class:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetReplicator < Gitlab::Geo::Replicator
-      include ::Geo::BlobReplicatorStrategy
-      extend ::Gitlab::Utils::Override
-
-      def self.model
-        ::CoolWidget
-      end
-
-      def carrierwave_uploader
-        model_record.file
-      end
-
-      override :verification_feature_flag_enabled?
-      def self.verification_feature_flag_enabled?
-        # We are adding verification at the same time as replication, so we
-        # don't need to toggle verification separately from replication. When
-        # the replication feature flag is off, then verification is also off
-        # (see `VerifiableReplicator.verification_enabled?`)
-        true
-      end
-    end
-  end
-  ```
-
-- [ ] Generate the feature flag definition file by running the feature flag commands and following the command prompts:
-
-  ```shell
-  bin/feature-flag --ee geo_cool_widget_replication --type development --group 'group::geo'
-  ```
-
-- [ ] Add this replicator class to the method `replicator_classes` in
-  `ee/lib/gitlab/geo.rb`:
-
-  ```ruby
-  REPLICATOR_CLASSES = [
-    ::Geo::PackageFileReplicator,
-    ::Geo::CoolWidgetReplicator
-  ]
-  ```
-
-- [ ] Create `ee/spec/replicators/geo/cool_widget_replicator_spec.rb` and perform the necessary setup to define the `model_record` variable for the shared examples:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetReplicator, feature_category: :geo_replication do
-    let(:model_record) { build(:cool_widget) }
-
-    include_examples 'a blob replicator'
-    include_examples 'a verifiable replicator'
-  end
-  ```
-
-- [ ] Create `ee/app/models/geo/cool_widget_registry.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetRegistry < Geo::BaseRegistry
-      include ::Geo::ReplicableRegistry
-      include ::Geo::VerifiableRegistry
-
-      MODEL_CLASS = ::CoolWidget
-      MODEL_FOREIGN_KEY = :cool_widget_id
-
-      belongs_to :cool_widget, class_name: 'CoolWidget'
-    end
-  end
-  ```
-
-- [ ] Update `REGISTRY_CLASSES` in `ee/app/workers/geo/secondary/registry_consistency_worker.rb`.
-- [ ] Add a custom factory name if needed in `def model_class_factory_name` in `ee/spec/support/helpers/ee/geo_helpers.rb`.
-- [ ] Update `it 'creates missing registries for each registry class'` in `ee/spec/workers/geo/secondary/registry_consistency_worker_spec.rb`.
-- [ ] Add `cool_widget_registry` to `ActiveSupport::Inflector.inflections` in `config/initializers_before_autoloader/000_inflections.rb`.
-- [ ] Create `ee/spec/factories/geo/cool_widget_registry.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  FactoryBot.define do
-    factory :geo_cool_widget_registry, class: 'Geo::CoolWidgetRegistry' do
-      cool_widget # This association should have data, like a file or repository
-      state { Geo::CoolWidgetRegistry.state_value(:pending) }
-
-      trait :synced do
-        state { Geo::CoolWidgetRegistry.state_value(:synced) }
-        last_synced_at { 5.days.ago }
-      end
-
-      trait :failed do
-        state { Geo::CoolWidgetRegistry.state_value(:failed) }
-        last_synced_at { 1.day.ago }
-        retry_count { 2 }
-        retry_at { 2.hours.from_now }
-        last_sync_failure { 'Random error' }
-      end
-
-      trait :started do
-        state { Geo::CoolWidgetRegistry.state_value(:started) }
-        last_synced_at { 1.day.ago }
-        retry_count { 0 }
-      end
-
-      trait :verification_succeeded do
-        verification_checksum { 'e079a831cab27bcda7d81cd9b48296d0c3dd92ef' }
-        verification_state { Geo::CoolWidgetRegistry.verification_state_value(:verification_succeeded) }
-        verified_at { 5.days.ago }
-      end
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/models/geo/cool_widget_registry_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetRegistry, :geo, type: :model, feature_category: :geo_replication do
-    let_it_be(:registry) { create(:geo_cool_widget_registry) }
-
-    specify 'factory is valid' do
-      expect(registry).to be_valid
-    end
-
-    include_examples 'a Geo framework registry'
-    include_examples 'a Geo verifiable registry'
-  end
-  ```
-
-- [ ] Add the following to `spec/factories/cool_widgets.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  FactoryBot.modify do
-    factory :cool_widget do
-      trait :verification_succeeded do
-          with_file
-          verification_checksum { 'abc' }
-          verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
-      end
-
-      trait :verification_failed do
-          with_file
-          verification_failure { 'Could not calculate the checksum' }
-          verification_state { CoolWidget.verification_state_value(:verification_failed) }
-      end
-    end
-  end
-  ```
-
-  If there is not an existing factory for the object in `spec/factories/cool_widgets.rb`, wrap the traits in `FactoryBot.create` instead of `FactoryBot.modify`
-
- [ ] Make sure the factory supports the `:remote_store` trait. If not, add something like
-
-  ```ruby
-  trait :remote_store do
-    file_store { CoolWidget::FileUploader::Store::REMOTE }
-  end
-  ```
-- [ ] Make sure the factory also allows setting a `project` attribute. If the model does not have a direct relation to a project, you can use a `transient` attribute. Check out `spec/factories/merge_request_diffs.rb` for an example.
-
-- [ ] Following [the example of Merge Request Diffs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309) add a `Geo::CoolWidgetState` model in `ee/app/models/geo/cool_widget_state.rb`:
-
-  ``` ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetState < ApplicationRecord
-      include ::Geo::VerificationStateDefinition
-
-      self.primary_key = :cool_widget_id
-
-      belongs_to :cool_widget, inverse_of: :cool_widget_state
-
-      validates :verification_failure, length: { maximum: 255 }
-      validates :verification_state, :cool_widget, presence: true
-    end
-  end
-  ```
-
-- [ ] Add a `factory` for `cool_widget_state`, in `ee/spec/factories/geo/cool_widget_states.rb`:
-
-  ``` ruby
-  # frozen_string_literal: true
-
-  FactoryBot.define do
-    factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
-      cool_widget
-
-      trait :checksummed do
-        verification_checksum { 'abc' }
-      end
-
-      trait :checksum_failure do
-        verification_failure { 'Could not calculate the checksum' }
-      end
-    end
-  end
-  ```
-
-- [ ] Add `[:cool_widget, :remote_store]` and `[:geo_cool_widget_state, any]` to `skipped` in `spec/models/factories_spec.rb`
-
-#### Step 2. Implement metrics gathering
-
-Metrics are gathered by `Geo::MetricsUpdateWorker`, persisted in `GeoNodeStatus` for display in the UI, and sent to Prometheus:
-
-- [ ] Add the following fields to Geo Node Status example responses in `doc/api/geo_nodes.md`:
-  - `cool_widgets_count`
-  - `cool_widgets_checksum_total_count`
-  - `cool_widgets_checksummed_count`
-  - `cool_widgets_checksum_failed_count`
-  - `cool_widgets_synced_count`
-  - `cool_widgets_failed_count`
-  - `cool_widgets_registry_count`
-  - `cool_widgets_verification_total_count`
-  - `cool_widgets_verified_count`
-  - `cool_widgets_verification_failed_count`
-  - `cool_widgets_synced_in_percentage`
-  - `cool_widgets_verified_in_percentage`
-- [ ] Add the same fields to `GET /geo_nodes/status` example response in
-  `ee/spec/fixtures/api/schemas/public_api/v4/geo_node_status.json`.
-- [ ] Add the following fields to the `Sidekiq metrics` table in `doc/administration/monitoring/prometheus/gitlab_metrics.md`:
-
-  ```markdown
-  | `geo_cool_widgets` | Gauge | XX.Y | Number of Cool Widgets on primary | `url` |
-  | `geo_cool_widgets_checksum_total` | Gauge | XX.Y | Number of Cool Widgets to checksum on primary | `url` |
-  | `geo_cool_widgets_checksummed` | Gauge | XX.Y | Number of Cool Widgets that successfully calculated the checksum on primary | `url` |
-  | `geo_cool_widgets_checksum_failed` | Gauge | XX.Y | Number of Cool Widgets that failed to calculate the checksum on primary | `url` |
-  | `geo_cool_widgets_synced` | Gauge | XX.Y | Number of syncable Cool Widgets synced on secondary | `url` |
-  | `geo_cool_widgets_failed` | Gauge | XX.Y | Number of syncable Cool Widgets failed to sync on secondary | `url` |
-  | `geo_cool_widgets_registry` | Gauge | XX.Y | Number of Cool Widgets in the registry | `url` |
-  | `geo_cool_widgets_verification_total` | Gauge | XX.Y | Number of Cool Widgets to attempt to verify on secondary | `url` |
-  | `geo_cool_widgets_verified` | Gauge | XX.Y | Number of Cool Widgets successfully verified on secondary | `url` |
-  | `geo_cool_widgets_verification_failed` | Gauge | XX.Y | Number of Cool Widgets that failed verification on secondary | `url` |
-  ```
-- [ ] Run the rake task `geo:dev:ssf_metrics` and commit the changes to `ee/config/metrics/object_schemas/geo_node_usage.json`
-
- Cool Widget replication and verification metrics should now be available in the API, the `Admin > Geo > Sites` view, and Prometheus.
-
-#### Step 3. Implement the GraphQL API
-
-The GraphQL API is used by `Admin > Geo > Replication Details` views, and is directly queryable by administrators.
-
-- [ ] Add a new field to `GeoNodeType` in `ee/app/graphql/types/geo/geo_node_type.rb`:
-
-  ```ruby
-  field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
-        null: true,
-        resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node. '\
-                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
-        alpha: { milestone: '15.5' } # Update the milestone
-  ```
-
-- [ ] Add the new `cool_widget_registries` field name to the `expected_fields` array in `ee/spec/graphql/types/geo/geo_node_type_spec.rb`.
-- [ ] Create `ee/app/graphql/resolvers/geo/cool_widget_registries_resolver.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Resolvers
-    module Geo
-      class CoolWidgetRegistriesResolver < BaseResolver
-        type ::Types::Geo::GeoNodeType.connection_type, null: true
-
-        include RegistriesResolver
-      end
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/graphql/resolvers/geo/cool_widget_registries_resolver_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Resolvers::Geo::CoolWidgetRegistriesResolver, feature_category: :geo_replication do
-    it_behaves_like 'a Geo registries resolver', :geo_cool_widget_registry
-  end
-  ```
-
-- [ ] Create `ee/app/finders/geo/cool_widget_registry_finder.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Geo
-    class CoolWidgetRegistryFinder
-      include FrameworkRegistryFinder
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/finders/geo/cool_widget_registry_finder_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe Geo::CoolWidgetRegistryFinder, feature_category: :geo_replication do
-    it_behaves_like 'a framework registry finder', :geo_cool_widget_registry
-  end
-  ```
-
-- [ ] Create `ee/app/graphql/types/geo/cool_widget_registry_type.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  module Types
-    module Geo
-      # rubocop:disable Graphql/AuthorizeTypes because it is included
-      class CoolWidgetRegistryType < BaseObject
-        graphql_name 'CoolWidgetRegistry'
-
-        include ::Types::Geo::RegistryType
-
-        description 'Represents the Geo replication and verification state of a cool_widget'
-
-        field :cool_widget_id, GraphQL::Types::ID, null: false, description: 'ID of the Cool Widget.'
-      end
-      # rubocop:enable Graphql/AuthorizeTypes
-    end
-  end
-  ```
-
-- [ ] Create `ee/spec/graphql/types/geo/cool_widget_registry_type_spec.rb`:
-
-  ```ruby
-  # frozen_string_literal: true
-
-  require 'spec_helper'
-
-  RSpec.describe GitlabSchema.types['CoolWidgetRegistry'], feature_category: :geo_replication do
-    it_behaves_like 'a Geo registry type'
-
-    it 'has the expected fields (other than those included in RegistryType)' do
-      expected_fields = %i[cool_widget_id]
-
-      expect(described_class).to have_graphql_fields(*expected_fields).at_least
-    end
-  end
-  ```
-
-- [ ] Add integration tests for providing CoolWidget registry data to the frontend via the GraphQL API, by duplicating and modifying the following shared examples in `ee/spec/requests/api/graphql/geo/registries_spec.rb`:
-
-  ```ruby
-  it_behaves_like 'gets registries for', {
-    field_name: 'coolWidgetRegistries',
-    registry_class_name: 'CoolWidgetRegistry',
-    registry_factory: :geo_cool_widget_registry,
-    registry_foreign_key_field_name: 'coolWidgetId'
-  }
-  ```
-
-- [ ] Update the GraphQL reference documentation:
-
-  ```shell
-  bundle exec rake gitlab:graphql:compile_docs
-  ```
-
-Individual Cool Widget replication and verification data should now be available via the GraphQL API.
-
-#### Step 4. Handle batch destroy
-
-If batch destroy logic is implemented for a replicable, then that logic must be "replicated" by Geo secondaries. The easiest way to do this is use `Geo::BatchEventCreateWorker` to bulk insert a delete event for each replicable.
-
-For example, if `FastDestroyAll` is used, then you may be able to [use `begin_fast_destroy` and `finalize_fast_destroy` hooks, like we did for uploads](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69763).
-
-Or if a special service is used to batch delete records and their associated data, then you probably need to [hook into that service, like we did for job artifacts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79530).
-
-As illustrated by the above two examples, batch destroy logic cannot be handled automatically by Geo secondaries without restricting the way other teams perform batch destroys. It is up to you to produce `Geo::BatchEventCreateWorker` attributes before the records are deleted, and then enqueue `Geo::BatchEventCreateWorker` after the records are deleted.
-
-- [ ] Ensure that any batch destroy of this replicable is replicated to secondary sites
-- [ ] Regardless of implementation details, please verify in specs that when the parent object is removed, the new `Geo::Event` records are created:
-
-```ruby
-  describe '#destroy' do
-    subject { create(:cool_widget) }
-
-    context 'when running in a Geo primary node' do
-      let_it_be(:primary) { create(:geo_node, :primary) }
-      let_it_be(:secondary) { create(:geo_node) }
-
-      it 'logs an event to the Geo event log when bulk removal is used', :sidekiq_inline do
-        stub_current_geo_node(primary)
-
-        expect { subject.project.destroy! }.to change(Geo::Event.where(replicable_name: :cool_widget, event_name: :deleted), :count).by(1)
-
-        payload = Geo::Event.where(replicable_name: :cool_widget, event_name: :deleted).last.payload
-
-        expect(payload['model_record_id']).to eq(subject.id)
-        expect(payload['blob_path']).to eq(subject.relative_path)
-        expect(payload['uploader_class']).to eq('CoolWidgetUploader')
-      end
-    end
-  end
-```
-
-### Code Review
-
-When requesting review from database reviewers:
-
-- [ ] Include a comment mentioning that the change is based on a documented template.
-- [ ] `replicables_for_current_secondary` and `available_replicables` may differ per Model. If their queries are new, then add [query plans](https://docs.gitlab.com/ee/development/database_review.html#query-plans) to the MR description. An easy place to gather SQL queries is your GDK's `log/test.log` when running tests of these methods.
-
-### Release Geo support of Cool Widgets
-
-- [ ] In the rollout issue you created when creating the feature flag, modify the Roll Out Steps:
-  - [ ] Cross out any steps related to testing on production GitLab.com, because Geo is not running on production GitLab.com at the moment.
-  - [ ] Add a step to `Test replication and verification of Cool Widgets on a non-GDK-deployment. For example, using GitLab Environment Toolkit`.
-  - [ ] Add a step to `Ping the Geo PM and EM to coordinate testing`. For example, you might add steps to generate Cool Widgets, and then a Geo engineer may take it from there.
-- [ ] In `ee/config/feature_flags/development/geo_cool_widget_replication.yml`, set `default_enabled: true`
-- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `alpha` option for the released type:
-
-  ```ruby
-  field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
-        null: true,
-        resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node. '\
-                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
-        alpha: { milestone: '15.5' } # Update the milestone
-  ```
-
-- [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
-
-- [ ] Add a row for Cool Widgets to the `Data types` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#data-types)
-- [ ] Add a row for Cool Widgets to the `Limitations on replication/verification` table in [Geo data types support](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/administration/geo/replication/datatypes.md#limitations-on-replicationverification). If the row already exists, then update it to show that Replication and Verification is released in the current version.

.gitlab/issue_templates/Global Search - bug.md

@@ -1,30 +0,0 @@
-## Summary
-
-<!-- Summarize the bug encountered concisely. -->
-
-## Steps to reproduce
-
-<!-- Describe how one can reproduce the issue - this is very important. Please use an ordered list. -->
-
-## What is the current *bug* behavior?
-
-<!-- Describe what actually happens. -->
-
-## What is the expected *correct* behavior?
-
-<!-- Describe what you should see instead. -->
-
-## Relevant logs and/or screenshots
-
-<!-- Paste any relevant logs - please use code blocks (```) to format console output, logs, and code
- as it's tough to read otherwise. -->
-
-## Possible fixes
-
-<!-- If you can, link to the line of code that might be responsible for the problem. -->
-
-<!-- Please add a label for the type of bug as per https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification -->
-/label ~"type::bug"
-/label ~"group::global search"
-/label ~"workflow::solution validation" 
-/milestone %Backlog

.gitlab/issue_templates/Global Search - feature.md

@@ -1,13 +0,0 @@
-## Problem to solve
-
-<!-- What problem do we solve? Try to define the who/what/why of the opportunity as a user story. For example, "As a (who), I want (what), so I can (why/value)." -->
-
-## Proposal
-
-<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
-
-<!-- Please add a label for the type of feature as per https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification -->
-/label ~"type::feature"
-/label ~"group::global search"
-/label ~"workflow::solution validation" 
-/milestone %Backlog

.gitlab/issue_templates/Global Search - maintenance.md

@@ -1,11 +0,0 @@
-## Background
-
-## Proposal
-
-<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
-
-<!-- Please add a label for the type of maintenance as per https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification -->
-/label ~"type::maintenance"
-/label ~"group::global search"
-/label ~"workflow::solution validation" 
-/milestone %Backlog

.gitlab/issue_templates/Implementation.md

@@ -1,82 +0,0 @@
-<!--
-Implementation issues are used break-up a large piece of work into small, discrete tasks that can
-move independently through the build workflow steps. They're typically used to populate a Feature
-Epic. Once created, an implementation issue is usually refined in order to populate and review the
-implementation plan and weight.
-Example workflow: https://about.gitlab.com/handbook/engineering/development/threat-management/planning/diagram.html#plan
--->
-
-## Why are we doing this work
-<!--
-A brief explanation of the why, not the what or how. Assume the reader doesn't know the
-background and won't have time to dig-up information from comment threads.
--->
-
-
-## Relevant links
-<!--
-Information that the developer might need to refer to when implementing the issue.
-
-- [Design Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>)
-  - [Design 1](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
-  - [Design 2](https://gitlab.com/gitlab-org/gitlab/-/issues/<id>/designs/<image>.png)
-- [Similar implementation](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/<id>)
--->
-
-
-## Non-functional requirements
-<!--
-Add details for required items and delete others.
--->
-
-- [ ] Documentation:
-- [ ] Feature flag:
-- [ ] Performance:
-- [ ] Testing:
-
-
-## Implementation plan
-<!--
-Steps and the parts of the code that will need to get updated.
-The plan can also call-out responsibilities for other team members or teams and
-can be split into smaller MRs to simplify the code review process.
-
-e.g.:
-
-- MR 1: Part 1
-- [ ] ~frontend Step 1
-- [ ] ~frontend Step 2
-- MR 2: Part 2
-- [ ] ~backend Step 1
-- [ ] ~backend Step 2
-- MR 3: Part 3
-- [ ] ~frontend Step 1
-- [ ] ~frontend Step 2
-
--->
-
-
-<!--
-Workflow and other relevant labels
-
-# ~"group::" ~"Category:" ~"GitLab Ultimate"
-Other settings you might want to include when creating the issue.
-
-# /assign @
-# /epic &
--->
-
-## Verification steps
-<!--
-Add verification steps to help GitLab team members test the implementation. This is particularly useful
-during the MR review and the ~"workflow::verification" step. You may not know exactly what the
-verification steps should be during issue refinement, so you can always come back later to add
-them.
-
-1. Check-out the corresponding branch
-1. ...
-1. Profit!
--->
-
-/label ~"workflow::refinement"
-/milestone %Backlog

.gitlab/issue_templates/InfraDev.md

@@ -1,56 +0,0 @@
-<!--
-Triage of infradev Issues is desired to occur asynchronously.
-For maximum efficiency, please ensure the following, so that your infradev issues can gain maximum traction.
-
-https://about.gitlab.com/handbook/engineering/workflow/#a-guide-to-creating-effective-infradev-issues
--->
-
-## Summary
-<!--
-Clearly state the scope of the problem, and how it affects GitLab.com
--->
-
-
-## Impact
-<!--
-- Quantify the effect of the problem to help ensure that correct prioritization occurs.
-- Include costs to availability. The Incident Budget Explorer dashboard can help here.
-- Include the number of times alerts have fired owing to the problem, how much time was spent dealing with the problem, and how many people were involved.
-- Link to affected incidents, and cross-reference them as related issues.
-- Include screenshots of visualization from Grafana or Kibana.
-- Always include a permalink to the source of the screenshot so that others can investigate further.
--->
-
-
-## Recommendation
-<!--
-Provide a clear, unambiguous, self-contained solution to the problem.
--->
-
-
-## Verification
-<!--
-Provide a method for validating that the original issue still exists.
-
-Having a way of checking validity can save on a great deal of back-and-forth discussion between Infradev Triage participants including Engineering Managers, Directors and Product Managers and make space for other non-resolved issues to get scheduled sooner.
-
-Ideally, provide a link to a Thanos query or an ELK query and clear instructions on how to interpret the results to determine whether the problem is still occurring.
--->
-
-
-<!--
-Workflow and other relevant labels
-
-/label ~"severity::"
-/label ~"priority::"
-/label ~"group::"
-/label ~"devops::"
-
-See also:
-- https://about.gitlab.com/handbook/engineering/quality/issue-triage/#availability
-- https://about.gitlab.com/handbook/product/categories/
-- https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml
--->
-
-/label ~"infradev"
-/label ~"type::bug"

.gitlab/issue_templates/Navigation Proposals.md

@@ -1,26 +0,0 @@
-<!-- This template is used for proposing changes to the left sidebar contextual navigation. This could include additions, removals, or general changes to overall hierarchy.-->
-
-### Proposal 
-
-<!-- Use this section to explain the proposed changes, including details around usage and business drivers. -->
-
-
-#### Other locations that were considered
-
- <!-- Include other design patterns or places you considered for this feature besides navigation. -->
-
-### Checklist
-
-- [ ] Review the handbook page for [navigation changes](https://about.gitlab.com/handbook/product/ux/navigation/#when-to-consider-making-a-change-to-the-navigation)
-- [ ] Add relevant information to the issue description detailing your proposal, including usage and business drivers.
-- [ ] List at least two other places you considered to introduce your feature
-- [ ] Add relevant designs to the Design Management area of the issue
-- [ ] Ensure your UI suggestion align with the [Documentation Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/)
-- [ ] Engage ~"Technical Writing". They can help craft a term that best describes the feature(s) you’re proposing. 
-- [ ] Follow the [product development workflow](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) validation process to ensure you are solving a well understood problem and that the proposed change is understandable and non-disruptive to users. Navigation-specific research is mandatory for additions or when restructuring.
-- [ ] Engage the [Foundations Product Manager](https://about.gitlab.com/handbook/product/categories/#foundations-group) for approval. The Foundations DRI (@cdybenko) will work with UX partners in product design, research, and technical writing, as applicable.
-- [ ] Consider whether you need to [communicate the change somehow](https://design.gitlab.com/patterns/navigation#messaging-changes-to-users), or if you will have an interim period in the UI where your item will live in more than one place.
-- [ ] Ensure engineers are familiar with the [implementation steps for navigation](https://docs.gitlab.com/ee/development/navigation_sidebar.html#navigation-sidebar).
-
-/label ~UX ~"UI text" ~"documentation" ~"Category:Navigation & Settings"  ~navigation ~type::ignore
-/label ~"Nav request::Start"  

.gitlab/issue_templates/Pipeline Authoring Issue Implementation.md

@@ -1,54 +0,0 @@
-<!--
-## Implementation Issue To-Do list 
-(_NOTE: This section can be removed when the issue is ready for creation_)
-- [ ] Ensure that issue title is concise yet descriptive
-- [ ] Add `Frontend :` or `Backend: ` per group [naming conventions](https://about.gitlab.com/handbook/engineering/development/ops/verify/pipeline-authoring/#splitting-issues)
-- [ ] Ensure the issue containing the feature or change proposal and related discussions is linked as related to this implementation issue.
-- [ ] Aside from default labeling, please make sure to include relevant labels for `type::`, `workflow::`, and `~frontend`/`~backend` labeling.
-- [ ] Issues with user-facing changes should include the `~UX` label.
--->
-
-## Summary
-
-## Proposal
-
-## Additional details
-<!--
-_NOTE: If the issue has addressed all of these questions, this separate section can be removed._
--->
-
-Some relevant technical details, if applicable, such as:
-
-- Does this need a ~"feature flag"?
-- Does there need to be an associated ~"instrumentation" issue created related to this work?
-- Is there an example response showing the data structure that should be returned (new endpoints only)?
-- What permissions should be used?
-- Is this EE or CE?
-    - [ ] EE
-    - [ ] CE
-- Additional comments:
-
-## Implementation Table
-
-<!--
-_NOTE: If the issue is not part of an epic, the implementation table can be removed. If it is part of an epic, make sure that the implementation table below mirrors the corresponding epic's implementation table content._
--->
-
-
-| Group | Issue Link |
-| ------ | ------ |
-| ~backend | :point_left: You are here |
-| ~frontend | [#123123](url) |
-
-<!--
-## Documentation 
-
-_NOTE: This section is optional, but can be used for easy access to any relevant documentation URLs._
--->
-
-## Links/References
-
-
-
-
-/label ~"group::pipeline authoring" ~"Category:Pipeline Composition" ~"section::ops" ~"devops::verify" ~"workflow::planning breakdown"

.gitlab/issue_templates/Problem Validation.md

@@ -1,56 +0,0 @@
-<!-- This template is used as a starting point for understanding and articulating a customer problem.
-Learn more about it in the handbook: https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation 
--->
-
-## Problem Statement
-
-<!-- What is the problem we hope to validate? Reference how to write a real customer problem statement at https://productcoalition.com/how-to-write-a-good-customer-problem-statement-a815f80189ba for guidance. -->
-
-## Reach
-
-<!-- Please describe who suffers from this problem. Consider referring to our personas, which are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
-
-<!-- Please also quantify the problem's reach using the following values, considering an aggregate across GitLab.com and self-managed:
-
-10.0 = Impacts the vast majority (~80% or greater) of our users, prospects, or customers.
-6.0 = Impacts a large percentage (~50% to ~80%) of the above.
-3.0 = Significant reach (~25% to ~50%).
-1.5 = Small reach (~5% to ~25%).
-0.5 = Minimal reach (Less than ~5%). -->
-
-## Impact
-
-<!-- How do we positively impact the users above and GitLab's business by solving this problem? Please describe briefly, and provide a numerical assessment:
-
-3.0 = Massive impact
-2.0 = High impact
-1.0 = Medium impact
-0.5 = Low impact
-0.25 = Minimal impact -->
-
-## Confidence
-
-<!-- How do we know this is a problem? Please provide and link to any supporting information (e.g. data, customer verbatims) and use this basis to provide a numerical assessment on our confidence level in this problem's severity:
-
-100% = High confidence
-80% = Medium confidence
-50% = Low confidence -->
-
-## Effort
-
-<!-- How much effort do we think it will be to solve this problem? Please include all counterparts (Product, UX, Engineering, etc) in your assessment and quantify the number of person-months needed to dedicate to the effort.
-
-For example, if the solution will take a product manager, designer, and engineer two weeks of effort - you may quantify this as 1.5 (based on 0.5 months x 3 people). -->
-
-## Definition of Done
-
-- [ ] The problem is well understood by the PM to have an understanding summarized in a RICE score
-- [ ] The problem is well understood by the PM to decide if they want to move forward with this idea or drop it
-- [ ] The problem is well described and detailed with necessary requirements for product design to understand the problem
-- [ ] The problem is well described and detailed with necessary requirements for engineering to understand the problem
-
-## Research Issue
-
-<!-- Link to the Problem Validation Research issue that will be executed by the UX Researcher. https://gitlab.com/gitlab-org/ux-research/ -->
-
-/label ~"workflow::validation backlog" ~devops:: ~category: ~group::

.gitlab/issue_templates/Problem_Validation.md

@@ -0,0 +1,41 @@
+## Problem Statement
+
+<!-- What is the problem we hope to validate and solve? -->
+
+## Reach
+
+<!-- Please describe who suffers from this problem. Consider referring to our personas, which are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ -->
+
+<!-- Please also quantify the problem's reach using the following values, considering an aggregate across GitLab.com and self-managed:
+
+10.0 = Impacts the vast majority (~80% or greater) of our users, prospects, or customers.
+6.0 = Impacts a large percentage (~50% to ~80%) of the above.
+3.0 = Significant reach (~25% to ~50%).
+1.5 = Small reach (~5% to ~25%).
+0.5 = Minimal reach (Less than ~5%). -->
+
+## Impact
+
+<!-- How do we positively impact the users above and GitLab's business by solving this problem? Please describe briefly, and provide a numerical assessment:
+
+3.0 = Massive impact
+2.0 = High impact
+1.0 = Medium impact
+0.5 = Low impact
+0.25 = Minimal impact -->
+
+## Confidence
+
+<!-- How do we know this is a problem? Please provide and link to any supporting information (e.g. data, customer verbatims) and use this basis to provide a numerical assessment on our confidence level in this problem's severity:
+
+100% = High confidence
+80% = Medium confidence
+50% = Low confidence -->
+
+## Effort
+
+<!-- How much effort do we think it will be to solve this problem? Please include all counterparts (Product, UX, Engineering, etc) in your assessment and quantify the number of person-months needed to dedicate to the effort.
+
+For example, if the solution will take a product manager, designer, and engineer two weeks of effort - you may quantify this as 1.5 (based on 0.5 months x 3 people). -->
+
+/label ~"workflow::validation backlog" ~devops:: ~category: ~group::