[tor-project] oniongit update

[Silvia]

Hi Isis,

Reply in line

On 20/07/17 02:16, isis agora lovecruft wrote:
> 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?


No, it is not a lot of work, in fact the branch it is just a target. It
is possible to say that the pipeline has to run for specific tags or
specific branches.


>
> 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.)


So what we can do is make sure the branch can be merged, but we do not
want to push to torgit as part of the CI in oniongit. Unless we could be
ok with automatic pushes on private repos. But even though, in order for
the CI to push to a different repo you would have to set up your ssh key
on the platform (as you would do on github). I do not think we can be
confy w/ this setup.


>> 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


Yes, we can defo reuse that. Also, the travis setup could be something
we could keep for external contributors and use our own runners for
people in the network group on oniongit. I'll work on this.


>
>> Another update that you might find interesting is the possibility to set
>> up confidential issues (although some have rightly said that they do not
>> feel comfortable having a web up handling confidential bugs).
>>
>> [Please see
>> https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html]
>>
>> An issue that was also raised since the beginning regarding Trac vs
>> Gitlab is the possibility to have components vs keywords vs labels. In
>> gitlab everything is done w/ labels, so keep that in mind if you are
>> thinking to test issues tracking in oniongit.
>>
>> [More on: https://docs.gitlab.com/ce/user/project/labels.html]
>>
>> [More on gitlab flow features here:
>> https://docs.gitlab.com/ce/workflow/README.html]
>>
>> Please let me know if you'd like to have an account on oniongit or if
>> you'd like to report any problems that you have found.
>>
>> Talk soon,
>> -hiro
>> _______________________________________________
>> tor-project mailing list
>> tor-project at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
>
>
> _______________________________________________
> tor-project mailing list
> tor-project at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20170720/a3354d31/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20170720/a3354d31/attachment.sig>