Silvia [Hiro] transcribed 2.7K bytes:
Hey everyone,
I just wanted to send a quick update regarding oniongit and gitlab in
general.
So a main issue when teams started testing oniongit was the possibility
to automatically sync repos on oniongit w/ repos on torgit.
The idea is always that torgit is pulled by oniongit. This way oniongit
doesn't write to our git repositories, but we can run code reviews with
updated branches.
There are mainly two ways how this can be achieved. The first
possibility is that torgit push to oniongit whenever master is updated
(with a post-receive hook maybe).
The other possibility is that a pipeline (gitlab CI feature) is set up
on oniongit to pull periodically from torgit and update the master branch.
Is it possible to have all branches synced? Is that a lot of work?
For example, on the network team, we have (at least) two workflows:
one for features going into the next (or some future release), and the
other for bugfixes and things that should get backported. The first
has its development done in a branch based on master, but in a
developer's personal repo/fork. The second has it's development done
in a branch based off a `maint-*` branch. So like for example, for
the second case (since that's more complicated), a workflow might go
like:
-1) (This step is just something I do personally.) I start working on
#22636, and I make a branch called `bug22636` and push one commit at a
time to github.com/isislovecruft/tor.git in order to trigger Travis CI
builds for each commit as I'm working.
0) I decide my branch is done, tests are passing, and that it should
be backported to versions 0.2.4 - 0.3.0, so I make a new branch
`bug22636_0.2.4` and rebase it onto `maint-0.2.4`. (Again, this
is just me, but at this point I'd push the backport branch to
Github to trigger another CI build.)
1) I make sure tests are passing and then push `bug22636_0.2.4` to
git.torproject.org/user/isis/tor.git.
2) Someone reviews the changes between that branch and its base (in
this case `maint-0.2.4`).
3) Depending on review:
a) If review is good, `bug22636_0.2.4` is merged into `maint-0.2.4`
(and in this case, since it's a backport, also to
`maint-0.2.{5,6,7,8,9}` and `maint-0.3.0`).
b) Otherwise, I have to add more commits to `bug22636_0.2.4` and
goto step #2 until the reviewer is happy. (Again, this is just
me: I push commits one at a time to Github to trigger CI before
pushing anything to git.torproject.org.)
Note that if you wanted the pipeline could also run a set of tests on
the branch since this is basically a docker runner that does this on a
separated server.
Yes, this would be awesome! Could we get this to run for all
branches? Also for developer's repos?
Taylor made a ticket for getting this set up:
https://trac.torproject.org/projects/tor/ticket/22891
I am in the process of documenting how this can be done. In the meantime
please let me know if you'd like me to set it up for you.
We can probably reuse a pretty similar configuration as for the Travis
CI configs that Patrick O'Doherty and I made:
https://gitweb.torproject.org/user/isis/tor.git/tree/.travis.yml?h=bug22636_0.3.1_squashed