blob: 228ed3fc1921efc789dbf1bf3387106a72783e0a (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
# frozen_string_literal: true
GITALY_COORDINATION_MESSAGE = <<~MSG
## Changing Gitaly version
This merge request requires coordination with Gitaly deployments. You must assert why this change is safe.
If these two assertions can be made, then this change is safe:
1. No Gitaly definitions that have been removed in the version bump are in use on the Rails side.
1. No Gitaly definitions that are not yet part of a released version become used without a feature flag.
In general, we can ignore the first assertion because the specs will fail as needed. If a GitLab Rails spec
exercises a definition that is removed in the new Gitaly version, then that
spec will fail.
You must confirm the second assertion. Failing to do so will introduce a [non
backward compatible change](https://docs.gitlab.com/ee/development/multi_version_compatibility.html),
for example during canary deployment of GitLab.com, which can cause an incident.
This type of problem can also impact customers performing zero-downtime upgrades.
Some options:
- This change does not cause Rails to use a new definition.
- This change causes Rails to use a new definition, but only behind a feature flag which is disabled by default.
This feature flag must only be removed in a subsequent release.
MSG
changed_lines = helper.changed_lines('Gemfile.lock')
if changed_lines.any? { |line| line =~ /^\+\s+gitaly \(/ }
warn 'Changing gitaly gem can cause a multi-version incompatibility incident'
markdown(GITALY_COORDINATION_MESSAGE)
end
|
