Hi guys,
at our wonderful OsmoDevCon 2016 we have decided to give a Gerrit based workflow a try. Right now the components are set-up and we need to figure out where to start, how to integrate and then also how to migrate.
URL:
https://gerrit.osmocom.org will host our installation of Gerrit.
Authentication:
It is using the OpenID authentication scheme to register to it. I have found and massaged a redmine plugin to turn our redmine into an OpenID provider[1].
Set-up/ACLs:
There is a complex set of rules for ACLs. In terms of user branches it will be the easiest if they are located at "user/*" instead of our current "*" scheme. For a transition period we can continue to allow to push directly into gerrit as well.
Registering:
https://gerrit.osmocom.org/login, sign-in with your OpenID provider. And then set a username (this will be used for the git log-in). Register additional email addresses and install your ssh key.
Projects:
I have currently created "osmo-ci" for some CI scripts and Dockerfiles and started to play with it, e.g. using git to manage notifications of this project.
Jenkins:
http://jenkins.osmocom.org/jenkins/job/osmo-pcpap-gerrit/16/ is an example of a build triggered (and failed and reported as failure) to the Gerrit installation.
Tricks:
$ git ls-remote gerrit ... 5f3b6b8472a319d8d1184266cf9f80b5dbb709b6 refs/changes/23/23/1
'23' the 'hashed' structure '23' the actual change #23 '1' the first patch
so one can use git fetch to fetch the patchset and browse
$ ssh -p 29418 zecke@gerrit.osmocom.org gerrit --help
Next:
We need to pick some projects to start with. I would propose to start with libosmocore and OpenBSC or one of the two.
Approach:
Regardless of what we start with the approach would be:
* Create project on Gerrit * Make current code available to gerrit * Set-up jenkins integration * Remove all but gerrit's push right for this specific repository * Set-up replication
What is missing:
* Which projects to migrate when * Gerrit / Jenkins integration * Gerrit => git.osmocom.org replication (and github?) * Additional build jobs (with docker). Decision if we * Group set-up if we want fine-grained review per project. I think we can start without. * Create wiki page/documentation
sorry, the mail is a bit too long.
holger
[1] Don't trust it as your general ID provider, but you might prefer using it for gerrit instead of yahoo or canonical. The URL is https://osmocom.org/openid. The heavy lifting is done by a ruby library (which has some DH code.. but I didn't see a configure knob to change the prime.. so probably everyone is using https://openid.net/specs/openid-authentication-2_0.html#pvalue?
Hi Holger,
thanks for getting this started.
On Wed, May 04, 2016 at 12:08:56AM +0200, Holger Freyther wrote:
There is a complex set of rules for ACLs. In terms of user branches it will be the easiest if they are located at "user/*" instead of our current "*" scheme.
works for me. it can probably be extended to group/* for the fairwaves/sysmocom branches, once there are groups defined with the respective developers? I think it is fair to simply rename the current branches when doing the import.
For a transition period we can continue to allow to push directly into gerrit as well.
Not sure if this has any risks?
https://gerrit.osmocom.org/login, sign-in with your OpenID provider. And then set a username (this will be used for the git log-in). Register additional email addresses and install your ssh key.
thanks, worked for me.
We need to pick some projects to start with. I would propose to start with libosmocore and OpenBSC or one of the two.
I would say let's do it for all the libraries and openbsc.git at the same time. Often, our changes affect libosmocore and -abis, and it would be odd to submit some changes one way, and some the other way. We might also use it for osmo-bts and osmo-pcu at the same time, for the same reason.
I'm more in favor of a "transition once, even if it causes fall out" than a "transition slowly with changes every week/month" approach.
So my proposal would be to do all the projects below in one go: * libosmocore.git * libosmo-abis.git * libosmo-netif.git * libsmpp34.git * openbsc.git * osmo-bts.git * osmo-iuh.git * osmo-pcu.git
- Which projects to migrate when
see above for my initial proposal
- Additional build jobs (with docker). Decision if we
if we?
Regards, Harald
On 04 May 2016, at 12:15, Harald Welte laforge@gnumonks.org wrote:
Hi Holger,
works for me. it can probably be extended to group/* for the fairwaves/sysmocom branches, once there are groups defined with the respective developers? I think it is fair to simply rename the current branches when doing the import.
If you go to Projects -> All Projects and then to the "Access" (ACL) you see which bits we can set. Yes, we can easily introduce group/*. The ACL is in the end a text file that is managed with git as well.
Yes, but we can keep the old branches around? What is the benefit of renaming (if something points to it?)
For a transition period we can continue to allow to push directly into gerrit as well.
Not sure if this has any risks?
no risk. Maybe the easiest to get used to the system without having to wait for the review.
So my proposal would be to do all the projects below in one go:
- libosmocore.git
- libosmo-abis.git
- libosmo-netif.git
- libsmpp34.git
- openbsc.git
- osmo-bts.git
- osmo-iuh.git
- osmo-pcu.git
- Which projects to migrate when
see above for my initial proposal
Okay. Switch by next Monday or is that too quick?
- Additional build jobs (with docker). Decision if we
if we?
good point. It got late yesterday. Decision if we run tests on more nodes and if one needs to be in a "trusted" group to benefit from the jenkins integration. But we will have a dedicated build machine anyway.. so if it is abused... harm will be limited.
holger
-
Harald Welte -
Holger Freyther