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.
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.)
I make sure tests are passing and then push `bug22636_0.2.4` to git.torproject.org/user/isis/tor.git.
Someone reviews the changes between that branch and its base (in this case `maint-0.2.4`).
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_...
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project