diff options
| author | Timothy Andrew <mail@timothyandrew.net> | 2016-08-04 09:55:02 +0530 |
|---|---|---|
| committer | Timothy Andrew <mail@timothyandrew.net> | 2016-08-04 10:39:30 +0530 |
| commit | 8e13162ae112c4c72ee269de0c7f58bfd675fa52 (patch) | |
| tree | bb00585b5fb569c8ad221de5d3ebffc55059b5ad /config | |
| parent | 532202a5278a622de874b9dfc1c4f7fe9ddf5ce4 (diff) | |
| download | gitlab-ce-8e13162ae112c4c72ee269de0c7f58bfd675fa52.tar.gz | |
Migrate protected branch access levels to match constants in `Gitlab::Access`20609-fix-protected-branch-access-levels-migration
- In the final round of review (!5081), we moved the protected branch
access levels from Rails enums to constants from Gitlab::Access.
- The migrations that moved us from the old data model (a single
protected_branches table with developers_can_push and
developers_can_merge flags) to the new one (separate tables for
push_access_levels and merge_access_levels) was not updated.
- These migrations still used 0 to mean "Masters" and 1 to mean
"Developers" (matching the previous Rails enum), while Gitlab::Access
uses 40 and 30 for these, respectively.
- Once the migrations run, our data gets into a broken state.
- We fix this by migrating all `0`s to `40` and all `1`s to `30`.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/20606#note_13561628
= Caveats =
- In Gitlab::Access, 0 represents NO_ACCESS. When we run this migration,
all protected branches with "No one" as an access level will be
changed to "Masters"
Diffstat (limited to 'config')
0 files changed, 0 insertions, 0 deletions