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. 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. 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. 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
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_...
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
-- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
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_...
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
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_...
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
On 20 Jul 2017, at 03:19, Silvia [Hiro] <hiro@torproject.org> wrote:
Hey everyone, I just wanted to send a quick update regarding oniongit and gitlab in general.
...
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.
A cypherpunks just complained that oniongit.eu requires JavaScript: https://trac.torproject.org/projects/tor/ticket/22542#comment:15 I tested this on gitlab.com (I don't have an oniongit account), and it is impossible to use GitLab without JavaScript on. (I can log in, but 2FA doesn't work, and neither does the issue tracker.) Do we want to make everyone who uses our bug tracker use JavaScript? Are there other ways that people can interact with oniongit.eu that don't require JavaScript? Is this a show-stopper for anyone? I would prefer to avoid JavaScript personally, but not so much that I would stop using the platform. But it concerns me that we would be excluding a significant number of people. Trac works fine without JavaScript, and only uses JavaScript to add a few features (like duplicate issue searches, smarter component selection, and mass ticket editing). T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 31 Jul 2017, at 10:48, teor <teor2345@gmail.com> wrote:
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.
A cypherpunks just complained that oniongit.eu requires JavaScript:
https://trac.torproject.org/projects/tor/ticket/22542#comment:15
I tested this on gitlab.com (I don't have an oniongit account), and it is impossible to use GitLab without JavaScript on. (I can log in, but 2FA doesn't work, and neither does the issue tracker.)
A follow-up: This likely makes it impossible for search engines to index our bug tracker. Trac is indexed fine by search engines. Although badly-coded bots sometimes create excess load. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
On 31 Jul (19:28:59), teor wrote:
On 31 Jul 2017, at 10:48, teor <teor2345@gmail.com> wrote:
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.
A cypherpunks just complained that oniongit.eu requires JavaScript:
https://trac.torproject.org/projects/tor/ticket/22542#comment:15
I tested this on gitlab.com (I don't have an oniongit account), and it is impossible to use GitLab without JavaScript on. (I can log in, but 2FA doesn't work, and neither does the issue tracker.)
A follow-up:
This likely makes it impossible for search engines to index our bug tracker.
Gitlab bugs work without JS, you just can't really interact with them. Here is an example from Riseup Gitlab that I found through Google which is indexing the content. https://0xacab.org/riseup/0xacab/issues/5 I do share the concern that anyone without JS can't comment or open a ticket with Gitlab... We'll suffer through that for all possible solutions we want :S... I personally do enable JS on trac.tpo voluntarily so I'm "fine" with it but that doesn't really matter for the rest reporting bugs :S... I recall also someone reviewing some HS code and wasn't able to use Gitlab because javascript and wasn't super pleased but understood the need for the review tool. The review code tool, people will have to suffer through it (including us) with javascript but I'm less easy with "reporting a bug requires JS" ... This is maybe something we could start talking with Gitlab people on if they could make it that someone can open and comment on a ticket without js to the cost of losing some fancy functionnality such has "tagging with 4k emojis". Although, I kind of have little hope there... Cheers! David
Trac is indexed fine by search engines. Although badly-coded bots sometimes create excess load.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
-- EMlsvWMmaQ7Dj/n+fwPuCY+BUG0E6RTlyVVTtCt459I=
Hi, replying below. On 31/07/17 19:16, David Goulet wrote:
On 31 Jul (19:28:59), teor wrote:
On 31 Jul 2017, at 10:48, teor <teor2345@gmail.com> wrote:
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.
A cypherpunks just complained that oniongit.eu requires JavaScript:
https://trac.torproject.org/projects/tor/ticket/22542#comment:15
I tested this on gitlab.com (I don't have an oniongit account), and it is impossible to use GitLab without JavaScript on. (I can log in, but 2FA doesn't work, and neither does the issue tracker.)
A follow-up:
This likely makes it impossible for search engines to index our bug tracker.
Gitlab bugs work without JS, you just can't really interact with them. Here is an example from Riseup Gitlab that I found through Google which is indexing the content.
https://0xacab.org/riseup/0xacab/issues/5
I do share the concern that anyone without JS can't comment or open a ticket with Gitlab... We'll suffer through that for all possible solutions we want :S...
+1 on this.
I personally do enable JS on trac.tpo voluntarily so I'm "fine" with it but that doesn't really matter for the rest reporting bugs :S... I recall also someone reviewing some HS code and wasn't able to use Gitlab because javascript and wasn't super pleased but understood the need for the review tool. The review code tool, people will have to suffer through it (including us) with javascript but I'm less easy with "reporting a bug requires JS" ...
This is maybe something we could start talking with Gitlab people on if they could make it that someone can open and comment on a ticket without js to the cost of losing some fancy functionnality such has "tagging with 4k emojis". Although, I kind of have little hope there...
If we really want this, I could get in touch with gitlab people or even see if I could provide a patch to have gitlab work withou JS. Talk more soon, -hiro
Cheers! David
Trac is indexed fine by search engines. Although badly-coded bots sometimes create excess load.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
_______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
Hi all, I have heard back from gitlab after reaching out directly w/ an issue on their codebase (using the support forums is not the best options). They have no intentions to support a version that works w/ JS disabled. We should now decide if we want to continue w/ oniongit or find alternatives. I think patching it on our own is not an option. Some other option could be to use a cli (https://about.gitlab.com/applications/) or wrap a no JS small UI using the APIs. -hiro On 31/07/17 21:30, isabela wrote:
On 7/31/17 15:17, Silvia [Hiro] wrote:
If we really want this, I could get in touch with gitlab people or even see if I could provide a patch to have gitlab work withou JS.
Talk more soon, -hiro This is awesome hiro :) lets talk about it on august 7th meeting o/
tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
participants (6)
-
David Goulet -
isabela -
isis agora lovecruft -
Silvia -
Silvia [Hiro] -
teor