summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/GitLab.mdwn
blob: ec1638c9d7d623756f1918f180be4f0a607adf28 (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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
This is about migrating our data and workflow from Redmine to GitLab,
which is tracked as [[!tails_ticket 15878]].

[[!toc levels=3]]

# Issues tracking

## Private issues

One can make an issue
[confidential](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html)
when creating it; confidentiality can later be toggled on/off at any
time. A aonfidential issue is visible only by whoever created it and
by project members with at least
[Reporter](https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions) access.

Given "Reporter" access is needed for lots of relatively basic
operations, such as labelling and assigning issues, presumably most
active Tails contributors would get at least this access level on the
`tails-team/tails` project, and then in turn access to this project's
confidential issues. So Tails teams that need to further restrict
access to their confidential issues will need to track their issues
under their own `tails-team/$project`.

# Merge requests

The [Protected branch
flow](https://docs.gitlab.com/ce/user/project/merge_requests/authorization_for_merge_requests.html#protected-branch-flow)
is probably the most adequate for regular contributors, since it's the
least disruptive in terms of workflow and habits and requires less
work to adjust our Jenkins CI setup:

 - We mark our main branches (`stable`, `testing`, `devel`,
   `feature/buster`) as "Protected". We give "Maintainer" access to
   people allowed to push to these branches, i.e. what we previously
   called "commit access".
 - The Git workflow remains unchanged for regular developers who are
   not granted full commit access: they get "Developer" access, can
   push a topic branch to the canonical Git repository and our CI will
   pick it up. The only difference is that they are not restricted to
   pushing to their own `$nickname/*` namespace, which makes things
   simpler and has other advantages, e.g. they can use the `wip/`
   prefix (so our Jenkins CI ignores the branch) and collaborate with
   others on shared branches.
 - Other contributors get access strictly lower than "Developer".
   They push topic branches to their own fork of the repository and
   create merge requests.
 - Our current Jenkins CI jobs generation process remains unchanged.
   (Technically, we could adjust it so it generates CI jobs for _any_
   merge request (based on `refs/merge-requests/*/head`), but this
   would give arbitrary code execution on our CI to _anyone_.
   Our infrastructure is not currently equipped to cope with this.)

# Importing data from Redmine

## Specification

### To be triaged

Relevant features — to be triaged as MUST/SHOULD/MAY:

* Preserve issue IDs so `#nnnn` should retain its meaning and links
  like [[!tails_ticket 15878]] can be easily redirected.
* Preserve issue private/public status.
* Convert Textile to Markdown.

## Tools

A number of tools are available online.

These data migration tools come in various shape and some don't
support GitLab API v4, but generally there's a fork on GitHub that
fixes the most critical problems. Start there, explore the network
of forks, and follow the white GitHub rabbit(-hole):

* <https://github.com/redmine-gitlab-migrator/redmine-gitlab-migrator>
* <https://github.com/ultreia-io/migrate-redmine-to-gitlab>