<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Isis,<br>
    <br>
    Reply in line<br>
    <br>
    <div class="moz-cite-prefix">On 20/07/17 02:16, isis agora lovecruft
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20170720001648.GB1913@patternsinthevoid.net">
      <pre wrap="">Silvia [Hiro] transcribed 2.7K bytes:
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
Is it possible to have all branches synced?  Is that a lot of work?</pre>
    </blockquote>
    <br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:20170720001648.GB1913@patternsinthevoid.net">
      <pre wrap="">

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.)
</pre>
    </blockquote>
    <br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:20170720001648.GB1913@patternsinthevoid.net">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
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:
<a class="moz-txt-link-freetext" href="https://trac.torproject.org/projects/tor/ticket/22891">https://trac.torproject.org/projects/tor/ticket/22891</a>

</pre>
      <blockquote type="cite">
        <pre wrap="">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.
</pre>
      </blockquote>
      <pre wrap="">
We can probably reuse a pretty similar configuration as for the Travis
CI configs that Patrick O'Doherty and I made:
<a class="moz-txt-link-freetext" href="https://gitweb.torproject.org/user/isis/tor.git/tree/.travis.yml?h=bug22636_0.3.1_squashed">https://gitweb.torproject.org/user/isis/tor.git/tree/.travis.yml?h=bug22636_0.3.1_squashed</a></pre>
    </blockquote>
    <br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote type="cite"
      cite="mid:20170720001648.GB1913@patternsinthevoid.net">
      <pre wrap="">

</pre>
      <blockquote type="cite">
        <pre wrap="">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
<a class="moz-txt-link-freetext" href="https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html">https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html</a>]

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: <a class="moz-txt-link-freetext" href="https://docs.gitlab.com/ce/user/project/labels.html">https://docs.gitlab.com/ce/user/project/labels.html</a>]

[More on gitlab flow features here:
<a class="moz-txt-link-freetext" href="https://docs.gitlab.com/ce/workflow/README.html">https://docs.gitlab.com/ce/workflow/README.html</a>]

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
<a class="moz-txt-link-abbreviated" href="mailto:tor-project@lists.torproject.org">tor-project@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
tor-project mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-project@lists.torproject.org">tor-project@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>