Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
5471579f3e
commit
b9f31c6df7
|
|
@ -13,7 +13,6 @@ RSpec/AvoidConditionalStatements:
|
|||
- 'ee/spec/features/incidents/incident_details_spec.rb'
|
||||
- 'ee/spec/features/issues/user_sees_empty_state_spec.rb'
|
||||
- 'ee/spec/features/labels_hierarchy_spec.rb'
|
||||
- 'ee/spec/features/profiles/usage_quotas_spec.rb'
|
||||
- 'ee/spec/features/projects/merge_requests/user_approves_merge_request_spec.rb'
|
||||
- 'ee/spec/features/projects/settings/issues_settings_spec.rb'
|
||||
- 'ee/spec/features/registrations/email_confirmation_spec.rb'
|
||||
|
|
|
|||
|
|
@ -105,14 +105,13 @@
|
|||
{"name":"database_cleaner-core","version":"2.0.1","platform":"ruby","checksum":"8646574c32162e59ed7b5258a97a208d3c44551b854e510994f24683865d846c"},
|
||||
{"name":"date","version":"3.3.3","platform":"java","checksum":"584e0a582d1eb2207b4eaac089d8a43f2ca10bea02682f286099642f15c56cce"},
|
||||
{"name":"date","version":"3.3.3","platform":"ruby","checksum":"819792019d5712b748fb15f6dfaaedef14b0328723ef23583ea35f186774530f"},
|
||||
{"name":"dead_end","version":"3.1.1","platform":"ruby","checksum":"1011df7f7c0149be004e11cbbc37747760227c55305cd902fd3c06e1394b2f5b"},
|
||||
{"name":"deb_version","version":"1.0.2","platform":"ruby","checksum":"c21f911d7f2fd1d61219caae254fc078e6598e477fdff8a05a18bec6c72ee713"},
|
||||
{"name":"debug_inspector","version":"1.1.0","platform":"ruby","checksum":"eaa5a2d0195e1d65fb4164e8e7e466cca2e7eb53bc5e608cf12b8bf02c3a8606"},
|
||||
{"name":"deckar01-task_list","version":"2.3.4","platform":"ruby","checksum":"66abdc7e009ea759732bb53867e1ea42de550e2aa03ac30a015cbf42a04c1667"},
|
||||
{"name":"declarative","version":"0.0.20","platform":"ruby","checksum":"8021dd6cb17ab2b61233c56903d3f5a259c5cf43c80ff332d447d395b17d9ff9"},
|
||||
{"name":"declarative_policy","version":"1.1.0","platform":"ruby","checksum":"9af4cf299ade03f2bbf63908f2ce6a117d132fc714c39a128596667fb13331cb"},
|
||||
{"name":"deprecation_toolkit","version":"1.5.1","platform":"ruby","checksum":"a8a1ab1a19ae40ea12560b65010e099f3459ebde390b76621ef0c21c516a04ba"},
|
||||
{"name":"derailed_benchmarks","version":"2.1.2","platform":"ruby","checksum":"eaadc6206ceeb5538ff8f5e04a0023d54ebdd95d04f33e8960fb95a5f189a14f"},
|
||||
{"name":"derailed_benchmarks","version":"2.2.1","platform":"ruby","checksum":"654280664fded41c9cd8fc27fc0fcfaf096023afab90eb4ac1185ba70c5d4439"},
|
||||
{"name":"descendants_tracker","version":"0.0.4","platform":"ruby","checksum":"e9c41dd4cfbb85829a9301ea7e7c48c2a03b26f09319db230e6479ccdc780897"},
|
||||
{"name":"devfile","version":"0.1.1","platform":"aarch64-linux","checksum":"08a932ea915fa1ae10e40cc33d23ac781bec60b30d4bc9c9d4a9ed7f9a93c460"},
|
||||
{"name":"devfile","version":"0.1.1","platform":"arm64-darwin","checksum":"390d9dddda5f5d7d7adc04dfacf949bf2b529942988a2f2baf11e785bd9a7d77"},
|
||||
|
|
@ -641,7 +640,7 @@
|
|||
{"name":"ruby-openai","version":"3.7.0","platform":"ruby","checksum":"fb735d4c055e282ade264cab9864944c05a8a10e0cddd45a0551e8a9851b1850"},
|
||||
{"name":"ruby-progressbar","version":"1.11.0","platform":"ruby","checksum":"cc127db3866dc414ffccbf92928a241e585b3aa2b758a5563e74a6ee0f57d50a"},
|
||||
{"name":"ruby-saml","version":"1.17.0","platform":"ruby","checksum":"0419839ba3312d255e35fe3cc7ae155e4a241fd468796caebcf61164aa01b8a9"},
|
||||
{"name":"ruby-statistics","version":"3.0.0","platform":"ruby","checksum":"610301370346931cb701e3a8d3d3e28eb65681162cae6066c0c11abf20efdc81"},
|
||||
{"name":"ruby-statistics","version":"4.1.0","platform":"ruby","checksum":"7d697abd5dc4e6141d21ecb4165482807564f11bbe154cf1c60a2677b507f2a9"},
|
||||
{"name":"ruby2_keywords","version":"0.0.5","platform":"ruby","checksum":"ffd13740c573b7301cf7a2e61fc857b2a8e3d3aff32545d6f8300d8bae10e3ef"},
|
||||
{"name":"rubyntlm","version":"0.6.3","platform":"ruby","checksum":"5b321456dba3130351f7451f8669f1afa83a0d26fd63cdec285b7b88e667102d"},
|
||||
{"name":"rubypants","version":"0.2.0","platform":"ruby","checksum":"f07e38eac793655a0323fe91946081052341b9e69807026fcf102346589eedee"},
|
||||
|
|
|
|||
17
Gemfile.lock
17
Gemfile.lock
|
|
@ -487,7 +487,6 @@ GEM
|
|||
database_cleaner-core (~> 2.0.0)
|
||||
database_cleaner-core (2.0.1)
|
||||
date (3.3.3)
|
||||
dead_end (3.1.1)
|
||||
deb_version (1.0.2)
|
||||
debug_inspector (1.1.0)
|
||||
deckar01-task_list (2.3.4)
|
||||
|
|
@ -496,17 +495,23 @@ GEM
|
|||
declarative_policy (1.1.0)
|
||||
deprecation_toolkit (1.5.1)
|
||||
activesupport (>= 4.2)
|
||||
derailed_benchmarks (2.1.2)
|
||||
derailed_benchmarks (2.2.1)
|
||||
base64
|
||||
benchmark-ips (~> 2)
|
||||
dead_end
|
||||
get_process_mem (~> 0)
|
||||
bigdecimal
|
||||
drb
|
||||
get_process_mem
|
||||
heapy (~> 0)
|
||||
logger
|
||||
memory_profiler (>= 0, < 2)
|
||||
mini_histogram (>= 0.3.0)
|
||||
mutex_m
|
||||
ostruct
|
||||
rack (>= 1)
|
||||
rack-test
|
||||
rake (> 10, < 14)
|
||||
ruby-statistics (>= 2.1)
|
||||
ruby-statistics (>= 4.0.1)
|
||||
ruby2_keywords
|
||||
thor (>= 0.19, < 2)
|
||||
descendants_tracker (0.0.4)
|
||||
thread_safe (~> 0.3, >= 0.3.1)
|
||||
|
|
@ -1697,7 +1702,7 @@ GEM
|
|||
ruby-saml (1.17.0)
|
||||
nokogiri (>= 1.13.10)
|
||||
rexml
|
||||
ruby-statistics (3.0.0)
|
||||
ruby-statistics (4.1.0)
|
||||
ruby2_keywords (0.0.5)
|
||||
rubyntlm (0.6.3)
|
||||
rubypants (0.2.0)
|
||||
|
|
|
|||
|
|
@ -105,14 +105,13 @@
|
|||
{"name":"database_cleaner-core","version":"2.0.1","platform":"ruby","checksum":"8646574c32162e59ed7b5258a97a208d3c44551b854e510994f24683865d846c"},
|
||||
{"name":"date","version":"3.3.3","platform":"java","checksum":"584e0a582d1eb2207b4eaac089d8a43f2ca10bea02682f286099642f15c56cce"},
|
||||
{"name":"date","version":"3.3.3","platform":"ruby","checksum":"819792019d5712b748fb15f6dfaaedef14b0328723ef23583ea35f186774530f"},
|
||||
{"name":"dead_end","version":"3.1.1","platform":"ruby","checksum":"1011df7f7c0149be004e11cbbc37747760227c55305cd902fd3c06e1394b2f5b"},
|
||||
{"name":"deb_version","version":"1.0.2","platform":"ruby","checksum":"c21f911d7f2fd1d61219caae254fc078e6598e477fdff8a05a18bec6c72ee713"},
|
||||
{"name":"debug_inspector","version":"1.1.0","platform":"ruby","checksum":"eaa5a2d0195e1d65fb4164e8e7e466cca2e7eb53bc5e608cf12b8bf02c3a8606"},
|
||||
{"name":"deckar01-task_list","version":"2.3.4","platform":"ruby","checksum":"66abdc7e009ea759732bb53867e1ea42de550e2aa03ac30a015cbf42a04c1667"},
|
||||
{"name":"declarative","version":"0.0.20","platform":"ruby","checksum":"8021dd6cb17ab2b61233c56903d3f5a259c5cf43c80ff332d447d395b17d9ff9"},
|
||||
{"name":"declarative_policy","version":"1.1.0","platform":"ruby","checksum":"9af4cf299ade03f2bbf63908f2ce6a117d132fc714c39a128596667fb13331cb"},
|
||||
{"name":"deprecation_toolkit","version":"1.5.1","platform":"ruby","checksum":"a8a1ab1a19ae40ea12560b65010e099f3459ebde390b76621ef0c21c516a04ba"},
|
||||
{"name":"derailed_benchmarks","version":"2.1.2","platform":"ruby","checksum":"eaadc6206ceeb5538ff8f5e04a0023d54ebdd95d04f33e8960fb95a5f189a14f"},
|
||||
{"name":"derailed_benchmarks","version":"2.2.1","platform":"ruby","checksum":"654280664fded41c9cd8fc27fc0fcfaf096023afab90eb4ac1185ba70c5d4439"},
|
||||
{"name":"descendants_tracker","version":"0.0.4","platform":"ruby","checksum":"e9c41dd4cfbb85829a9301ea7e7c48c2a03b26f09319db230e6479ccdc780897"},
|
||||
{"name":"devfile","version":"0.1.1","platform":"aarch64-linux","checksum":"08a932ea915fa1ae10e40cc33d23ac781bec60b30d4bc9c9d4a9ed7f9a93c460"},
|
||||
{"name":"devfile","version":"0.1.1","platform":"arm64-darwin","checksum":"390d9dddda5f5d7d7adc04dfacf949bf2b529942988a2f2baf11e785bd9a7d77"},
|
||||
|
|
@ -651,7 +650,7 @@
|
|||
{"name":"ruby-openai","version":"3.7.0","platform":"ruby","checksum":"fb735d4c055e282ade264cab9864944c05a8a10e0cddd45a0551e8a9851b1850"},
|
||||
{"name":"ruby-progressbar","version":"1.11.0","platform":"ruby","checksum":"cc127db3866dc414ffccbf92928a241e585b3aa2b758a5563e74a6ee0f57d50a"},
|
||||
{"name":"ruby-saml","version":"1.17.0","platform":"ruby","checksum":"0419839ba3312d255e35fe3cc7ae155e4a241fd468796caebcf61164aa01b8a9"},
|
||||
{"name":"ruby-statistics","version":"3.0.0","platform":"ruby","checksum":"610301370346931cb701e3a8d3d3e28eb65681162cae6066c0c11abf20efdc81"},
|
||||
{"name":"ruby-statistics","version":"4.1.0","platform":"ruby","checksum":"7d697abd5dc4e6141d21ecb4165482807564f11bbe154cf1c60a2677b507f2a9"},
|
||||
{"name":"ruby2_keywords","version":"0.0.5","platform":"ruby","checksum":"ffd13740c573b7301cf7a2e61fc857b2a8e3d3aff32545d6f8300d8bae10e3ef"},
|
||||
{"name":"rubyntlm","version":"0.6.3","platform":"ruby","checksum":"5b321456dba3130351f7451f8669f1afa83a0d26fd63cdec285b7b88e667102d"},
|
||||
{"name":"rubypants","version":"0.2.0","platform":"ruby","checksum":"f07e38eac793655a0323fe91946081052341b9e69807026fcf102346589eedee"},
|
||||
|
|
|
|||
|
|
@ -499,7 +499,6 @@ GEM
|
|||
database_cleaner-core (~> 2.0.0)
|
||||
database_cleaner-core (2.0.1)
|
||||
date (3.3.3)
|
||||
dead_end (3.1.1)
|
||||
deb_version (1.0.2)
|
||||
debug_inspector (1.1.0)
|
||||
deckar01-task_list (2.3.4)
|
||||
|
|
@ -508,17 +507,23 @@ GEM
|
|||
declarative_policy (1.1.0)
|
||||
deprecation_toolkit (1.5.1)
|
||||
activesupport (>= 4.2)
|
||||
derailed_benchmarks (2.1.2)
|
||||
derailed_benchmarks (2.2.1)
|
||||
base64
|
||||
benchmark-ips (~> 2)
|
||||
dead_end
|
||||
get_process_mem (~> 0)
|
||||
bigdecimal
|
||||
drb
|
||||
get_process_mem
|
||||
heapy (~> 0)
|
||||
logger
|
||||
memory_profiler (>= 0, < 2)
|
||||
mini_histogram (>= 0.3.0)
|
||||
mutex_m
|
||||
ostruct
|
||||
rack (>= 1)
|
||||
rack-test
|
||||
rake (> 10, < 14)
|
||||
ruby-statistics (>= 2.1)
|
||||
ruby-statistics (>= 4.0.1)
|
||||
ruby2_keywords
|
||||
thor (>= 0.19, < 2)
|
||||
descendants_tracker (0.0.4)
|
||||
thread_safe (~> 0.3, >= 0.3.1)
|
||||
|
|
@ -1729,7 +1734,7 @@ GEM
|
|||
ruby-saml (1.17.0)
|
||||
nokogiri (>= 1.13.10)
|
||||
rexml
|
||||
ruby-statistics (3.0.0)
|
||||
ruby-statistics (4.1.0)
|
||||
ruby2_keywords (0.0.5)
|
||||
rubyntlm (0.6.3)
|
||||
rubypants (0.2.0)
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ module Types
|
|||
field :id, Types::GlobalIDType[::AbuseReport],
|
||||
null: false, description: 'Global ID of the abuse report.'
|
||||
|
||||
field :labels, ::Types::LabelType.connection_type,
|
||||
field :labels, ::Types::AntiAbuse::AbuseReportLabelType.connection_type,
|
||||
null: true, description: 'Labels of the abuse report.'
|
||||
|
||||
field :discussions, ::Types::Notes::AbuseReport::DiscussionType.connection_type,
|
||||
|
|
|
|||
|
|
@ -11,6 +11,10 @@ module Types
|
|||
|
||||
authorize :read_label
|
||||
|
||||
field :id, Types::GlobalIDType[::AntiAbuse::Reports::Label],
|
||||
null: false,
|
||||
description: 'Global ID of the abuse report label.'
|
||||
|
||||
markdown_field :description_html, null: true
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -12,8 +12,6 @@ module Types
|
|||
GraphQL::Types::String,
|
||||
null: true,
|
||||
description: 'Description of the label (Markdown rendered as HTML for caching).'
|
||||
field :id, GraphQL::Types::ID, null: false,
|
||||
description: 'Label ID.'
|
||||
field :text_color, GraphQL::Types::String, null: false,
|
||||
description: 'Text color of the label.'
|
||||
field :title, GraphQL::Types::String, null: false,
|
||||
|
|
|
|||
|
|
@ -10,6 +10,10 @@ module Types
|
|||
|
||||
authorize :read_label
|
||||
|
||||
field :id, Types::GlobalIDType[::Label],
|
||||
null: false,
|
||||
description: 'Global ID of the label.'
|
||||
|
||||
field :lock_on_merge, GraphQL::Types::Boolean, null: false,
|
||||
description: 'Indicates this label is locked for merge requests ' \
|
||||
'that have been merged.'
|
||||
|
|
|
|||
|
|
@ -223,7 +223,7 @@ module Types
|
|||
description: 'Find an abuse report.',
|
||||
resolver: Resolvers::AbuseReportResolver
|
||||
|
||||
field :abuse_report_labels, ::Types::LabelType.connection_type,
|
||||
field :abuse_report_labels, ::Types::AntiAbuse::AbuseReportLabelType.connection_type,
|
||||
null: true,
|
||||
experiment: { milestone: '16.3' },
|
||||
description: 'Abuse report labels.',
|
||||
|
|
|
|||
|
|
@ -11,4 +11,4 @@
|
|||
stage: Foundations
|
||||
tiers: Premium
|
||||
issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/337993
|
||||
documentation_url: https://docs.gitlab.com/ee/administration/index.html
|
||||
documentation_url: https://docs.gitlab.com/ee/administration/
|
||||
|
|
|
|||
|
|
@ -0,0 +1,20 @@
|
|||
- title: "Major update of the Prometheus subchart"
|
||||
removal_milestone: "18.0"
|
||||
announcement_milestone: "17.9"
|
||||
breaking_change: true
|
||||
reporter: clemensbeck
|
||||
stage: systems
|
||||
issue_url: https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5927
|
||||
impact: small
|
||||
scope: instance
|
||||
resolution_role: Admin
|
||||
manual_task: true
|
||||
body: |
|
||||
With GitLab 18.0 and GitLab chart 9.0, the Prometheus subchart will be updated from 15.3 to 27.3.
|
||||
Along with this update, Prometheus 3 will be shipped by default.
|
||||
|
||||
Manual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter or
|
||||
Pushgateway enabled, you will also need to update your Helm values.
|
||||
|
||||
Please refer to the [migration guide](https://docs.gitlab.com/charts/releases/9_0.html#prometheus-upgrade)
|
||||
for more information.
|
||||
|
|
@ -11,7 +11,7 @@
|
|||
resolution_role: Developer
|
||||
manual_task: true
|
||||
body: | # (required) Don't change this line.
|
||||
The SpotBugs [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/index.html#supported-languages-and-frameworks)
|
||||
The SpotBugs [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)
|
||||
can perform a build when the artifacts to be scanned aren't present. While this usually works well for simple projects, it can fail on more complex builds.
|
||||
|
||||
From GitLab 18.0, to resolve SpotBugs analyzer build failures, you should:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: substitution
|
||||
message: "Use the US spelling '%s' instead of the British '%s'."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#language
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#language
|
||||
vocab: false
|
||||
level: error
|
||||
action:
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Instead of '%s' for the code block, use yaml, ruby, plaintext, markdown, javascript, shell, go, python, dockerfile, or typescript."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#code-blocks
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#code-blocks
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Refactor the section or page to avoid headings greater than H5."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#heading-levels-in-markdown
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#heading-levels-in-markdown
|
||||
vocab: false
|
||||
level: suggestion
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ extends: existence
|
|||
message: "Improve SEO and accessibility by rewriting the link text for '%s'."
|
||||
level: warning
|
||||
ignorecase: true
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#text-for-links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#text-for-links
|
||||
vocab: false
|
||||
scope: raw
|
||||
nonword: true
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Put the full link on one line, even if the link is very long."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ message: "Use standard single quotes or double quotes only. Do not use left or r
|
|||
vocab: false
|
||||
level: warning
|
||||
ignorecase: true
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#punctuation
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#punctuation
|
||||
scope: raw
|
||||
raw:
|
||||
- '[‘’“”]'
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ message: "Use standard spaces only. Do not use no-break or zero width spaces."
|
|||
vocab: false
|
||||
level: error
|
||||
ignorecase: true
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#punctuation
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#punctuation
|
||||
scope: raw
|
||||
raw:
|
||||
- '[ ]'
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Use a comma before the last 'and' or 'or' in a list of four or more items."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#punctuation
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#punctuation
|
||||
vocab: false
|
||||
level: warning
|
||||
raw:
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@
|
|||
extends: occurrence
|
||||
message: "Improve readability by using fewer than 25 words in this sentence."
|
||||
scope: sentence
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#language
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#language
|
||||
level: suggestion
|
||||
max: 25
|
||||
token: \b(\w+)\b
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Use exactly one space between sentences and clauses. Check '%s' for spacing problems."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#punctuation
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#punctuation
|
||||
vocab: false
|
||||
level: error
|
||||
nonword: true
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Update the format of the '%s' alert box. View the style guide for details."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#alert-boxes
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#alert-boxes
|
||||
vocab: false
|
||||
level: error
|
||||
nonword: true
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Review this image. It might be out of date."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#anchor-links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#anchor-links
|
||||
vocab: false
|
||||
level: suggestion
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Use lowercase for the anchor link."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#anchor-links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#anchor-links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Link to a file and use the .md file extension instead of .html."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Edit the link so it does not start with '/' or './'."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Use full URLs for files outside the docs directory."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Put this link inline with the rest of the text."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
nonword: true
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Use a relative link instead of a URL, and ensure the file name ends in .md and not .html."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Do not use double slashes '//' or '../doc' in the link path"
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#links
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#links
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@
|
|||
# For a list of all options, see https://vale.sh/docs/topics/styles/
|
||||
extends: existence
|
||||
message: "Do not include tabs query parameters in links."
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#tabs
|
||||
link: https://docs.gitlab.com/ee/development/documentation/styleguide/#tabs
|
||||
vocab: false
|
||||
level: error
|
||||
scope: raw
|
||||
|
|
|
|||
|
|
@ -300,7 +300,7 @@ new bucket.
|
|||
[Using a non-packaged PostgreSQL database management server](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server).
|
||||
|
||||
- For Helm chart (Kubernetes) installations, follow
|
||||
[Configure the GitLab chart with an external database](https://docs.gitlab.com/charts/advanced/external-db/index.html).
|
||||
[Configure the GitLab chart with an external database](https://docs.gitlab.com/charts/advanced/external-db/).
|
||||
|
||||
1. Before moving on, wait until the new RDS instance is created and ready to use.
|
||||
|
||||
|
|
@ -313,7 +313,7 @@ new bucket.
|
|||
[Using a non-packaged PostgreSQL database management server](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server).
|
||||
|
||||
- For Helm chart (Kubernetes) installations, follow
|
||||
[Configure the GitLab chart with an external database](https://docs.gitlab.com/charts/advanced/external-db/index.html).
|
||||
[Configure the GitLab chart with an external database](https://docs.gitlab.com/charts/advanced/external-db/).
|
||||
|
||||
1. Before moving on, wait until the Cloud SQL instance is ready to use.
|
||||
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ processing is done in a background worker and requires **no downtime**.
|
|||
|
||||
::EndTabs
|
||||
|
||||
1. If [Geo](../geo/_index.md) is enabled, [reverify all job artifacts](../geo/replication/troubleshooting/synchronization_verification.md#reverify-all-components-or-any-ssf-data-type-which-supports-verification).
|
||||
1. If [Geo](../geo/_index.md) is enabled, [reverify all job artifacts](../geo/replication/troubleshooting/synchronization_verification.md#reverify-one-component-on-all-sites).
|
||||
|
||||
In some cases, you need to run the [orphan artifact file cleanup Rake task](../../raketasks/cleanup.md#remove-orphan-artifact-files)
|
||||
to clean up orphaned artifacts.
|
||||
|
|
|
|||
|
|
@ -344,7 +344,7 @@ of the backfill.
|
|||
|
||||
### Runners
|
||||
|
||||
- In addition to our standard best practices for deploying a [fleet of runners](https://docs.gitlab.com/runner/fleet_scaling/index.html), runners can also be configured to connect to Geo secondaries to spread out job load. See how to [register runners against secondaries](secondary_proxy/runners.md).
|
||||
- In addition to our standard best practices for deploying a [fleet of runners](https://docs.gitlab.com/runner/fleet_scaling/), runners can also be configured to connect to Geo secondaries to spread out job load. See how to [register runners against secondaries](secondary_proxy/runners.md).
|
||||
- See also how to handle [Disaster Recovery with runners](disaster_recovery/planned_failover.md#runner-failover).
|
||||
|
||||
### Upgrading Geo
|
||||
|
|
|
|||
|
|
@ -276,9 +276,9 @@ changing Git remotes and API URLs.
|
|||
|
||||
1. Update the **secondary**'s SSL certificate:
|
||||
|
||||
- If you use the [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration),
|
||||
- If you use the [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl/#enable-the-lets-encrypt-integration),
|
||||
the certificate updates automatically.
|
||||
- If you had [manually set up](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-https-manually),
|
||||
- If you had [manually set up](https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually),
|
||||
the **secondary**'s certificate, copy the certificate from the **primary** to the **secondary**.
|
||||
If you don't have access to the **primary**, issue a new certificate and make sure it contains
|
||||
both the **primary** and **secondary** URLs in the subject alternative names. You can check with:
|
||||
|
|
|
|||
|
|
@ -277,12 +277,12 @@ You can safely skip this step if:
|
|||
|
||||
### Custom or self-signed certificate for inbound connections
|
||||
|
||||
If your GitLab Geo **primary** site uses a custom or [self-signed certificate to secure inbound HTTPS connections](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates), this can be either a single-domain or multi-domain certificate.
|
||||
If your GitLab Geo **primary** site uses a custom or [self-signed certificate to secure inbound HTTPS connections](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates), this can be either a single-domain or multi-domain certificate.
|
||||
|
||||
Install the correct certificate based on your certificate type:
|
||||
|
||||
- **Multi-domain certificate** that includes both primary and secondary site domains: Install the certificate at `/etc/gitlab/ssl` on all **Rails, Sidekiq, and Gitaly** nodes in the **secondary** site.
|
||||
- **Single-domain certificate** where the certificates are specific to each Geo site domain: Generate a valid certificate for your **secondary** site's domain and install it at `/etc/gitlab/ssl` following [these instructions](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) on all **Rails, Sidekiq, and Gitaly** nodes in the **secondary** site.
|
||||
- **Single-domain certificate** where the certificates are specific to each Geo site domain: Generate a valid certificate for your **secondary** site's domain and install it at `/etc/gitlab/ssl` following [these instructions](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) on all **Rails, Sidekiq, and Gitaly** nodes in the **secondary** site.
|
||||
|
||||
### Connecting to external services that use custom certificates
|
||||
|
||||
|
|
|
|||
|
|
@ -437,7 +437,7 @@ Geo finds the current Puma or Sidekiq node's Geo [site](../../glossary.md) name
|
|||
1. Get the "Geo node name" (there is
|
||||
[an issue to rename the settings to "Geo site name"](https://gitlab.com/gitlab-org/gitlab/-/issues/335944)):
|
||||
- Linux package: get the `gitlab_rails['geo_node_name']` setting.
|
||||
- GitLab Helm charts: get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/index.html)).
|
||||
- GitLab Helm charts: get the `global.geo.nodeName` setting (see [Charts with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/)).
|
||||
1. If that is not defined, then get the `external_url` setting.
|
||||
|
||||
This name is used to look up the Geo site with the same **Name** in the **Geo Sites**
|
||||
|
|
|
|||
|
|
@ -17,9 +17,171 @@ If you notice replication or verification failures in `Admin > Geo > Sites` or t
|
|||
|
||||
## Manually retry replication or verification
|
||||
|
||||
A Geo data type is a specific class of data that is required by one or more GitLab features to store relevant information and is replicated by Geo to secondary sites.
|
||||
In [Rails console](../../../operations/rails_console.md#starting-a-rails-console-session) in a
|
||||
secondary Geo site, you can:
|
||||
|
||||
### Geo data type classes
|
||||
- [Manually resync and reverify individual components](#resync-and-reverify-individual-components)
|
||||
- [Manually resync and reverify multiple components](#resync-and-reverify-multiple-components)
|
||||
|
||||
### Resync and reverify individual components
|
||||
|
||||
[You can force a resync and reverify individual items](https://gitlab.com/gitlab-org/gitlab/-/issues/364727)
|
||||
for all component types managed by the
|
||||
[self-service framework](../../../../development/geo/framework.md) using the UI. On the secondary
|
||||
site, visit **Admin > Geo > Replication**.
|
||||
|
||||
However, if this doesn't work, you can perform the same action using the Rails console. The
|
||||
following sections describe how to use internal application commands in the
|
||||
[Rails console](../../../operations/rails_console.md#starting-a-rails-console-session) to cause
|
||||
replication or verification for individual records synchronously or asynchronously.
|
||||
|
||||
#### Obtaining a Replicator instance
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions.
|
||||
Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
Before you can perform any sync or verify operations, you need to obtain a Replicator instance.
|
||||
|
||||
First, [start a Rails console session](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
in a **primary** or **secondary** site, depending on what you want to do.
|
||||
|
||||
**Primary** site:
|
||||
|
||||
- You can checksum a resource
|
||||
|
||||
**Secondary** site:
|
||||
|
||||
- You can sync a resource
|
||||
- You can checksum a resource and verify that checksum against the primary site's checksum
|
||||
|
||||
Next, run one of the following snippets to get a Replicator instance.
|
||||
|
||||
##### Given a model record's ID
|
||||
|
||||
- Replace `123` with the actual ID.
|
||||
- Replace `Packages::PackageFile` with any of the
|
||||
[Geo data type Model classes](#geo-data-type-model-classes).
|
||||
|
||||
```ruby
|
||||
model_record = Packages::PackageFile.find_by(id: 123)
|
||||
replicator = model_record.replicator
|
||||
```
|
||||
|
||||
##### Given a registry record's ID
|
||||
|
||||
- Replace `432` with the actual ID. Note that a Registry record may or may not have the same ID
|
||||
value as the Model record that it tracks.
|
||||
- Replace `Geo::PackageFileRegistry` with any of the [Geo Registry classes](#geo-registry-classes).
|
||||
|
||||
In a secondary Geo site:
|
||||
|
||||
```ruby
|
||||
registry_record = Geo::PackageFileRegistry.find_by(id: 432)
|
||||
replicator = registry_record.replicator
|
||||
```
|
||||
|
||||
##### Given an error message in a Registry record's `last_sync_failure`
|
||||
|
||||
- Replace `Geo::PackageFileRegistry` with any of the [Geo Registry classes](#geo-registry-classes).
|
||||
- Replace `error message here` with the actual error message.
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find_by("last_sync_failure LIKE '%error message here%'")
|
||||
replicator = registry.replicator
|
||||
```
|
||||
|
||||
##### Given an error message in a Registry record's `verification_failure`
|
||||
|
||||
- Replace `Geo::PackageFileRegistry` with any of the [Geo Registry classes](#geo-registry-classes).
|
||||
- Replace `error message here` with the actual error message.
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find_by("verification_failure LIKE '%error message here%'")
|
||||
replicator = registry.replicator
|
||||
```
|
||||
|
||||
#### Performing operations with a Replicator instance
|
||||
|
||||
After you have a Replicator instance stored in a `replicator` variable, you can perform many
|
||||
operations:
|
||||
|
||||
##### Sync in the console
|
||||
|
||||
This snippet only works in a **secondary** site.
|
||||
|
||||
This executes the sync code synchronously in the console, so you can observe how long it takes to
|
||||
sync a resource, or view a full error backtrace.
|
||||
|
||||
```ruby
|
||||
replicator.sync
|
||||
```
|
||||
|
||||
Optionally, make the log level of the console more verbose than the configured log level, and then
|
||||
perform a sync:
|
||||
|
||||
```ruby
|
||||
Rails.logger.level = :debug
|
||||
```
|
||||
|
||||
##### Checksum or verify in the console
|
||||
|
||||
This snippet works in any **primary** or **secondary** site.
|
||||
|
||||
In a **primary** site, it checksums the resource and stores the result in the main GitLab
|
||||
database. In a **secondary** site, it checksums the resource, compares it against the checksum in
|
||||
the main GitLab database (generated by the **primary** site), and stores the result in the Geo
|
||||
Tracking database.
|
||||
|
||||
This executes the checksum and verification code synchronously in the console, so you can observe
|
||||
how long it takes, or view a full error backtrace.
|
||||
|
||||
```ruby
|
||||
replicator.verify
|
||||
```
|
||||
|
||||
##### Sync in a Sidekiq job
|
||||
|
||||
This snippet only works in a **secondary** site.
|
||||
|
||||
It enqueues a job for Sidekiq to perform a [sync](#sync-in-the-console) of the resource.
|
||||
|
||||
```ruby
|
||||
replicator.enqueue_sync
|
||||
```
|
||||
|
||||
##### Verify in a Sidekiq job
|
||||
|
||||
This snippet works in any **primary** or **secondary** site.
|
||||
|
||||
It enqueues a job for Sidekiq to perform a
|
||||
[checksum or verify](#checksum-or-verify-in-the-console) of the resource.
|
||||
|
||||
```ruby
|
||||
replicator.verify_async
|
||||
```
|
||||
|
||||
##### Get a model record
|
||||
|
||||
This snippet works in any **primary** or **secondary** site.
|
||||
|
||||
```ruby
|
||||
replicator.model_record
|
||||
```
|
||||
|
||||
##### Get a registry record
|
||||
|
||||
This snippet only works in a **secondary** site because registry tables are stored in the Geo
|
||||
Tracking DB.
|
||||
|
||||
```ruby
|
||||
replicator.registry
|
||||
```
|
||||
|
||||
#### Geo data type Model classes
|
||||
|
||||
A Geo data type is a specific class of data that is required by one or more GitLab features to store
|
||||
relevant data and is replicated by Geo to secondary sites.
|
||||
|
||||
- **Blob types:**
|
||||
- `Ci::JobArtifact`
|
||||
|
|
@ -42,165 +204,109 @@ A Geo data type is a specific class of data that is required by one or more GitL
|
|||
- **Other types:**
|
||||
- `ContainerRepository`
|
||||
|
||||
The main kinds of classes are Registry, Model, and Replicator. If you have an instance of one of these classes, you can get the others. The Registry and Model mostly manage PostgreSQL DB state. The Replicator knows how to replicate/verify (or it can call a service to do it):
|
||||
The main kinds of classes are Registry, Model, and Replicator. If you have an instance of one of
|
||||
these classes, you can get the others. The Registry and Model mostly manage PostgreSQL DB state. The
|
||||
Replicator knows how to replicate or verify the non-PostgreSQL data (file/Git repository/Container
|
||||
repository).
|
||||
|
||||
```ruby
|
||||
model_record = Packages::PackageFile.last
|
||||
model_record.replicator.registry.replicator.model_record # just showing that these methods exist
|
||||
```
|
||||
|
||||
With all this information, you can:
|
||||
|
||||
- [Manually resync and reverify individual components](#resync-and-reverify-individual-components)
|
||||
- [Manually resync and reverify multiple components](#resync-and-reverify-multiple-components)
|
||||
|
||||
### Resync and reverify individual components
|
||||
|
||||
[You can force a resync and reverify individual items](https://gitlab.com/gitlab-org/gitlab/-/issues/364727)
|
||||
for all component types managed by the [self-service framework](../../../../development/geo/framework.md) using the UI.
|
||||
On the secondary site, visit **Admin > Geo > Replication**.
|
||||
|
||||
However, if this doesn't work, you can perform the same action using the Rails
|
||||
console. The following sections describe how to use internal application
|
||||
commands in the Rails console to cause replication or verification for
|
||||
individual records synchronously or asynchronously.
|
||||
|
||||
### Geo registry table models
|
||||
#### Geo Registry classes
|
||||
|
||||
In the context of GitLab Geo, a **registry record** refers to registry tables in
|
||||
the Geo tracking database. Each record tracks a single replicable in the main
|
||||
GitLab database, such as an LFS file, or a project Git repository. The Rails
|
||||
models that correspond to Geo registry tables that can be queried are:
|
||||
|
||||
- `Geo::CiSecureFileRegistry`
|
||||
- `Geo::ContainerRepositoryRegistry`
|
||||
- `Geo::DependencyProxyBlobRegistry`
|
||||
- `Geo::DependencyProxyManifestRegistry`
|
||||
- `Geo::JobArtifactRegistry`
|
||||
- `Geo::LfsObjectRegistry`
|
||||
- `Geo::MergeRequestDiffRegistry`
|
||||
- `Geo::PackageFileRegistry`
|
||||
- `Geo::PagesDeploymentRegistry`
|
||||
- `Geo::PipelineArtifactRegistry`
|
||||
- `Geo::ProjectWikiRepositoryRegistry`
|
||||
- `Geo::SnippetRepositoryRegistry`
|
||||
- `Geo::TerraformStateVersionRegistry`
|
||||
- `Geo::UploadRegistry`
|
||||
|
||||
You can use Rails to perform basic troubleshooting. Troubleshooting steps vary
|
||||
depending on the object type.
|
||||
|
||||
#### For blob types
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
[Start a Rails console session](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
on a **secondary site**.
|
||||
|
||||
Using the `Packages::PackageFile` component as an example:
|
||||
|
||||
- Find registry records that failed to sync:
|
||||
|
||||
```ruby
|
||||
Geo::PackageFileRegistry.failed
|
||||
```
|
||||
|
||||
- Find registry records that are missing on the primary site:
|
||||
|
||||
```ruby
|
||||
Geo::PackageFileRegistry.where(last_sync_failure: 'The file is missing on the Geo primary site')
|
||||
```
|
||||
|
||||
- Resync a package file, synchronously, given an ID:
|
||||
|
||||
```ruby
|
||||
model_record = Packages::PackageFile.find(<id>)
|
||||
model_record.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a package file, synchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a package file, asynchronously, given a registry ID.
|
||||
Since GitLab 16.2, a component can be asynchronously replicated as follows:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.enqueue_sync
|
||||
```
|
||||
|
||||
- Reverify a package file, asynchronously, given a registry ID.
|
||||
Since GitLab 16.2, a component can be asynchronously reverified as follows:
|
||||
|
||||
```ruby
|
||||
registry = Geo::PackageFileRegistry.find(<registry_id>)
|
||||
registry.replicator.verify_async
|
||||
```
|
||||
|
||||
#### For repository types
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
[Start a Rails console session](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
on a **secondary site**.
|
||||
|
||||
Using the `SnippetRepository` component as an example:
|
||||
|
||||
- Resync a snippet repository, synchronously, given an ID:
|
||||
|
||||
```ruby
|
||||
model_record = Geo::SnippetRepositoryRegistry.find(<id>)
|
||||
model_record.replicator.sync
|
||||
```
|
||||
|
||||
- Resync a snippet repository, synchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
|
||||
registry.replicator.sync
|
||||
```
|
||||
|
||||
- Since GitLab 16.2, a component can be asynchronously replicated. Resync a
|
||||
snippet repository, asynchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
|
||||
registry.replicator.enqueue_sync
|
||||
```
|
||||
|
||||
- Since GitLab 16.2, a component can be asynchronously reverified. Reverify a
|
||||
snippet repository, asynchronously, given a registry ID:
|
||||
|
||||
```ruby
|
||||
registry = Geo::SnippetRepositoryRegistry.find(<registry_id>)
|
||||
registry.replicator.verify_async
|
||||
```
|
||||
- **Blob types:**
|
||||
- `Geo::CiSecureFileRegistry`
|
||||
- `Geo::DependencyProxyBlobRegistry`
|
||||
- `Geo::DependencyProxyManifestRegistry`
|
||||
- `Geo::JobArtifactRegistry`
|
||||
- `Geo::LfsObjectRegistry`
|
||||
- `Geo::MergeRequestDiffRegistry`
|
||||
- `Geo::PackageFileRegistry`
|
||||
- `Geo::PagesDeploymentRegistry`
|
||||
- `Geo::PipelineArtifactRegistry`
|
||||
- `Geo::ProjectWikiRepositoryRegistry`
|
||||
- `Geo::SnippetRepositoryRegistry`
|
||||
- `Geo::TerraformStateVersionRegistry`
|
||||
- `Geo::UploadRegistry`
|
||||
- **Git Repository types:**
|
||||
- `Geo::DesignManagementRepositoryRegistry`
|
||||
- `Geo::ProjectRepositoryRegistry`
|
||||
- `Geo::ProjectWikiRepositoryRegistry`
|
||||
- `Geo::SnippetRepositoryRegistry`
|
||||
- `Geo::GroupWikiRepositoryRegistry`
|
||||
- **Other types:**
|
||||
- `Geo::ContainerRepositoryRegistry`
|
||||
|
||||
### Resync and reverify multiple components
|
||||
|
||||
> - Bulk resync and reverify [added](https://gitlab.com/gitlab-org/gitlab/-/issues/364729) in GitLab 16.5.
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions.
|
||||
Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
The following sections describe how to use internal application commands in the [Rails console](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
to cause bulk replication or verification.
|
||||
The following sections describe how to use internal application commands in the
|
||||
[Rails console](../../../operations/rails_console.md#starting-a-rails-console-session) to cause bulk
|
||||
replication or verification.
|
||||
|
||||
#### Reverify all components (or any SSF data type which supports verification)
|
||||
#### Resync all resources of one component
|
||||
|
||||
You can reverify any [data type](#geo-data-type-classes) that supports verification from the Rails console.
|
||||
You can schedule a full resync of all resources of one component from the UI:
|
||||
|
||||
For example, to reverify the `Upload` class:
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
1. Select **Geo > Sites**.
|
||||
1. Under **Replication details**, select the desired component.
|
||||
1. Select **Resync all**.
|
||||
|
||||
1. SSH into a GitLab Rails node in the primary Geo site.
|
||||
Alternatively,
|
||||
[start a Rails console session](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
**on the secondary Geo site** to gather more information, or execute these operations manually using
|
||||
the snippets below.
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions.
|
||||
Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
##### Sync all resources of one component that failed to sync
|
||||
|
||||
The following script:
|
||||
|
||||
- Loops over all failed repositories.
|
||||
- Displays the Geo sync and verification metadata, including the reasons for the last failure.
|
||||
- Attempts to resync the repository.
|
||||
- Reports back if a failure occurs, and why.
|
||||
- Might take some time to complete. Each repository check must complete
|
||||
before reporting back the result. If your session times out, take measures
|
||||
to allow the process to continue running such as starting a `screen` session,
|
||||
or running it using [Rails runner](../../../operations/rails_console.md#using-the-rails-runner)
|
||||
and `nohup`.
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.failed.find_each do |registry|
|
||||
begin
|
||||
puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Last Sync Failure: '#{registry.last_sync_failure}'"
|
||||
registry.replicator.sync
|
||||
puts "Sync initiated for registry ID: #{registry.id}"
|
||||
rescue => e
|
||||
puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Failed: '#{e}'", e.backtrace.join("\n")
|
||||
end
|
||||
end; nil
|
||||
```
|
||||
|
||||
#### Reverify one component on all sites
|
||||
|
||||
If the **primary** site's checksums are in question, then you need to make the **primary** site recalculate checksums. A "full re-verification" is then achieved, because after each checksum is recalculated on a **primary** site, events are generated which propagate to all **secondary** sites, causing them to recalculate their checksums and compare values. Any mismatch marks the registry as `sync failed`, which causes sync retries to be scheduled.
|
||||
|
||||
The UI does not provide a button to do a "full re-verification". You can simulate this by setting your **primary** site's `Re-verification interval` to 1 (day) in **Admin > Geo > Nodes > Edit**. The **primary** site will then recalculate the checksum of any resource that has been checksummed more than 1 day ago.
|
||||
|
||||
Optionally, you can do this manually:
|
||||
|
||||
1. SSH into a GitLab Rails node in the **primary** site.
|
||||
1. Open the [Rails console](../../../operations/rails_console.md#starting-a-rails-console-session).
|
||||
1. Mark all uploads as `pending verification`:
|
||||
1. Replacing `Upload` with any of the [Geo data type Model classes](#geo-data-type-model-classes),
|
||||
mark all resources as `pending verification`:
|
||||
|
||||
```ruby
|
||||
Upload.verification_state_table_class.each_batch do |relation|
|
||||
|
|
@ -208,37 +314,36 @@ For example, to reverify the `Upload` class:
|
|||
end
|
||||
```
|
||||
|
||||
1. This causes the primary to start checksumming all Uploads.
|
||||
1. When a primary successfully checksums a record, then all secondaries recalculate the checksum as well, and they compare the values.
|
||||
##### Reverify all resources that failed to checksum on the primary site
|
||||
|
||||
For other SSF data types replace `Upload` in the command above with the desired model class.
|
||||
The system automatically reverifies all resources that failed to checksum on the primary site, but
|
||||
it uses a progressive backoff scheme to avoid an excessive volume of failures.
|
||||
|
||||
#### Verify blob files on the secondary manually
|
||||
Optionally, for example if you've completed an attempted intervention, you can manually trigger
|
||||
reverification sooner:
|
||||
|
||||
This iterates over all package files on the secondary, looking at the
|
||||
`verification_checksum` stored in the database (which came from the primary)
|
||||
and then calculate this value on the secondary to check if they match. This
|
||||
does not change anything in the UI.
|
||||
1. SSH into a GitLab Rails node in the **primary** site.
|
||||
1. Open the [Rails console](../../../operations/rails_console.md#starting-a-rails-console-session).
|
||||
1. Replacing `Upload` with any of the [Geo data type Model classes](#geo-data-type-model-classes),
|
||||
mark all resources as `pending verification`:
|
||||
|
||||
```ruby
|
||||
# Run on secondary
|
||||
status = {}
|
||||
```ruby
|
||||
Upload.verification_state_table_class.where(verification_state: 3).each_batch do |relation|
|
||||
relation.update_all(verification_state: 0)
|
||||
end
|
||||
```
|
||||
|
||||
Packages::PackageFile.find_each do |package_file|
|
||||
primary_checksum = package_file.verification_checksum
|
||||
secondary_checksum = Packages::PackageFile.sha256_hexdigest(package_file.file.path)
|
||||
verification_status = (primary_checksum == secondary_checksum)
|
||||
#### Reverify one component on one secondary site
|
||||
|
||||
status[verification_status.to_s] ||= []
|
||||
status[verification_status.to_s] << package_file.id
|
||||
end
|
||||
If you believe the **primary** site checksums are correct, you can schedule a reverification of one
|
||||
component on one **secondary** site from the UI:
|
||||
|
||||
# Count how many of each value we get
|
||||
status.keys.each {|key| puts "#{key} count: #{status[key].count}"}
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
1. Select **Geo > Sites**.
|
||||
1. Under **Replication details**, select the desired component.
|
||||
1. Select **Reverify all**.
|
||||
|
||||
# See the output in its entirety
|
||||
status
|
||||
```
|
||||
## Errors
|
||||
|
||||
### Failed verification of Uploads on the primary Geo site
|
||||
|
||||
|
|
@ -435,56 +540,7 @@ Failed to open TCP connection to localhost:5000 (Connection refused - connect(2)
|
|||
It happens if the container registry is not enabled on the secondary site. To fix it, check that the container registry
|
||||
is [enabled on the secondary site](../../../packages/container_registry.md#enable-the-container-registry). Note that if [Let’s Encrypt integration is disabled](https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually), container registry is disabled as well, and you must [configure it manually](../../../packages/container_registry.md#configure-container-registry-under-its-own-domain).
|
||||
|
||||
## Reverify all uploads (or any SSF data type which is verified)
|
||||
|
||||
1. SSH into a GitLab Rails node in the primary Geo site.
|
||||
1. Open [Rails console](../../../operations/rails_console.md).
|
||||
1. Mark all uploads as "pending verification":
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
### Reverify all uploads
|
||||
|
||||
```ruby
|
||||
Upload.verification_state_table_class.each_batch do |relation|
|
||||
relation.update_all(verification_state: 0)
|
||||
end
|
||||
```
|
||||
|
||||
### Reverify failed uploads only
|
||||
|
||||
```ruby
|
||||
Upload.verification_state_table_class.where(verification_state: 3).each_batch do |relation|
|
||||
relation.update_all(verification_state: 0)
|
||||
end
|
||||
```
|
||||
|
||||
### How the reverification process works
|
||||
|
||||
When you [reverify all uploads](#reverify-all-uploads) or [reverify failed uploads only](#reverify-failed-uploads-only):
|
||||
|
||||
1. This causes the primary to start checksumming the Uploads depending on which commands were executed.
|
||||
1. When a primary successfully checksums a record, then all secondaries recalculate the checksum as well, and they compare the values.
|
||||
|
||||
You can perform a similar operation with other the Models handled by the [Geo Self-Service Framework](../../../../development/geo/framework.md) which have implemented verification:
|
||||
|
||||
- `LfsObject`
|
||||
- `MergeRequestDiff`
|
||||
- `Packages::PackageFile`
|
||||
- `Terraform::StateVersion`
|
||||
- `SnippetRepository`
|
||||
- `Ci::PipelineArtifact`
|
||||
- `PagesDeployment`
|
||||
- `Upload`
|
||||
- `Ci::JobArtifact`
|
||||
- `Ci::SecureFile`
|
||||
|
||||
NOTE:
|
||||
`GroupWikiRepository` is not in the previous list since verification is not implemented.
|
||||
There is an [issue to implement this functionality in the **Admin** area UI](https://gitlab.com/gitlab-org/gitlab/-/issues/364729).
|
||||
|
||||
## Message: `Synchronization failed - Error syncing repository`
|
||||
### Message: `Synchronization failed - Error syncing repository`
|
||||
|
||||
WARNING:
|
||||
If large repositories are affected by this problem,
|
||||
|
|
@ -514,7 +570,7 @@ A second synchronization error can also be caused by repository check issues:
|
|||
Error syncing repository: 13:Received RST_STREAM with error code 2.
|
||||
```
|
||||
|
||||
These errors can be observed by [immediately syncing all failed repositories](#sync-all-failed-repositories-now).
|
||||
These errors can be observed by [immediately syncing all failed repositories](#sync-all-resources-of-one-component-that-failed-to-sync).
|
||||
|
||||
Removing the malformed objects causing consistency errors involves rewriting the repository history, which is usually not an option.
|
||||
|
||||
|
|
@ -646,100 +702,6 @@ We recommend transferring each failing repository individually and checking for
|
|||
after each transfer. Follow the [single target `rsync` instructions](../../../operations/moving_repositories.md#single-rsync-to-another-server)
|
||||
to transfer each affected repository from the primary to the secondary site.
|
||||
|
||||
## Project or project wiki repositories
|
||||
|
||||
### Resync all Geo-replicable objects
|
||||
|
||||
You can schedule a full resync or reverification of all Geo-replicable objects
|
||||
from the UI:
|
||||
|
||||
1. On the left sidebar, at the bottom, select **Admin**.
|
||||
1. Select **Geo > Sites**.
|
||||
1. Under **Replication details**, select the desired object.
|
||||
1. Select **Resync all** or **Reverify all**.
|
||||
|
||||
Alternatively, [start a Rails console session](../../../operations/rails_console.md#starting-a-rails-console-session)
|
||||
**on the secondary Geo site** to gather more information, or execute these operations manually using the snippets below.
|
||||
|
||||
WARNING:
|
||||
Commands that change data can cause damage if not run correctly or under the right conditions. Always run commands in a test environment first and have a backup instance ready to restore.
|
||||
|
||||
### Find repository verification failures
|
||||
|
||||
#### Get the number of verification failed repositories
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.verification_failed.count
|
||||
```
|
||||
|
||||
#### Find the verification failed repositories
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.verification_failed
|
||||
```
|
||||
|
||||
#### Find repositories that failed to sync
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.failed
|
||||
```
|
||||
|
||||
#### Mark all repositories for reverification
|
||||
|
||||
The following snippet marks all project repositories for reverification. After a minute or two, the system should begin to schedule Sidekiq jobs according to your concurrency limits:
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.update_all(verification_state: 0)
|
||||
```
|
||||
|
||||
If there's a very large number of repositories to reverify, the single update query can time out. If this happens, you should run update queries in batches of rows using the same code as the **Reverify all** feature in the admin area:
|
||||
|
||||
```ruby
|
||||
::Geo::RegistryBulkUpdateService.new(:reverify_all, Geo::ProjectRepositoryRegistry).execute
|
||||
```
|
||||
|
||||
### Resync project and project wiki repositories
|
||||
|
||||
#### Queue up all repositories for resync
|
||||
|
||||
The following snippet marks all project repositories for reverification. After a minute or two, the system should begin to schedule Sidekiq jobs according to your concurrency limits:
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.update_all(state: 0, last_synced_at: nil)
|
||||
```
|
||||
|
||||
If there's a very large number of repositories to reverify, the single update query can time out. If this happens, you should run update queries in batches of rows using the same code as the **Reverify all** feature in the admin area:
|
||||
|
||||
```ruby
|
||||
::Geo::RegistryBulkUpdateService.new(:resync_all, Geo::ProjectRepositoryRegistry).execute
|
||||
```
|
||||
|
||||
#### Sync all failed repositories now
|
||||
|
||||
The following script:
|
||||
|
||||
- Loops over all failed repositories.
|
||||
- Displays the project details and the reasons for the last failure.
|
||||
- Attempts to resync the repository.
|
||||
- Reports back if a failure occurs, and why.
|
||||
- Might take some time to complete. Each repository check must complete
|
||||
before reporting back the result. If your session times out, take measures
|
||||
to allow the process to continue running such as starting a `screen` session,
|
||||
or running it using [Rails runner](../../../operations/rails_console.md#using-the-rails-runner)
|
||||
and `nohup`.
|
||||
|
||||
```ruby
|
||||
Geo::ProjectRepositoryRegistry.failed.find_each do |registry|
|
||||
begin
|
||||
puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Last Sync Failure: '#{registry.last_sync_failure}'"
|
||||
registry.replicator.sync
|
||||
puts "Sync initiated for registry ID: #{registry.id}"
|
||||
rescue => e
|
||||
puts "ID: #{registry.id}, Project ID: #{registry.project_id}, Failed: '#{e}'", e.backtrace.join("\n")
|
||||
end
|
||||
end ; nil
|
||||
```
|
||||
|
||||
## Find repository check failures in a Geo secondary site
|
||||
|
||||
NOTE:
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ the following steps if your sites use different URLs:
|
|||
|
||||
To allow the sites to talk to each other, [make sure the `Internal URL` field is unique for each site](../../geo_sites.md#set-up-the-internal-urls).
|
||||
|
||||
In Kubernetes, you can [use the same domain under `global.hosts.domain` as for the primary site](https://docs.gitlab.com/charts/advanced/geo/index.html).
|
||||
In Kubernetes, you can [use the same domain under `global.hosts.domain` as for the primary site](https://docs.gitlab.com/charts/advanced/geo/).
|
||||
|
||||
## Set up a separate URL for a secondary Geo site
|
||||
|
||||
|
|
|
|||
|
|
@ -1315,7 +1315,7 @@ gitaly['configuration'] = {
|
|||
:::TabTitle Helm chart (Kubernetes)
|
||||
|
||||
For Helm-based deployments, see the
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/index.html#server-side-backups).
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/#server-side-backups).
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
|
|
@ -1360,7 +1360,7 @@ gitaly['configuration'] = {
|
|||
:::TabTitle Helm chart (Kubernetes)
|
||||
|
||||
For Helm-based deployments, see the
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/index.html#server-side-backups).
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/#server-side-backups).
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
|
|
@ -1406,7 +1406,7 @@ gitaly['configuration'] = {
|
|||
:::TabTitle Helm chart (Kubernetes)
|
||||
|
||||
For Helm-based deployments, see the
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/index.html#server-side-backups).
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/#server-side-backups).
|
||||
|
||||
:::TabTitle Self-compiled (source)
|
||||
|
||||
|
|
@ -1435,7 +1435,7 @@ The following parameters are supported:
|
|||
:::TabTitle Helm chart (Kubernetes)
|
||||
|
||||
For Helm-based deployments, see the
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/index.html#server-side-backups).
|
||||
[server-side backup documentation for Gitaly chart](https://docs.gitlab.com/charts/charts/gitlab/gitaly/#server-side-backups).
|
||||
|
||||
:::TabTitle Linux package (Omnibus)
|
||||
|
||||
|
|
|
|||
|
|
@ -733,7 +733,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ check for an SSL or TLS problem:
|
|||
```
|
||||
|
||||
Check whether `Verify return code` field indicates a
|
||||
[known Linux package installation configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
[known Linux package installation configuration problem](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
If `openssl` succeeds but `gitlab-rake gitlab:gitaly:check` fails,
|
||||
check [certificate requirements](tls_support.md#certificate-requirements) for Gitaly.
|
||||
|
|
|
|||
|
|
@ -295,7 +295,7 @@ following:
|
|||
- `http://plantuml:8005/`
|
||||
- `http://localhost:8005/plantuml/`
|
||||
|
||||
If you're running [GitLab with TLS](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
If you're running [GitLab with TLS](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
you must configure this redirection, because PlantUML uses the insecure HTTP protocol.
|
||||
Newer browsers, such as [Google Chrome 86+](https://www.chromestatus.com/feature/4926989725073408),
|
||||
don't load insecure HTTP resources on pages served over HTTPS.
|
||||
|
|
|
|||
|
|
@ -520,7 +520,7 @@ error: failed to fetch some objects from 'https://username:[MASKED]@gitlab.examp
|
|||
```
|
||||
|
||||
When using GitLab CI over a TLS v1.3 configured GitLab server, you must
|
||||
[upgrade to GitLab Runner](https://docs.gitlab.com/runner/install/index.html) 13.2.0
|
||||
[upgrade to GitLab Runner](https://docs.gitlab.com/runner/install/) 13.2.0
|
||||
or later to receive an updated Git LFS client version with
|
||||
the included [GitLab Runner Helper image](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#helper-image).
|
||||
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Configure your load balancers to pass connections on port 443 as 'TCP' rather
|
|||
than 'HTTP(S)' protocol. This passes the connection to the application nodes
|
||||
NGINX service untouched. NGINX has the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
### Load Balancers terminate SSL without backend SSL
|
||||
|
|
@ -45,7 +45,7 @@ terminating SSL.
|
|||
|
||||
Because communication between the load balancers and GitLab isn't secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
### Load Balancers terminate SSL with backend SSL
|
||||
|
|
@ -58,7 +58,7 @@ Traffic is secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL because the
|
||||
connection is secure all the way. However, configuration must be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
## Ports
|
||||
|
|
@ -134,7 +134,7 @@ The default ciphers for a GitLab version can be
|
|||
viewed in the [`files/gitlab-cookbooks/gitlab/attributes/default.rb`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/files/gitlab-cookbooks/gitlab/attributes/default.rb)
|
||||
file and selecting the Git tag that correlates with your target GitLab version
|
||||
(for example `15.0.5+ee.0`). If required by your load balancer, you can then define
|
||||
[custom SSL ciphers](https://docs.gitlab.com/omnibus/settings/ssl/index.html#use-custom-ssl-ciphers)
|
||||
[custom SSL ciphers](https://docs.gitlab.com/omnibus/settings/ssl/#use-custom-ssl-ciphers)
|
||||
for NGINX.
|
||||
|
||||
### Some pages and links are downloaded instead of rendered in the browser
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ generation and copy the existing OpenSSH host keys into
|
|||
The following instructions switch OpenSSH in favor of `gitlab-sshd`:
|
||||
|
||||
1. Set the `gitlab-shell` charts `sshDaemon` option to
|
||||
[`gitlab-sshd`](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/index.html#installation-command-line-options).
|
||||
[`gitlab-sshd`](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/#installation-command-line-options).
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
|
|
@ -133,7 +133,7 @@ To enable the PROXY protocol:
|
|||
|
||||
:::TabTitle Helm chart (Kubernetes)
|
||||
|
||||
1. Set the [`gitlab.gitlab-shell.config` options](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/index.html#installation-command-line-options). For example:
|
||||
1. Set the [`gitlab.gitlab-shell.config` options](https://docs.gitlab.com/charts/charts/gitlab/gitlab-shell/#installation-command-line-options). For example:
|
||||
|
||||
```yaml
|
||||
gitlab:
|
||||
|
|
|
|||
|
|
@ -55,7 +55,7 @@ To move repositories:
|
|||
- [All groups](#move-all-groups) or
|
||||
[individual groups](../../api/group_repository_storage_moves.md#schedule-a-repository-storage-move-for-a-group).
|
||||
1. If [Geo](../geo/_index.md) is enabled,
|
||||
[resync all repositories](../geo/replication/troubleshooting/synchronization_verification.md#queue-up-all-repositories-for-resync).
|
||||
[resync all repositories](../geo/replication/troubleshooting/synchronization_verification.md#resync-all-resources-of-one-component).
|
||||
|
||||
#### Move all projects
|
||||
|
||||
|
|
|
|||
|
|
@ -154,7 +154,7 @@ steps below:
|
|||
|
||||
NOTE:
|
||||
If using a self-signed certificate from a custom Certificate Authority (CA),
|
||||
follow [the documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates)
|
||||
follow [the documentation](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates)
|
||||
to make them trusted by other GitLab components.
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb`:
|
||||
|
|
@ -251,7 +251,7 @@ configure this:
|
|||
|
||||
NOTE:
|
||||
For Helm-based deployments, see the
|
||||
[`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
|
||||
[`webservice` chart documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/).
|
||||
|
||||
Puma is the default web server and Unicorn is no longer supported.
|
||||
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ If you installed GitLab by using the Linux package, the container registry
|
|||
may or may not be available by default.
|
||||
|
||||
The container registry is automatically enabled and available on your GitLab domain, port 5050 if
|
||||
you're using the built-in [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration).
|
||||
you're using the built-in [Let's Encrypt integration](https://docs.gitlab.com/omnibus/settings/ssl/#enable-the-lets-encrypt-integration).
|
||||
|
||||
Otherwise, the container registry is not enabled. To enable it:
|
||||
|
||||
|
|
@ -224,7 +224,7 @@ domain. For example, `*.gitlab.example.com`, is a wildcard that matches `registr
|
|||
and is distinct from `*.example.com`.
|
||||
|
||||
As well as manually generated SSL certificates (explained here), certificates automatically
|
||||
generated by Let's Encrypt are also [supported in Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
generated by Let's Encrypt are also [supported in Linux package installations](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
Let's assume that you want the container registry to be accessible at
|
||||
`https://registry.gitlab.example.com`.
|
||||
|
|
|
|||
|
|
@ -677,7 +677,7 @@ fails to work if the custom CA is not recognized.
|
|||
This usually results in this error:
|
||||
`Post /oauth/token: x509: certificate signed by unknown authority`.
|
||||
|
||||
For Linux package installations, this is fixed by [installing a custom CA](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates).
|
||||
For Linux package installations, this is fixed by [installing a custom CA](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates).
|
||||
|
||||
For self-compiled installations, this can be fixed by installing the custom Certificate
|
||||
Authority (CA) in the system certificate store.
|
||||
|
|
@ -1259,7 +1259,7 @@ To allow certain IP ranges (subnets) to bypass all rate limits:
|
|||
|
||||
- `rate_limit_subnets_allow_list`: Sets the allow list with the IP ranges (subnets) that should bypass all rate limits.
|
||||
For example, `['1.2.3.4/24', '2001:db8::1/32']`.
|
||||
[Charts example](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/index.html#configure-rate-limits-subnets-allow-list) is available.
|
||||
[Charts example](https://docs.gitlab.com/charts/charts/gitlab/gitlab-pages/#configure-rate-limits-subnets-allow-list) is available.
|
||||
|
||||
An IPv6 address receives a large prefix in the 128-bit address space. The prefix is typically at least size /64. Because of the large number of possible addresses, if the client's IP address is IPv6, the limit is applied to the IPv6 prefix with a length of 64, rather than the entire IPv6 address.
|
||||
|
||||
|
|
|
|||
|
|
@ -131,7 +131,7 @@ component servers like [Gitaly](../gitaly/configure_gitaly.md#run-gitaly-on-its-
|
|||
You may also have a look at our troubleshooting guides for:
|
||||
|
||||
- [GitLab](../troubleshooting/_index.md).
|
||||
- [Linux package installations](https://docs.gitlab.com/omnibus/index.html#troubleshooting).
|
||||
- [Linux package installations](https://docs.gitlab.com/omnibus/#troubleshooting).
|
||||
|
||||
Additionally you should also [verify database values can be decrypted using the current secrets](check.md#verify-database-values-can-be-decrypted-using-the-current-secrets).
|
||||
|
||||
|
|
|
|||
|
|
@ -326,7 +326,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -337,7 +337,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -350,7 +350,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -1681,7 +1681,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
@ -2094,7 +2094,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX will fail to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -328,7 +328,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -339,7 +339,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -352,7 +352,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -1687,7 +1687,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
@ -2102,7 +2102,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX will fail to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -227,7 +227,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -238,7 +238,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -251,7 +251,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -558,7 +558,7 @@ You must bring your own certificates as this isn't provided automatically.
|
|||
The certificate, or its certificate authority, must be installed on all Gitaly
|
||||
nodes (including the Gitaly node using the certificate) and on all client nodes
|
||||
that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates).
|
||||
|
||||
NOTE:
|
||||
The self-signed certificate must specify the address you use to access the
|
||||
|
|
@ -910,7 +910,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX will fail to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -327,7 +327,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -340,7 +340,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -1521,7 +1521,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
@ -1962,7 +1962,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX will fail to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -334,7 +334,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -345,7 +345,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -358,7 +358,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -1694,7 +1694,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
@ -2117,7 +2117,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX will fail to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ Configure your load balancer to pass connections on port 443 as `TCP` rather
|
|||
than `HTTP(S)` protocol. This will pass the connection to the application node's
|
||||
NGINX service untouched. NGINX will have the SSL certificate and listen on port 443.
|
||||
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
See the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
#### Load balancer terminates SSL without backend SSL
|
||||
|
|
@ -327,7 +327,7 @@ terminating SSL.
|
|||
|
||||
Since communication between the load balancer and GitLab will not be secure,
|
||||
there is some additional configuration needed. See the
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
[proxied SSL documentation](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination)
|
||||
for details.
|
||||
|
||||
#### Load balancer terminates SSL with backend SSL
|
||||
|
|
@ -340,7 +340,7 @@ Traffic will also be secure between the load balancers and NGINX in this
|
|||
scenario. There is no need to add configuration for proxied SSL since the
|
||||
connection will be secure all the way. However, configuration will need to be
|
||||
added to GitLab to configure SSL certificates. See
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
for details on managing SSL certificates and configuring NGINX.
|
||||
|
||||
<div align="right">
|
||||
|
|
@ -1518,7 +1518,7 @@ for secure connections, you must:
|
|||
|
||||
Additionally the certificate, or its certificate authority, must be installed on all Gitaly servers
|
||||
and on all Praefect clients that communicate with it following the procedure described in
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates) (and repeated below).
|
||||
[GitLab custom certificate configuration](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates) (and repeated below).
|
||||
|
||||
Note the following:
|
||||
|
||||
|
|
@ -1962,7 +1962,7 @@ On each node perform the following:
|
|||
When you specify `https` in the `external_url`, as in the previous example,
|
||||
GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
|
||||
certificates aren't present, NGINX fails to start. For more information, see
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### GitLab Rails post-configuration
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ the [Linux package documentation](https://docs.gitlab.com/omnibus/settings/logs.
|
|||
When using TLS Authentication with a self signed certificate, the CA certificate
|
||||
needs to be trusted by the OpenSSL installation. When using GitLab installed
|
||||
using the Linux package, learn to install a custom CA in the
|
||||
[Linux package documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
[Linux package documentation](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
Alternatively, learn where to install custom certificates by using
|
||||
`openssl version -d`.
|
||||
|
||||
|
|
|
|||
|
|
@ -73,25 +73,25 @@ This content has been moved to [Troubleshooting Sidekiq](../sidekiq/sidekiq_trou
|
|||
|
||||
### Reverify all uploads (or any SSF data type which is verified)
|
||||
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#reverify-all-uploads-or-any-ssf-data-type-which-is-verified).
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#resync-and-reverify-multiple-components).
|
||||
|
||||
### Artifacts
|
||||
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#resync-and-reverify-individual-components).
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#manually-retry-replication-or-verification).
|
||||
|
||||
### Repository verification failures
|
||||
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#find-repository-verification-failures).
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#manually-retry-replication-or-verification).
|
||||
|
||||
### Resync repositories
|
||||
|
||||
Moved to [Geo replication troubleshooting - Resync repository types](../geo/replication/troubleshooting/synchronization_verification.md#resync-and-reverify-individual-components).
|
||||
Moved to [Geo replication troubleshooting - Resync repository types](../geo/replication/troubleshooting/synchronization_verification.md#manually-retry-replication-or-verification).
|
||||
|
||||
Moved to [Geo replication troubleshooting - Resync project and project wiki repositories](../geo/replication/troubleshooting/synchronization_verification.md#resync-project-and-project-wiki-repositories).
|
||||
Moved to [Geo replication troubleshooting - Resync project and project wiki repositories](../geo/replication/troubleshooting/synchronization_verification.md#manually-retry-replication-or-verification).
|
||||
|
||||
### Blob types
|
||||
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#resync-and-reverify-individual-components).
|
||||
Moved to [Geo replication troubleshooting](../geo/replication/troubleshooting/synchronization_verification.md#manually-retry-replication-or-verification).
|
||||
|
||||
## Generate Service Ping
|
||||
|
||||
|
|
|
|||
|
|
@ -63,7 +63,7 @@ DETAILS:
|
|||
**Introduced** in GitLab 16.3.
|
||||
**Status**: Experiment.
|
||||
|
||||
Returns [`LabelConnection`](#labelconnection).
|
||||
Returns [`AbuseReportLabelConnection`](#abusereportlabelconnection).
|
||||
|
||||
This field returns a [connection](#connections). It accepts the
|
||||
four standard [pagination arguments](#pagination-arguments):
|
||||
|
|
@ -12348,6 +12348,30 @@ The edge type for [`AbuseReportDiscussion`](#abusereportdiscussion).
|
|||
| <a id="abusereportdiscussionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
|
||||
| <a id="abusereportdiscussionedgenode"></a>`node` | [`AbuseReportDiscussion`](#abusereportdiscussion) | The item at the end of the edge. |
|
||||
|
||||
#### `AbuseReportLabelConnection`
|
||||
|
||||
The connection type for [`AbuseReportLabel`](#abusereportlabel).
|
||||
|
||||
##### Fields
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="abusereportlabelconnectioncount"></a>`count` | [`Int!`](#int) | Total count of collection. |
|
||||
| <a id="abusereportlabelconnectionedges"></a>`edges` | [`[AbuseReportLabelEdge]`](#abusereportlabeledge) | A list of edges. |
|
||||
| <a id="abusereportlabelconnectionnodes"></a>`nodes` | [`[AbuseReportLabel]`](#abusereportlabel) | A list of nodes. |
|
||||
| <a id="abusereportlabelconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
|
||||
|
||||
#### `AbuseReportLabelEdge`
|
||||
|
||||
The edge type for [`AbuseReportLabel`](#abusereportlabel).
|
||||
|
||||
##### Fields
|
||||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="abusereportlabeledgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
|
||||
| <a id="abusereportlabeledgenode"></a>`node` | [`AbuseReportLabel`](#abusereportlabel) | The item at the end of the edge. |
|
||||
|
||||
#### `AbuseReportNoteConnection`
|
||||
|
||||
The connection type for [`AbuseReportNote`](#abusereportnote).
|
||||
|
|
@ -19016,7 +19040,7 @@ An abuse report.
|
|||
| ---- | ---- | ----------- |
|
||||
| <a id="abusereportdiscussions"></a>`discussions` | [`AbuseReportDiscussionConnection!`](#abusereportdiscussionconnection) | All discussions on the noteable. (see [Connections](#connections)) |
|
||||
| <a id="abusereportid"></a>`id` | [`AbuseReportID!`](#abusereportid) | Global ID of the abuse report. |
|
||||
| <a id="abusereportlabels"></a>`labels` | [`LabelConnection`](#labelconnection) | Labels of the abuse report. (see [Connections](#connections)) |
|
||||
| <a id="abusereportlabels"></a>`labels` | [`AbuseReportLabelConnection`](#abusereportlabelconnection) | Labels of the abuse report. (see [Connections](#connections)) |
|
||||
| <a id="abusereportnotes"></a>`notes` | [`AbuseReportNoteConnection!`](#abusereportnoteconnection) | All notes on the noteable. (see [Connections](#connections)) |
|
||||
|
||||
### `AbuseReportDiscussion`
|
||||
|
|
@ -19045,7 +19069,7 @@ An abuse report.
|
|||
| <a id="abusereportlabelcreatedat"></a>`createdAt` | [`Time!`](#time) | When the label was created. |
|
||||
| <a id="abusereportlabeldescription"></a>`description` | [`String`](#string) | Description of the label (Markdown rendered as HTML for caching). |
|
||||
| <a id="abusereportlabeldescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
|
||||
| <a id="abusereportlabelid"></a>`id` | [`ID!`](#id) | Label ID. |
|
||||
| <a id="abusereportlabelid"></a>`id` | [`AntiAbuseReportsLabelID!`](#antiabusereportslabelid) | Global ID of the abuse report label. |
|
||||
| <a id="abusereportlabeltextcolor"></a>`textColor` | [`String!`](#string) | Text color of the label. |
|
||||
| <a id="abusereportlabeltitle"></a>`title` | [`String!`](#string) | Content of the label. |
|
||||
| <a id="abusereportlabelupdatedat"></a>`updatedAt` | [`Time!`](#time) | When the label was last updated. |
|
||||
|
|
@ -23742,6 +23766,7 @@ A software dependency used by a project.
|
|||
| <a id="dependencypackager"></a>`packager` | [`PackageManager`](#packagemanager) | Description of the tool used to manage the dependency. |
|
||||
| <a id="dependencyreachability"></a>`reachability` | [`ReachabilityType`](#reachabilitytype) | Information about reachability of a dependency. |
|
||||
| <a id="dependencyversion"></a>`version` | [`String`](#string) | Version of the dependency. |
|
||||
| <a id="dependencyvulnerabilitycount"></a>`vulnerabilityCount` | [`Int!`](#int) | Number of vulnerabilities within the dependency. |
|
||||
|
||||
### `DependencyProxyBlob`
|
||||
|
||||
|
|
@ -28619,7 +28644,7 @@ Label to apply to associated Kubernetes objects of a workspace.
|
|||
| <a id="labelcreatedat"></a>`createdAt` | [`Time!`](#time) | When the label was created. |
|
||||
| <a id="labeldescription"></a>`description` | [`String`](#string) | Description of the label (Markdown rendered as HTML for caching). |
|
||||
| <a id="labeldescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
|
||||
| <a id="labelid"></a>`id` | [`ID!`](#id) | Label ID. |
|
||||
| <a id="labelid"></a>`id` | [`LabelID!`](#labelid) | Global ID of the label. |
|
||||
| <a id="labellockonmerge"></a>`lockOnMerge` | [`Boolean!`](#boolean) | Indicates this label is locked for merge requests that have been merged. |
|
||||
| <a id="labeltextcolor"></a>`textColor` | [`String!`](#string) | Text color of the label. |
|
||||
| <a id="labeltitle"></a>`title` | [`String!`](#string) | Content of the label. |
|
||||
|
|
@ -28661,7 +28686,8 @@ Represents the Geo sync and verification state of an LFS object.
|
|||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="licensename"></a>`name` | [`String!`](#string) | Name of the license. |
|
||||
| <a id="licenseurl"></a>`url` | [`String!`](#string) | License URL in relation to SPDX. |
|
||||
| <a id="licensespdxidentifier"></a>`spdxIdentifier` | [`String`](#string) | Name of the SPDX identifier. |
|
||||
| <a id="licenseurl"></a>`url` | [`String`](#string) | License URL in relation to SPDX. |
|
||||
|
||||
### `LicenseHistoryEntry`
|
||||
|
||||
|
|
@ -28705,6 +28731,7 @@ Represents an entry from the Cloud License history.
|
|||
| ---- | ---- | ----------- |
|
||||
| <a id="locationblobpath"></a>`blobPath` | [`String`](#string) | HTTP URI path to view the input file in GitLab. |
|
||||
| <a id="locationpath"></a>`path` | [`String`](#string) | Path, relative to the root of the repository, of the filewhich was analyzed to detect the dependency. |
|
||||
| <a id="locationtoplevel"></a>`topLevel` | [`Boolean`](#boolean) | Is top level dependency. |
|
||||
|
||||
### `MLCandidateLinks`
|
||||
|
||||
|
|
@ -43493,6 +43520,12 @@ A `AnalyticsDevopsAdoptionEnabledNamespaceID` is a global ID. It is encoded as a
|
|||
|
||||
An example `AnalyticsDevopsAdoptionEnabledNamespaceID` is: `"gid://gitlab/Analytics::DevopsAdoption::EnabledNamespace/1"`.
|
||||
|
||||
### `AntiAbuseReportsLabelID`
|
||||
|
||||
A `AntiAbuseReportsLabelID` is a global ID. It is encoded as a string.
|
||||
|
||||
An example `AntiAbuseReportsLabelID` is: `"gid://gitlab/AntiAbuse::Reports::Label/1"`.
|
||||
|
||||
### `AntiAbuseReportsNoteID`
|
||||
|
||||
A `AntiAbuseReportsNoteID` is a global ID. It is encoded as a string.
|
||||
|
|
@ -45042,7 +45075,6 @@ Implementations:
|
|||
| <a id="labelinterfacecolor"></a>`color` | [`String!`](#string) | Background color of the label. |
|
||||
| <a id="labelinterfacecreatedat"></a>`createdAt` | [`Time!`](#time) | When the label was created. |
|
||||
| <a id="labelinterfacedescription"></a>`description` | [`String`](#string) | Description of the label (Markdown rendered as HTML for caching). |
|
||||
| <a id="labelinterfaceid"></a>`id` | [`ID!`](#id) | Label ID. |
|
||||
| <a id="labelinterfacetextcolor"></a>`textColor` | [`String!`](#string) | Text color of the label. |
|
||||
| <a id="labelinterfacetitle"></a>`title` | [`String!`](#string) | Content of the label. |
|
||||
| <a id="labelinterfaceupdatedat"></a>`updatedAt` | [`Time!`](#time) | When the label was last updated. |
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ info:
|
|||
|
||||
When viewing this on gitlab.com, you can test API calls directly from the browser
|
||||
against the `gitlab.com` instance, if you are logged in.
|
||||
The feature uses the current [GitLab session cookie](https://docs.gitlab.com/ee/api/index.html#session-cookie),
|
||||
The feature uses the current [GitLab session cookie](https://docs.gitlab.com/ee/api/#session-cookie),
|
||||
so each request is made using your account.
|
||||
|
||||
Instructions for using this tool can be found in [Interactive API Documentation](https://docs.gitlab.com/ee/api/openapi/openapi_interactive.html)
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ For general information about the GitLab APIs, see [API Docs](../_index.md).
|
|||
|
||||
<!--
|
||||
The following link is absolute rather than relative because it needs to be viewed through the GitLab
|
||||
Open API file viewer: https://docs.gitlab.com/ee/user/project/repository/index.html#openapi-viewer.
|
||||
Open API file viewer: https://docs.gitlab.com/ee/user/project/repository/#openapi-viewer.
|
||||
-->
|
||||
The [interactive API documentation tool](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/api/openapi/openapi.yaml)
|
||||
allows API testing directly on the GitLab.com website. Only a few of the available endpoints are
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ Example response:
|
|||
```json
|
||||
{
|
||||
"name": "Ruby",
|
||||
"content": "# This file is a template, and might need editing before it works on your project.\n# To contribute improvements to CI/CD templates, please follow the Development guide at:\n# https://docs.gitlab.com/ee/development/cicd/templates.html\n# This specific template is located at:\n# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml\n\n# Official language image. Look for the different tagged releases at:\n# https://hub.docker.com/r/library/ruby/tags/\nimage: ruby:latest\n\n# Pick zero or more services to be used on all builds.\n# Only needed when using a docker container to run your tests in.\n# Check out: https://docs.gitlab.com/ee/ci/services/index.html\nservices:\n - mysql:latest\n - redis:latest\n - postgres:latest\n\nvariables:\n POSTGRES_DB: database_name\n\n# Cache gems in between builds\ncache:\n paths:\n - vendor/ruby\n\n# This is a basic example for a gem or script which doesn't use\n# services such as redis or postgres\nbefore_script:\n - ruby -v # Print out ruby version for debugging\n # Uncomment next line if your rails app needs a JS runtime:\n # - apt-get update -q \u0026\u0026 apt-get install nodejs -yqq\n - bundle config set --local deployment true # Install dependencies into ./vendor/ruby\n - bundle install -j $(nproc)\n\n# Optional - Delete if not using `rubocop`\nrubocop:\n script:\n - rubocop\n\nrspec:\n script:\n - rspec spec\n\nrails:\n variables:\n DATABASE_URL: \"postgresql://postgres:postgres@postgres:5432/$POSTGRES_DB\"\n script:\n - rails db:migrate\n - rails db:seed\n - rails test\n\n# This deploy job uses a simple deploy flow to Heroku, other providers, for example, AWS Elastic Beanstalk\n# are supported too: https://github.com/travis-ci/dpl\ndeploy:\n stage: deploy\n environment: production\n script:\n - gem install dpl\n - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY\n"
|
||||
"content": "# This file is a template, and might need editing before it works on your project.\n# To contribute improvements to CI/CD templates, please follow the Development guide at:\n# https://docs.gitlab.com/ee/development/cicd/templates.html\n# This specific template is located at:\n# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Ruby.gitlab-ci.yml\n\n# Official language image. Look for the different tagged releases at:\n# https://hub.docker.com/r/library/ruby/tags/\nimage: ruby:latest\n\n# Pick zero or more services to be used on all builds.\n# Only needed when using a docker container to run your tests in.\n# Check out: https://docs.gitlab.com/ee/ci/services/\nservices:\n - mysql:latest\n - redis:latest\n - postgres:latest\n\nvariables:\n POSTGRES_DB: database_name\n\n# Cache gems in between builds\ncache:\n paths:\n - vendor/ruby\n\n# This is a basic example for a gem or script which doesn't use\n# services such as redis or postgres\nbefore_script:\n - ruby -v # Print out ruby version for debugging\n # Uncomment next line if your rails app needs a JS runtime:\n # - apt-get update -q \u0026\u0026 apt-get install nodejs -yqq\n - bundle config set --local deployment true # Install dependencies into ./vendor/ruby\n - bundle install -j $(nproc)\n\n# Optional - Delete if not using `rubocop`\nrubocop:\n script:\n - rubocop\n\nrspec:\n script:\n - rspec spec\n\nrails:\n variables:\n DATABASE_URL: \"postgresql://postgres:postgres@postgres:5432/$POSTGRES_DB\"\n script:\n - rails db:migrate\n - rails db:seed\n - rails test\n\n# This deploy job uses a simple deploy flow to Heroku, other providers, for example, AWS Elastic Beanstalk\n# are supported too: https://github.com/travis-ci/dpl\ndeploy:\n stage: deploy\n environment: production\n script:\n - gem install dpl\n - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_PRODUCTION_KEY\n"
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -90,7 +90,7 @@ of this file. You can do this with a command like:
|
|||
kubectl create configmap docker-client-config --namespace gitlab-runner --from-file /opt/.docker/config.json
|
||||
```
|
||||
|
||||
Update the [volume mounts](https://docs.gitlab.com/runner/executors/kubernetes/index.html#custom-volume-mount)
|
||||
Update the [volume mounts](https://docs.gitlab.com/runner/executors/kubernetes/#custom-volume-mount)
|
||||
to include the file.
|
||||
|
||||
```toml
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ For more information, see [security of the `docker` group](https://blog.zopyx.co
|
|||
"Docker-in-Docker" (`dind`) means:
|
||||
|
||||
- Your registered runner uses the [Docker executor](https://docs.gitlab.com/runner/executors/docker.html) or
|
||||
the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html).
|
||||
the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/).
|
||||
- The executor uses a [container image of Docker](https://hub.docker.com/_/docker/), provided
|
||||
by Docker, to run your CI/CD jobs.
|
||||
|
||||
|
|
@ -296,7 +296,7 @@ For more information, see [Proxy settings when using dind service](https://docs.
|
|||
|
||||
#### Use the Kubernetes executor with Docker-in-Docker
|
||||
|
||||
You can use the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html) to run jobs in a Docker container.
|
||||
You can use the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/) to run jobs in a Docker container.
|
||||
|
||||
##### Docker-in-Docker with TLS enabled in Kubernetes
|
||||
|
||||
|
|
@ -519,7 +519,7 @@ services:
|
|||
If you are a GitLab Runner administrator, you can specify the `command` to configure the registry mirror
|
||||
for the Docker daemon. The `dind` service must be defined for the
|
||||
[Docker](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnersdockerservices-section)
|
||||
or [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html#define-a-list-of-services).
|
||||
or [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/#define-a-list-of-services).
|
||||
|
||||
Docker:
|
||||
|
||||
|
|
@ -587,7 +587,7 @@ detected by the `dind` service.
|
|||
If you are a GitLab Runner administrator, you can use
|
||||
the mirror for every `dind` service. Update the
|
||||
[configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html)
|
||||
to specify a [ConfigMap volume mount](https://docs.gitlab.com/runner/executors/kubernetes/index.html#configmap-volume).
|
||||
to specify a [ConfigMap volume mount](https://docs.gitlab.com/runner/executors/kubernetes/#configmap-volume).
|
||||
|
||||
For example, if you have a `/tmp/daemon.json` file with the following
|
||||
content:
|
||||
|
|
@ -743,7 +743,7 @@ use one of these alternatives:
|
|||
To use Buildah with GitLab CI/CD, you need [a runner](https://docs.gitlab.com/runner/) with one
|
||||
of the following executors:
|
||||
|
||||
- [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/index.html).
|
||||
- [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/).
|
||||
- [Docker](https://docs.gitlab.com/runner/executors/docker.html).
|
||||
- [Docker Machine](https://docs.gitlab.com/runner/executors/docker_machine.html).
|
||||
|
||||
|
|
@ -807,7 +807,7 @@ This error occurs because Docker starts on TLS automatically.
|
|||
- If you are upgrading from v18.09 or earlier, see the
|
||||
[upgrade guide](https://about.gitlab.com/blog/2019/07/31/docker-in-docker-with-docker-19-dot-03/).
|
||||
|
||||
This error can also occur with the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html#using-dockerdind) when attempts are made to access the Docker-in-Docker service before it has fully started up. For a more detailed explanation, see [issue 27215](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27215).
|
||||
This error can also occur with the [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/#using-dockerdind) when attempts are made to access the Docker-in-Docker service before it has fully started up. For a more detailed explanation, see [issue 27215](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27215).
|
||||
|
||||
### Docker `no such host` error
|
||||
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ To define which option should be used, the runner process reads the configuratio
|
|||
|
||||
### Requirements and limitations
|
||||
|
||||
- Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html)
|
||||
- Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/)
|
||||
in GitLab Runner 13.1 and later.
|
||||
- [Credentials Store](#use-a-credentials-store) and [Credential Helpers](#use-credential-helpers)
|
||||
require binaries to be added to the GitLab Runner `$PATH`, and require access to do so. Therefore,
|
||||
|
|
@ -560,4 +560,4 @@ and manual credential management.
|
|||
- Dockerfile
|
||||
```
|
||||
|
||||
1. [Register the runner](https://docs.gitlab.com/runner/register/index.html#docker).
|
||||
1. [Register the runner](https://docs.gitlab.com/runner/register/#docker).
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ method:
|
|||
To use kaniko with GitLab, [a runner](https://docs.gitlab.com/runner/) with one
|
||||
of the following executors is required:
|
||||
|
||||
- [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/index.html).
|
||||
- [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/).
|
||||
- [Docker](https://docs.gitlab.com/runner/executors/docker.html).
|
||||
- [Docker Machine](https://docs.gitlab.com/runner/executors/docker_machine.html).
|
||||
|
||||
|
|
@ -146,7 +146,7 @@ video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-ex
|
|||
Guided Exploration project pipeline. It was tested on:
|
||||
|
||||
- [GitLab.com instance runners](../runners/_index.md)
|
||||
- [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes/index.html)
|
||||
- [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes/)
|
||||
|
||||
The example can be copied to your own group or instance for testing. More details
|
||||
on what other GitLab CI patterns are demonstrated are available at the project page.
|
||||
|
|
|
|||
|
|
@ -46,7 +46,7 @@ GitLab uses a similar concept to agents called [runners](https://docs.gitlab.com
|
|||
which use [executors](https://docs.gitlab.com/runner/executors/) to run builds.
|
||||
|
||||
Examples of executors are shell, Docker, or Kubernetes. You can choose to use [GitLab.com runners](../runners/_index.md)
|
||||
or deploy your own [self-managed runners](https://docs.gitlab.com/runner/install/index.html).
|
||||
or deploy your own [self-managed runners](https://docs.gitlab.com/runner/install/).
|
||||
|
||||
### Workflow
|
||||
|
||||
|
|
|
|||
|
|
@ -472,7 +472,7 @@ You can also use variables to configure how many times a runner
|
|||
[attempts certain stages of job execution](#job-stages-attempts).
|
||||
|
||||
When using the Kubernetes executor, you can use variables to
|
||||
[override Kubernetes CPU and memory allocations for requests and limits](https://docs.gitlab.com/runner/executors/kubernetes/index.html#overwrite-container-resources).
|
||||
[override Kubernetes CPU and memory allocations for requests and limits](https://docs.gitlab.com/runner/executors/kubernetes/#overwrite-container-resources).
|
||||
|
||||
### Git strategy
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ multiple projects.
|
|||
|
||||
If you are using GitLab Self-Managed, administrators can:
|
||||
|
||||
- [Install GitLab Runner](https://docs.gitlab.com/runner/install/index.html) and register an instance runner.
|
||||
- [Install GitLab Runner](https://docs.gitlab.com/runner/install/) and register an instance runner.
|
||||
- Configure a maximum number of instance runner [compute minutes for each group](../../administration/cicd/compute_minutes.md#set-the-compute-quota-for-a-group).
|
||||
|
||||
If you are using GitLab.com:
|
||||
|
|
@ -137,8 +137,8 @@ On GitLab Self-Managed, an administrator can
|
|||
[enable them for all new projects](../../administration/settings/continuous_integration.md#enable-instance-runners-for-new-projects).
|
||||
|
||||
For existing projects, an administrator must
|
||||
[install](https://docs.gitlab.com/runner/install/index.html) and
|
||||
[register](https://docs.gitlab.com/runner/register/index.html) them.
|
||||
[install](https://docs.gitlab.com/runner/install/) and
|
||||
[register](https://docs.gitlab.com/runner/register/) them.
|
||||
|
||||
To enable instance runners for a project:
|
||||
|
||||
|
|
@ -644,7 +644,7 @@ DETAILS:
|
|||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/365078) in GitLab 15.3.
|
||||
|
||||
The version of GitLab Runner used by your runners should be
|
||||
[kept up-to-date](https://docs.gitlab.com/runner/index.html#gitlab-runner-versions).
|
||||
[kept up-to-date](https://docs.gitlab.com/runner/#gitlab-runner-versions).
|
||||
|
||||
To determine which runners need to be upgraded:
|
||||
|
||||
|
|
|
|||
|
|
@ -471,11 +471,11 @@ The same configuration is required if your goal is to [use rootless Podman to ru
|
|||
|
||||
### Configure Kubernetes or OpenShift runners
|
||||
|
||||
You must set up Docker in a Docker container (Docker-in-Docker) to use Code Quality. The Kubernetes executor [supports Docker-in-Docker](https://docs.gitlab.com/runner/executors/kubernetes/index.html#using-dockerdind).
|
||||
You must set up Docker in a Docker container (Docker-in-Docker) to use Code Quality. The Kubernetes executor [supports Docker-in-Docker](https://docs.gitlab.com/runner/executors/kubernetes/#using-dockerdind).
|
||||
|
||||
To ensure Code Quality jobs can run on a Kubernetes executor:
|
||||
|
||||
- If you're using TLS to communicate with the Docker daemon, the executor [must be running in privileged mode](https://docs.gitlab.com/runner/executors/kubernetes/index.html#other-configtoml-settings). Additionally, the certificate directory must be [specified as a volume mount](../docker/using_docker_build.md#docker-in-docker-with-tls-enabled-in-kubernetes).
|
||||
- If you're using TLS to communicate with the Docker daemon, the executor [must be running in privileged mode](https://docs.gitlab.com/runner/executors/kubernetes/#other-configtoml-settings). Additionally, the certificate directory must be [specified as a volume mount](../docker/using_docker_build.md#docker-in-docker-with-tls-enabled-in-kubernetes).
|
||||
- It is possible that the DinD service doesn't start up fully before the Code Quality job starts. This is a limitation documented in
|
||||
[Troubleshooting the Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes/troubleshooting.html#docker-cannot-connect-to-the-docker-daemon-at-tcpdocker2375-is-the-docker-daemon-running). To resolve the issue, use `before_script` to wait for the Docker daemon to fully boot up. For an example, see the configuration in the `.gitlab-ci.yml` file below.
|
||||
|
||||
|
|
@ -524,7 +524,7 @@ To ensure that you use the `overlay2` [storage driver](https://docs.docker.com/s
|
|||
- Specify the `DOCKER_HOST` that the Docker CLI communicates with.
|
||||
- Set the `DOCKER_DRIVER` variable to empty.
|
||||
|
||||
Use the `before_script` section to wait for the Docker daemon to fully boot up. Since GitLab Runner v16.9, this can also be done [by just setting the `HEALTHCHECK_TCP_PORT` variable](https://docs.gitlab.com/runner/executors/kubernetes/index.html#define-a-list-of-services).
|
||||
Use the `before_script` section to wait for the Docker daemon to fully boot up. Since GitLab Runner v16.9, this can also be done [by just setting the `HEALTHCHECK_TCP_PORT` variable](https://docs.gitlab.com/runner/executors/kubernetes/#define-a-list-of-services).
|
||||
|
||||
```yaml
|
||||
include:
|
||||
|
|
@ -595,7 +595,7 @@ name = "docker:20.10.12-dind"
|
|||
oc adm policy add-scc-to-user -z dind-sa privileged
|
||||
```
|
||||
|
||||
1. Set the permissions in the [`[runners.kubernetes]` section](https://docs.gitlab.com/runner/executors/kubernetes/index.html#other-configtoml-settings).
|
||||
1. Set the permissions in the [`[runners.kubernetes]` section](https://docs.gitlab.com/runner/executors/kubernetes/#other-configtoml-settings).
|
||||
1. Set the job definition stays the same as in Kubernetes case:
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Example:
|
|||
### Kubernetes
|
||||
|
||||
If you have access to GitLab Runner configuration and the Kubernetes cluster,
|
||||
you can [mount a ConfigMap](https://docs.gitlab.com/runner/executors/kubernetes/index.html#configmap-volume).
|
||||
you can [mount a ConfigMap](https://docs.gitlab.com/runner/executors/kubernetes/#configmap-volume).
|
||||
|
||||
Replace `gitlab.example.com` with the actual domain of the registry.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ CI/CD variables are a type of environment variable. You can use them to:
|
|||
You can [override variable values](#cicd-variable-precedence) for a specific pipeline when you [run a pipeline manually](../pipelines/_index.md#run-a-pipeline-manually), [run a manual job](../jobs/job_control.md#specify-variables-when-running-manual-jobs),
|
||||
or have them [prefilled in manual pipelines](../pipelines/_index.md#prefill-variables-in-manual-pipelines).
|
||||
|
||||
Variable names are limited by the [shell the runner uses](https://docs.gitlab.com/runner/shells/index.html)
|
||||
Variable names are limited by the [shell the runner uses](https://docs.gitlab.com/runner/shells/)
|
||||
to execute scripts. Each shell has its own set of reserved variable names.
|
||||
|
||||
To ensure consistent behavior, you should always put variable values in single or double quotes.
|
||||
|
|
|
|||
|
|
@ -505,7 +505,7 @@ Please, see the video ([internal link](https://drive.google.com/file/d/1X6CARf0g
|
|||
### (Deprecated) Issue and epic experiments
|
||||
|
||||
NOTE:
|
||||
This section is deprecated in favor of the [development seed file](model_migration.md#seed-project-and-group-resources-for-testing-and-evaluation).
|
||||
This section is deprecated in favor of the [development seed file](testing_and_validation.md#seed-project-and-group-resources-for-testing-and-evaluation).
|
||||
|
||||
If you would like to use the evaluation framework (as described [here](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/prompt-library/-/blob/main/doc/how-to/run_duo_chat_eval.md?ref_type=heads#evaluation-on-issueepic))
|
||||
you can import the required groups and projects using this Rake task:
|
||||
|
|
@ -523,7 +523,7 @@ desired.
|
|||
#### (Deprecated) Epic and issue fixtures
|
||||
|
||||
NOTE:
|
||||
This section is deprecated in favor of the [development seed file](model_migration.md#seed-project-and-group-resources-for-testing-and-evaluation).
|
||||
This section is deprecated in favor of the [development seed file](testing_and_validation.md#seed-project-and-group-resources-for-testing-and-evaluation).
|
||||
|
||||
The fixtures are the replicas of the _public_ issues and epics from projects and groups _owned by_ GitLab.
|
||||
The internal notes were excluded when they were sampled. The fixtures have been committed into the canonical `gitlab` repository.
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ The model selection logic should be implemented in:
|
|||
- If issues arise, quickly disable the feature flag to rollback to the previous model
|
||||
- Once stability is confirmed, remove the feature flag and make the migration permanent
|
||||
|
||||
For more details on monitoring during migrations, see the [Monitoring and Metrics](#monitoring-and-metrics) section below.
|
||||
For more details on monitoring during migrations, see the [Monitoring and Metrics](testing_and_validation.md#monitoring-and-metrics) section below.
|
||||
|
||||
## Scope of Work
|
||||
|
||||
|
|
@ -156,60 +156,3 @@ For more details on monitoring during migrations, see the [Monitoring and Metric
|
|||
- **Experimental Tools:**
|
||||
- Summarize Comments Chat
|
||||
- Fill MR Description
|
||||
|
||||
## Testing and Validation
|
||||
|
||||
### Model Evaluation
|
||||
|
||||
The `ai-model-validation` team created the following library to evaluate the performance of prompt changes as well as model changes. The [Prompt Library README.MD](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/prompt-library/-/blob/main/doc/how-to/run_duo_chat_eval.md) provides details on how to evaluate the performance of AI features.
|
||||
|
||||
> Another use-case for running chat evaluation is during feature development cycle. The purpose is to verify how the changes to the code base and prompts affect the quality of chat responses before the code reaches the production environment.
|
||||
|
||||
For evaluation in merge request pipelines, we use:
|
||||
|
||||
- One click [Duo Chat evaluation](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner)
|
||||
- Automated evaluation in [merge request pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/495410)
|
||||
|
||||
### Seed project and group resources for testing and evaluation
|
||||
|
||||
To seed project and group resources for testing and evaluation, run the following command:
|
||||
|
||||
```shell
|
||||
SEED_GITLAB_DUO=1 FILTER=gitlab_duo bundle exec rake db:seed_fu
|
||||
```
|
||||
|
||||
This command executes the [development seed file](../development_seed_files.md) for GitLab Duo, which creates `gitlab-duo` group in your GDK.
|
||||
|
||||
This command is responsible for seeding group and project resources for testing GitLab Duo features.
|
||||
It's mainly used by the following scenarios:
|
||||
|
||||
- Developers or UX designers have a local GDK but don't know how to set up the group and project resources to test a feature in UI.
|
||||
- Evaluators (e.g. CEF) have input dataset that refers to a group or project resource e.g. (`Summarize issue #123` requires a corresponding issue record in PosstgreSQL)
|
||||
|
||||
Currently, the input dataset of evaluators and this development seed file are managed separately.
|
||||
To ensure that the integration keeps working, this seeder has to create the **same** group/project resources every time.
|
||||
For example, ID and IID of the inserted PostgreSQL records must be the same every time we run this seeding process.
|
||||
|
||||
These fixtures are depended by the following projects:
|
||||
|
||||
- [Central Evaluation Framework](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/prompt-library)
|
||||
- [Evaluation Runner](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner)
|
||||
|
||||
See [this architecture doc](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner/-/blob/main/docs/architecture.md) for more information.
|
||||
|
||||
### Local Development
|
||||
|
||||
A valuable tool for local development to ensure the changes are correct outside of unit tests is to use [LangSmith](duo_chat.md#tracing-with-langsmith) for tracing. The tool allows you to trace LLM calls within Duo Chat to verify the LLM tool is using the correct model.
|
||||
|
||||
To prevent regressions, we also have CI jobs to make sure our tools are working correctly. For more details, see the [Duo Chat testing section](duo_chat.md#prevent-regressions-in-your-merge-request).
|
||||
|
||||
## Monitoring and Metrics
|
||||
|
||||
Monitor the following during migration:
|
||||
|
||||
- **Performance Metrics:**
|
||||
- Error ratio and response latency apdex for each AI action on [Sidekiq Service dashboard](https://dashboards.gitlab.net/d/sidekiq-main/sidekiq-overview)
|
||||
- Spent tokens, usage of each AI feature and other statistics on [periscope dashboard](https://app.periscopedata.com/app/gitlab/1137231/Ai-Features)
|
||||
- [AI gateway logs](https://log.gprd.gitlab.net/app/r/s/zKEel)
|
||||
- [AI gateway metrics](https://dashboards.gitlab.net/d/ai-gateway-main/ai-gateway3a-overview?orgId=1)
|
||||
- [Feature usage dashboard via proxy](https://log.gprd.gitlab.net/app/r/s/egybF)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
stage: AI-powered
|
||||
group: AI Framework
|
||||
info: Any user with at least the Maintainer role can merge updates to this content. For details, see https://docs.gitlab.com/ee/development/development_processes.html#development-guidelines-review.
|
||||
title: Testing and Validation
|
||||
---
|
||||
|
||||
## Testing and validation
|
||||
|
||||
### Model Evaluation
|
||||
|
||||
The `ai-model-validation` team created the following library to evaluate the performance of prompt changes as well as model changes. The [Prompt Library README.MD](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/prompt-library/-/blob/main/doc/how-to/run_duo_chat_eval.md) provides details on how to evaluate the performance of AI features.
|
||||
|
||||
> Another use-case for running chat evaluation is during feature development cycle. The purpose is to verify how the changes to the code base and prompts affect the quality of chat responses before the code reaches the production environment.
|
||||
|
||||
For evaluation in merge request pipelines, we use:
|
||||
|
||||
- One click [Duo Chat evaluation](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner)
|
||||
- Automated evaluation in [merge request pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/495410)
|
||||
|
||||
### Seed project and group resources for testing and evaluation
|
||||
|
||||
To seed project and group resources for testing and evaluation, run the following command:
|
||||
|
||||
```shell
|
||||
SEED_GITLAB_DUO=1 FILTER=gitlab_duo bundle exec rake db:seed_fu
|
||||
```
|
||||
|
||||
This command executes the [development seed file](../development_seed_files.md) for GitLab Duo, which creates `gitlab-duo` group in your GDK.
|
||||
|
||||
This command is responsible for seeding group and project resources for testing GitLab Duo features.
|
||||
It's mainly used by the following scenarios:
|
||||
|
||||
- Developers or UX designers have a local GDK but don't know how to set up the group and project resources to test a feature in UI.
|
||||
- Evaluators (e.g. CEF) have input dataset that refers to a group or project resource e.g. (`Summarize issue #123` requires a corresponding issue record in PosstgreSQL)
|
||||
|
||||
Currently, the input dataset of evaluators and this development seed file are managed separately.
|
||||
To ensure that the integration keeps working, this seeder has to create the **same** group/project resources every time.
|
||||
For example, ID and IID of the inserted PostgreSQL records must be the same every time we run this seeding process.
|
||||
|
||||
These fixtures are depended by the following projects:
|
||||
|
||||
- [Central Evaluation Framework](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/prompt-library)
|
||||
- [Evaluation Runner](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner)
|
||||
|
||||
See [this architecture doc](https://gitlab.com/gitlab-org/modelops/ai-model-validation-and-research/ai-evaluation/evaluation-runner/-/blob/main/docs/architecture.md) for more information.
|
||||
|
||||
### Local Development
|
||||
|
||||
A valuable tool for local development to ensure the changes are correct outside of unit tests is to use [LangSmith](duo_chat.md#tracing-with-langsmith) for tracing. The tool allows you to trace LLM calls within Duo Chat to verify the LLM tool is using the correct model.
|
||||
|
||||
To prevent regressions, we also have CI jobs to make sure our tools are working correctly. For more details, see the [Duo Chat testing section](duo_chat.md#prevent-regressions-in-your-merge-request).
|
||||
|
||||
## Monitoring and Metrics
|
||||
|
||||
Monitor the following during migration:
|
||||
|
||||
- **Performance Metrics:**
|
||||
- Error ratio and response latency apdex for each AI action on [Sidekiq Service dashboard](https://dashboards.gitlab.net/d/sidekiq-main/sidekiq-overview)
|
||||
- Spent tokens, usage of each AI feature and other statistics on [periscope dashboard](https://app.periscopedata.com/app/gitlab/1137231/Ai-Features)
|
||||
- [AI gateway logs](https://log.gprd.gitlab.net/app/r/s/zKEel)
|
||||
- [AI gateway metrics](https://dashboards.gitlab.net/d/ai-gateway-main/ai-gateway3a-overview?orgId=1)
|
||||
- [Feature usage dashboard via proxy](https://log.gprd.gitlab.net/app/r/s/egybF)
|
||||
|
|
@ -452,7 +452,7 @@ GitLab can be considered to have two layers from a process perspective:
|
|||
- [Omnibus](https://github.com/certbot/certbot/blob/master/README.rst)
|
||||
- [Charts](https://github.com/cert-manager/cert-manager/blob/master/README.md)
|
||||
- Configuration:
|
||||
- [Omnibus](https://docs.gitlab.com/omnibus/settings/ssl/index.html)
|
||||
- [Omnibus](https://docs.gitlab.com/omnibus/settings/ssl/)
|
||||
- [Charts](https://docs.gitlab.com/charts/installation/tls.html)
|
||||
- [Source](../install/installation.md#using-https)
|
||||
- [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/nginx.md)
|
||||
|
|
@ -530,7 +530,7 @@ Geo is a premium feature built to help speed up the development of distributed t
|
|||
- [Project page](https://gitlab.com/gitlab-org/ruby/gems/gitlab-exporter)
|
||||
- Configuration:
|
||||
- [Omnibus](../administration/monitoring/prometheus/gitlab_exporter.md)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/gitlab-exporter/index.html)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/gitlab-exporter/)
|
||||
- Layer: Monitoring
|
||||
- Process: `gitlab-exporter`
|
||||
- GitLab.com: [Monitoring of GitLab.com](https://handbook.gitlab.com/handbook/engineering/monitoring/)
|
||||
|
|
@ -542,7 +542,7 @@ GitLab Exporter is a process designed in house that allows us to export metrics
|
|||
- [Project page](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent)
|
||||
- Configuration:
|
||||
- [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/kas/index.html)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/kas/)
|
||||
|
||||
The [GitLab agent](../user/clusters/agent/_index.md) is an active in-cluster
|
||||
component for solving GitLab and Kubernetes integration tasks in a secure and
|
||||
|
|
@ -831,7 +831,7 @@ For monitoring deployed apps, see the [Sentry integration docs](../operations/er
|
|||
- Configuration:
|
||||
- [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template)
|
||||
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/)
|
||||
- [minikube Minimal](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html)
|
||||
- [minikube Minimal](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/)
|
||||
- [Source](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
|
||||
- [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)
|
||||
- Layer: Core Service (Processor)
|
||||
|
|
|
|||
|
|
@ -272,7 +272,7 @@ URLs must be relative. In addition:
|
|||
|
||||
- All links in the data file must end with `.html` (with the exception
|
||||
of `index.html` files), and not `.md`.
|
||||
- For `index.html` files, use the clean (canonical) URL: `path/to/`. For example, `https://docs.gitlab.com/ee/install/index.html` becomes `ee/install/`.
|
||||
- For `index.html` files, use the clean (canonical) URL: `path/to/`. For example, `https://docs.gitlab.com/ee/install/` becomes `ee/install/`.
|
||||
- Do not start any relative link with a forward slash `/`.
|
||||
- As convention, always wrap URLs in single quotes `'url'`.
|
||||
- Always use the project prefix depending on which project the link you add
|
||||
|
|
@ -285,7 +285,7 @@ Examples of relative URLs:
|
|||
| Full URL | Global nav URL |
|
||||
| -------------------------------------------------------------- | ------------------------------------- |
|
||||
| `https://docs.gitlab.com/ee/api/avatar.html` | `ee/api/avatar.html` |
|
||||
| `https://docs.gitlab.com/ee/install/index.html` | `ee/install/` |
|
||||
| `https://docs.gitlab.com/ee/install/` | `ee/install/` |
|
||||
| `https://docs.gitlab.com/omnibus/settings/database.html` | `omnibus/settings/database.html` |
|
||||
| `https://docs.gitlab.com/charts/installation/deployment.html` | `charts/installation/deployment.html` |
|
||||
| `https://docs.gitlab.com/runner/install/docker.html` | `runner/install/docker.html` |
|
||||
|
|
|
|||
|
|
@ -274,7 +274,7 @@ all:
|
|||
|
||||
Now create `charts.yml` in the location specified above and specify tags with a `-fips` suffix.
|
||||
|
||||
See our [Charts documentation on FIPS](https://docs.gitlab.com/charts/advanced/fips/index.html) for more details, including
|
||||
See our [Charts documentation on FIPS](https://docs.gitlab.com/charts/advanced/fips/) for more details, including
|
||||
an [example values file](https://gitlab.com/gitlab-org/charts/gitlab/blob/master/examples/fips/values.yaml) as a reference.
|
||||
|
||||
You can also use release tags, but the versioning is tricky because each
|
||||
|
|
|
|||
|
|
@ -299,8 +299,6 @@ The `trigger_internal_events` matcher can also be used for testing [Haml with da
|
|||
|
||||
Any frontend tracking call automatically passes the values `user.id`, `namespace.id`, and `project.id` from the current context of the page.
|
||||
|
||||
If you need to pass any further properties, such as `extra`, `context`, `label`, `property`, and `value`, you can use the [deprecated snowplow implementation](https://archives.docs.gitlab.com/16.4/ee/development/internal_analytics/snowplow/implementation.html). In this case, let us know about your specific use-case in our [feedback issue for Internal Events](https://gitlab.com/gitlab-org/analytics-section/analytics-instrumentation/internal/-/issues/690).
|
||||
|
||||
#### Vue components
|
||||
|
||||
In Vue components, tracking can be done with [Vue mixin](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/tracking/internal_events.js#L29).
|
||||
|
|
|
|||
|
|
@ -531,7 +531,7 @@ Connect to your GitLab instance via **Bastion Host A** using [SSH Agent Forwardi
|
|||
|
||||
#### Disable Let's Encrypt
|
||||
|
||||
Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/index.html#enable-the-lets-encrypt-integration) when using an `https` domain, so we must explicitly disable it:
|
||||
Because we're adding our SSL certificate at the load balancer, we do not need the GitLab built-in support for Let's Encrypt. Let's Encrypt [is enabled by default](https://docs.gitlab.com/omnibus/settings/ssl/#enable-the-lets-encrypt-integration) when using an `https` domain, so we must explicitly disable it:
|
||||
|
||||
1. Open `/etc/gitlab/gitlab.rb` and disable it:
|
||||
|
||||
|
|
@ -652,7 +652,7 @@ Now that we have our EC2 instance ready, follow the [documentation to install Gi
|
|||
|
||||
#### Add Support for Proxied SSL
|
||||
|
||||
As we are terminating SSL at our [load balancer](#load-balancer), follow the steps at [Supporting proxied SSL](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-a-reverse-proxy-or-load-balancer-ssl-termination) to configure this in `/etc/gitlab/gitlab.rb`.
|
||||
As we are terminating SSL at our [load balancer](#load-balancer), follow the steps at [Supporting proxied SSL](https://docs.gitlab.com/omnibus/settings/ssl/#configure-a-reverse-proxy-or-load-balancer-ssl-termination) to configure this in `/etc/gitlab/gitlab.rb`.
|
||||
|
||||
Remember to run `sudo gitlab-ctl reconfigure` after saving the changes to the `gitlab.rb` file.
|
||||
|
||||
|
|
|
|||
|
|
@ -191,7 +191,7 @@ To set up the GitLab external URL:
|
|||
1. Find `external_url` and replace it with your own domain name. For the sake
|
||||
of this example, use the default domain name Azure sets up.
|
||||
Using `https` in the URL
|
||||
[automatically enables](https://docs.gitlab.com/omnibus/settings/ssl/index.html#lets-encrypt-integration),
|
||||
[automatically enables](https://docs.gitlab.com/omnibus/settings/ssl/#lets-encrypt-integration),
|
||||
Let's Encrypt, and sets HTTPS by default:
|
||||
|
||||
```ruby
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ context of a running container.
|
|||
[SMTP settings](https://docs.gitlab.com/omnibus/settings/smtp.html). The GitLab Docker image
|
||||
doesn't have an SMTP server pre-installed.
|
||||
|
||||
1. If desired [enable HTTPS](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
1. If desired [enable HTTPS](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
1. Save the file and restart the container to reconfigure GitLab:
|
||||
|
||||
|
|
|
|||
|
|
@ -121,7 +121,7 @@ here's how you configure GitLab to be aware of the change:
|
|||
### Configuring HTTPS with the domain name
|
||||
|
||||
Although not needed, it's strongly recommended to secure GitLab with a
|
||||
[TLS certificate](https://docs.gitlab.com/omnibus/settings/ssl/index.html).
|
||||
[TLS certificate](https://docs.gitlab.com/omnibus/settings/ssl/).
|
||||
|
||||
### Configuring the email SMTP settings
|
||||
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ Prerequisites:
|
|||
- Working installation of `kubectl`.
|
||||
- Working installation of Helm, version v3.11.0 or later.
|
||||
|
||||
For more information, see [Test the GitLab chart on GKE or EKS](https://docs.gitlab.com/charts/quickstart/index.html).
|
||||
For more information, see [Test the GitLab chart on GKE or EKS](https://docs.gitlab.com/charts/quickstart/).
|
||||
|
||||
### Add the AI gateway Helm repository
|
||||
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ To adjust Puma settings:
|
|||
|
||||
- For the Linux package, see [Puma settings](../administration/operations/puma.md).
|
||||
- For the GitLab Helm chart, see the
|
||||
[`webservice` chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
|
||||
[`webservice` chart](https://docs.gitlab.com/charts/charts/gitlab/webservice/).
|
||||
|
||||
### Workers
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ As a workaround, do one of the following:
|
|||
- [Adding trusted root certificates to the server](https://manuals.gfi.com/en/kerio/connect/content/server-configuration/ssl-certificates/adding-trusted-root-certificates-to-the-server-1605.html)
|
||||
- [How do you add a certificate authority (CA) to Ubuntu?](https://superuser.com/questions/437330/how-do-you-add-a-certificate-authority-ca-to-ubuntu)
|
||||
- For installations that use the Linux package, add the certificate to the GitLab trusted chain:
|
||||
1. [Install the self-signed certificate](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates).
|
||||
1. [Install the self-signed certificate](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates).
|
||||
1. Concatenate the self-signed certificate with the GitLab trusted certificate.
|
||||
The self-signed certificate might be overwritten during upgrades.
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Error obtaining access token. Cannot access https://gitlab.example.com from Jira
|
|||
- The [Jira issues integration](../_index.md) requires
|
||||
GitLab to connect to Jira. Any TLS issues that arise from a private certificate
|
||||
authority or self-signed certificate are resolved
|
||||
[on the GitLab server](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates),
|
||||
[on the GitLab server](https://docs.gitlab.com/omnibus/settings/ssl/#install-custom-public-certificates),
|
||||
as GitLab is the TLS client.
|
||||
- The Jira development panel requires Jira to connect to GitLab, which
|
||||
causes Jira to be the TLS client. If your GitLab server's certificate is not
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ processes.
|
|||
|
||||
You can perform GitLab Rake tasks by using:
|
||||
|
||||
- `gitlab-rake <raketask>` for [Linux package](https://docs.gitlab.com/omnibus/index.html) and [GitLab Helm chart](https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html#gitlab-specific-kubernetes-information) installations.
|
||||
- `gitlab-rake <raketask>` for [Linux package](https://docs.gitlab.com/omnibus/) and [GitLab Helm chart](https://docs.gitlab.com/charts/troubleshooting/kubernetes_cheat_sheet.html#gitlab-specific-kubernetes-information) installations.
|
||||
- `bundle exec rake <raketask>` for [self-compiled](../install/installation.md) installations.
|
||||
|
||||
## Available Rake tasks
|
||||
|
|
|
|||
|
|
@ -128,7 +128,7 @@ To make full use of Auto DevOps with Kubernetes, you need:
|
|||
|
||||
Your runner must be configured to run Docker, usually with either the
|
||||
[Docker](https://docs.gitlab.com/runner/executors/docker.html)
|
||||
or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/index.html) executors, with
|
||||
or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/) executors, with
|
||||
[privileged mode enabled](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
|
||||
The runners don't need to be installed in the Kubernetes cluster, but the
|
||||
Kubernetes executor is easy to use and automatically autoscales.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ sudo EXTERNAL_URL="http://my-host.internal" dpkg -i <gitlab_package_name>.deb
|
|||
## Enabling SSL
|
||||
|
||||
Follow these steps to enable SSL for your fresh instance. These steps reflect those for
|
||||
[manually configuring SSL in Omnibus's NGINX configuration](https://docs.gitlab.com/omnibus/settings/ssl/index.html#configure-https-manually):
|
||||
[manually configuring SSL in Omnibus's NGINX configuration](https://docs.gitlab.com/omnibus/settings/ssl/#configure-https-manually):
|
||||
|
||||
1. Make the following changes to `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
|
|
|
|||
|
|
@ -522,7 +522,7 @@ As a final step in the deployment phase, you must establish a solution to monito
|
|||
- Network utilization
|
||||
- Disk utilization
|
||||
|
||||
See the [Dedicated GitLab Runner monitoring page](https://docs.gitlab.com/runner/monitoring/index.html) for more details on how to proceed.
|
||||
See the [Dedicated GitLab Runner monitoring page](https://docs.gitlab.com/runner/monitoring/) for more details on how to proceed.
|
||||
|
||||
## Optimize
|
||||
|
||||
|
|
|
|||
|
|
@ -171,7 +171,7 @@ To address the above two scenarios, it is advised to do the following prior to u
|
|||
|
||||
1. Wait until all jobs are finished.
|
||||
1. Upgrade GitLab.
|
||||
1. [Upgrade GitLab Runner](https://docs.gitlab.com/runner/install/index.html) to the same version
|
||||
1. [Upgrade GitLab Runner](https://docs.gitlab.com/runner/install/) to the same version
|
||||
as your GitLab version. Both versions [should be the same](https://docs.gitlab.com/runner/#gitlab-runner-versions).
|
||||
1. Unpause your runners and unblock new jobs from starting by reverting the previous `/etc/gitlab/gitlab.rb` change.
|
||||
|
||||
|
|
|
|||
|
|
@ -1111,6 +1111,29 @@ For GitLab Self-Managed administrators, you can configure a custom limit with th
|
|||
|
||||
<div class="deprecation breaking-change" data-milestone="18.0">
|
||||
|
||||
### Major update of the Prometheus subchart
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
||||
- Announced in GitLab <span class="milestone">17.9</span>
|
||||
- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
|
||||
- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/5927).
|
||||
|
||||
</div>
|
||||
|
||||
With GitLab 18.0 and GitLab chart 9.0, the Prometheus subchart will be updated from 15.3 to 27.3.
|
||||
Along with this update, Prometheus 3 will be shipped by default.
|
||||
|
||||
Manual steps are required to perform the upgrade. If you have Alertmanager, Node Exporter or
|
||||
Pushgateway enabled, you will also need to update your Helm values.
|
||||
|
||||
Please refer to the [migration guide](https://docs.gitlab.com/charts/releases/9_0.html#prometheus-upgrade)
|
||||
for more information.
|
||||
|
||||
</div>
|
||||
|
||||
<div class="deprecation breaking-change" data-milestone="18.0">
|
||||
|
||||
### OpenTofu CI/CD template
|
||||
|
||||
<div class="deprecation-notes">
|
||||
|
|
@ -1655,7 +1678,7 @@ SLES 15 SP6 for continued support.
|
|||
|
||||
</div>
|
||||
|
||||
The SpotBugs [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/index.html#supported-languages-and-frameworks)
|
||||
The SpotBugs [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)
|
||||
can perform a build when the artifacts to be scanned aren't present. While this usually works well for simple projects, it can fail on more complex builds.
|
||||
|
||||
From GitLab 18.0, to resolve SpotBugs analyzer build failures, you should:
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ sudo gitlab-rake gitlab:check SANITIZE=true
|
|||
|
||||
For more information on:
|
||||
|
||||
- Using `gitlab-ctl` for maintenance, see [Maintenance commands](https://docs.gitlab.com/omnibus/maintenance/index.html).
|
||||
- Using `gitlab-ctl` for maintenance, see [Maintenance commands](https://docs.gitlab.com/omnibus/maintenance/).
|
||||
- Using `gitlab-rake` for configuration checking, see
|
||||
[Check GitLab configuration](../../administration/raketasks/maintenance.md#check-gitlab-configuration).
|
||||
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ You can use agents and receptive agents simultaneously.
|
|||
GitLab supports the following Kubernetes versions. If you want to run
|
||||
GitLab in a Kubernetes cluster, you might need a different version of Kubernetes:
|
||||
|
||||
- For the [Helm Chart](https://docs.gitlab.com/charts/installation/cloud/index.html).
|
||||
- For the [Helm Chart](https://docs.gitlab.com/charts/installation/cloud/).
|
||||
- For [GitLab Operator](https://docs.gitlab.com/operator/installation.html).
|
||||
|
||||
You can upgrade your
|
||||
|
|
|
|||
|
|
@ -381,7 +381,7 @@ Examples:
|
|||
<!--
|
||||
The "2." and "4." in the example above are changed to "1." below, to match the style
|
||||
standards on docs.gitlab.com.
|
||||
See https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#lists
|
||||
See https://docs.gitlab.com/ee/development/documentation/styleguide/#lists
|
||||
-->
|
||||
|
||||
1. First ordered list item
|
||||
|
|
@ -415,7 +415,7 @@ They can even:
|
|||
<!--
|
||||
The "*" and "+" in the example above are changed to "-" below, to match the style
|
||||
standards on docs.gitlab.com.
|
||||
See https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#lists
|
||||
See https://docs.gitlab.com/ee/development/documentation/styleguide/#lists
|
||||
-->
|
||||
|
||||
Unordered lists can:
|
||||
|
|
|
|||
|
|
@ -213,5 +213,5 @@ deploy:
|
|||
|
||||
NOTE:
|
||||
This example explicitly calls `docker pull`. If you prefer to implicitly pull the container image using `image:`,
|
||||
and use either the [Docker](https://docs.gitlab.com/runner/executors/docker.html) or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/index.html) executor,
|
||||
and use either the [Docker](https://docs.gitlab.com/runner/executors/docker.html) or [Kubernetes](https://docs.gitlab.com/runner/executors/kubernetes/) executor,
|
||||
make sure that [`pull_policy`](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work) is set to `always`.
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue