Proposal: gitlab.com/baserock/definitions as definitions canonical source (was Re: RFC: Gitlab Implementation)
5:59 p.m.
Hi all,
On 4 July 2016 at 17:35, Javier Jardón <jjardon(a)gnome.org> wrote:
On 3 July 2016 at 14:20, Javier Jardón <jjardon(a)gnome.org>
wrote:
> I personally like gitlab for its simplicity so this morning I went
> ahead and I setup a ci/cd pipeline in a mirror of definitions in
> gitlab.com [1]
> To make things easier it would be great if you can review this patch
> [2] to add .gitlab-ci.yml in the master branch of definitions.
> In this way the ci pipeline will be automatically triggered after any change.
<snip>
> [1] https://gitlab.com/jjardon/baserock-definitions/pipelines/3636171
> [2] https://gerrit.baserock.org/#/c/2194/
This is merged now, thanks for the quick reviews!
Pipelines will be automatically generated here [1] with any change in
master of definitions
If you want to give a try to this ci system: the only thing you have
to do is create a branch from master of definitions in gitlab,
make your changes and push it. A pipeline will be automatically created
Cheers,
Javier
[1] https://gitlab.com/baserock/definitions/pipelines
Since I presented this demo in July, I've improved the CI pipeline a
little so now we have elastic runners; this means that we will
generate build machines on demand, while keeping the free runners
offered by gitlab.com as a backup.
This will save us resources and we can adjust the capabilities of the
machines as we wish (the machines are generated from a DigitalOcean
account)
We also have a ARM runner but I've had to disable it at the moment
because some problems cloning git repos [1]
Therefore, and after some people have been playing with the system for
a while with mostly positive feedback, I'd like to propose
gitlab.com/baserock/definitions as the canonical source for
definitions.
By doing so we will have the most important feature we were wanting for a
long time (and one of the main reason we switched to gerrit):
- Pre-merge testing of all the system we are interested on
There are myriad other gitlab features we can use (issue
tracker... ), but I think this is the most important one for this
discussion
Let me know what you think
Cheers,
Javier
[1]
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
6:45 p.m.
On 27 October 2016 at 16:59, Javier Jardón <jjardon(a)gnome.org> wrote:
Hi all,
<snip>
Since I presented this demo in July, I've improved the CI pipeline a
little so now we have elastic runners; this means that we will
generate build machines on demand, while keeping the free runners
offered by gitlab.com as a backup.
This will save us resources and we can adjust the capabilities of the
machines as we wish (the machines are generated from a DigitalOcean
account)
We also have a ARM runner but I've had to disable it at the moment
because some problems cloning git repos [1]
Therefore, and after some people have been playing with the system for
a while with mostly positive feedback, I'd like to propose
gitlab.com/baserock/definitions as the canonical source for
definitions.
By doing so we will have the most important feature we were wanting for a
long time (and one of the main reason we switched to gerrit):
- Pre-merge testing of all the system we are interested on
There are myriad other gitlab features we can use (issue
tracker... ), but I think this is the most important one for this
discussion
Let me know what you think
Cheers,
Javier
[1]
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
To clarify this a little more, the only change I'm requesting here is
to stop mirroring the g.b.o definitions repo into
gitlab.com/baserock/definitions
So to make a change in definitions, the process would as simple as:
- Create branch in gitlab.com/baserock/definition -> test branch in
the gitlab ci -> Create Merge request -> review -> patch is applied to
master
(currently the patches have to be send to gerrit and then wait for the
change to be mirrored in gitlab)
I'd like to do this change on a week counting from today (so next
Friday 4th of October)
Let me know if you have any objection for this to not happen
Cheers,
Javier
12:47 p.m.
On 2016-10-28 17:45, Javier Jardón wrote:
> [1]
>
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
To clarify this a little more, the only change I'm requesting here is
to stop mirroring the g.b.o definitions repo into
gitlab.com/baserock/definitions
So to make a change in definitions, the process would as simple as:
- Create branch in gitlab.com/baserock/definition -> test branch in
the gitlab ci -> Create Merge request -> review -> patch is applied to
master
(currently the patches have to be send to gerrit and then wait for the
change to be mirrored in gitlab)
I'd like to do this change on a week counting from today (so next
Friday 4th of October)
Let me know if you have any objection for this to not happen
I'm happy with your proposed change, but I think there are a few more
general implications:
1) as discussed on irc, gitlab services will require
maintenance/security updates etc
- review gitlab setup with infra team
- establish who will maintain, and how
2) new canonical upstream location for definitions
- abandon any in-progress patches/reviews in gerrit, or bring them
across to gitlab
- update the wiki for contributors, and all references to definitions
- add a lorry file for definitions itself, to land at its new mirror
location, which i expect would be
https://git.baserock.org/delta/definitions
3) other projects that have up to now been reviewed via the gerrit
- https://gerrit.baserock.org/#/admin/projects/
- i assume the logical implication is to migrate those too?
- and then deprecate the gerrit, take down the service, decommission
whatever's hosting it?
4) turn git.baserock.org into a strict mirror? or establish a new
mirror-only service?
- historically we've pushed branches to g.b.o (eg when we've had to
patch upstream for baserock builds)
- in discussion with users, some have expressed a preference that troves
would act as pure mirrors
- so any work we or they would need to do, would happen elsewhere (say
on a gitlab server), and thereafter be mirrored into the trove
Clearly your proposed transition could happen without resolving all of
the above, but we should aim to minimise confusion and tidy things up as
we go if possible.
br
Paul
11:37 a.m.
Hi Paul,
On 30 October 2016 at 11:47, Paul Sherwood <paul.sherwood(a)codethink.com> wrote:
On 2016-10-28 17:45, Javier Jardón wrote:
>>
>> [1]
>>
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
>
>
> To clarify this a little more, the only change I'm requesting here is
> to stop mirroring the g.b.o definitions repo into
> gitlab.com/baserock/definitions
> So to make a change in definitions, the process would as simple as:
>
> - Create branch in gitlab.com/baserock/definition -> test branch in
> the gitlab ci -> Create Merge request -> review -> patch is applied to
> master
>
> (currently the patches have to be send to gerrit and then wait for the
> change to be mirrored in gitlab)
>
> I'd like to do this change on a week counting from today (so next
> Friday 4th of October)
> Let me know if you have any objection for this to not happen
I'm happy with your proposed change, but I think there are a few more
general implications:
1) as discussed on irc, gitlab services will require maintenance/security
updates etc
- review gitlab setup with infra team
- establish who will maintain, and how
No maintenance is required if we store the projects in gitlab.com.
Some people seems to have interest on have our own gitlab instance but
Its not what Im suggesting here (although for sure It can be done in
the future if there is enough intesrest)
If we want to use our own runners, then the only maintenance required
is for the "manager" runner that will spin up the other runners on
demand.
So, the maintenance would be keep that machine updated + gitlab-runner
software up-to-date + toml config file (which should not change much)
(Ive attached it so you can have a look to it)
I already volunteer to do this work if nobody is available at the moment
2) new canonical upstream location for definitions
- abandon any in-progress patches/reviews in gerrit, or bring them across to
gitlab
Yeah, this should be easy; there are actually only a few patches being
actively on review at the moment
- update the wiki for contributors, and all references to definitions
Yes, we can do this over the weekend
- add a lorry file for definitions itself, to land at its new mirror
location, which i expect would be
https://git.baserock.org/delta/definitions
Sure, we can do this or use gitlab directly: you can push gitlab repos
to any other repo if you give gitlab the required credentials
3) other projects that have up to now been reviewed via the gerrit
- https://gerrit.baserock.org/#/admin/projects/
- i assume the logical implication is to migrate those too?
Yeah, some project are already being mirrored [1] . Feel free to add
more if some active one is missing
- and then deprecate the gerrit, take down the service, decommission
whatever's hosting it?
Sure, this can be done when the migration is complete
4) turn git.baserock.org into a strict mirror? or establish a new
mirror-only service?
- historically we've pushed branches to g.b.o (eg when we've had to patch
upstream for baserock builds)
- in discussion with users, some have expressed a preference that troves
would act as pure mirrors
- so any work we or they would need to do, would happen elsewhere (say on a
gitlab server), and thereafter be mirrored into the trove
Sure, we can discuss about this point later
Clearly your proposed transition could happen without resolving all
of the
above, but we should aim to minimise confusion and tidy things up as we go
if possible.
Agree, let me know if you have any other questions / concerns
Cheers,
Javier
[1] https://gitlab.com/baserock/
5:33 p.m.
Send again to the list as previous mail seems to not be processed correctly
On 1 November 2016 at 10:37, Javier Jardón <jjardon(a)gnome.org> wrote:
Hi Paul,
On 30 October 2016 at 11:47, Paul Sherwood <paul.sherwood(a)codethink.com> wrote:
> On 2016-10-28 17:45, Javier Jardón wrote:
>>>
>>> [1]
>>>
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
>>
>>
>> To clarify this a little more, the only change I'm requesting here is
>> to stop mirroring the g.b.o definitions repo into
>> gitlab.com/baserock/definitions
>> So to make a change in definitions, the process would as simple as:
>>
>> - Create branch in gitlab.com/baserock/definition -> test branch in
>> the gitlab ci -> Create Merge request -> review -> patch is applied to
>> master
>>
>> (currently the patches have to be send to gerrit and then wait for the
>> change to be mirrored in gitlab)
>>
>> I'd like to do this change on a week counting from today (so next
>> Friday 4th of October)
>> Let me know if you have any objection for this to not happen
>
>
> I'm happy with your proposed change, but I think there are a few more
> general implications:
>
> 1) as discussed on irc, gitlab services will require maintenance/security
> updates etc
> - review gitlab setup with infra team
> - establish who will maintain, and how
No maintenance is required if we store the projects in gitlab.com.
Some people seems to have interest on have our own gitlab instance but
Its not what Im suggesting here (although for sure It can be done in
the future if there is enough intesrest)
If we want to use our own runners, then the only maintenance required
is for the "manager" runner that will spin up the other runners on
demand.
So, the maintenance would be keep that machine updated + gitlab-runner
software up-to-date + toml config file (which should not change much)
(Ive attached it so you can have a look to it)
I already volunteer to do this work if nobody is available at the moment
> 2) new canonical upstream location for definitions
> - abandon any in-progress patches/reviews in gerrit, or bring them across to
> gitlab
Yeah, this should be easy; there are actually only a few patches being
actively on review at the moment
> - update the wiki for contributors, and all references to definitions
Yes, we can do this over the weekend
> - add a lorry file for definitions itself, to land at its new mirror
> location, which i expect would be
> https://git.baserock.org/delta/definitions
Sure, we can do this or use gitlab directly: you can push gitlab repos
to any other repo if you give gitlab the required credentials
> 3) other projects that have up to now been reviewed via the gerrit
> - https://gerrit.baserock.org/#/admin/projects/
> - i assume the logical implication is to migrate those too?
Yeah, some project are already being mirrored [1] . Feel free to add
more if some active one is missing
> - and then deprecate the gerrit, take down the service, decommission
> whatever's hosting it?
Sure, this can be done when the migration is complete
> 4) turn git.baserock.org into a strict mirror? or establish a new
> mirror-only service?
> - historically we've pushed branches to g.b.o (eg when we've had to patch
> upstream for baserock builds)
> - in discussion with users, some have expressed a preference that troves
> would act as pure mirrors
> - so any work we or they would need to do, would happen elsewhere (say on a
> gitlab server), and thereafter be mirrored into the trove
Sure, we can discuss about this point later
> Clearly your proposed transition could happen without resolving all of the
> above, but we should aim to minimise confusion and tidy things up as we go
> if possible.
Agree, let me know if you have any other questions / concerns
Cheers,
Javier
[1] https://gitlab.com/baserock/
--
Javier Jardón Cabezas
1:42 p.m.
On 2016-10-28 17:45, Javier Jardón wrote:
> [1]
>
https://gitlab.com/baserock/definitions/commit/e2255bd601a12c9f6924874f2d...
To clarify this a little more, the only change I'm requesting here is
to stop mirroring the g.b.o definitions repo into
gitlab.com/baserock/definitions
So to make a change in definitions, the process would as simple as:
- Create branch in gitlab.com/baserock/definition -> test branch in
the gitlab ci -> Create Merge request -> review -> patch is applied to
master
(currently the patches have to be send to gerrit and then wait for the
change to be mirrored in gitlab)
I'd like to do this change on a week counting from today (so next
Friday 4th of October)
Let me know if you have any objection for this to not happen
I'm happy with your proposed change, but I think there are a few more
general implications:
1) as discussed on irc, gitlab services will require
maintenance/security updates etc
- review gitlab setup with infra team
- establish who will maintain, and how
2) new canonical upstream location for definitions
- abandon any in-progress patches/reviews in gerrit, or bring them
across to gitlab
- update the wiki for contributors, and all references to definitions
- add a lorry file for definitions itself, to land at its new mirror
location, which i expect would be
https://git.baserock.org/delta/definitions
3) other projects that have up to now been reviewed via the gerrit
- https://gerrit.baserock.org/#/admin/projects/
- i assume the logical implication is to migrate those too?
- and then deprecate the gerrit, take down the service, decommission
whatever's hosting it?
4) turn git.baserock.org into a strict mirror? or establish a new
mirror-only service?
- historically we've pushed branches to g.b.o (eg when we've had to
patch upstream for baserock builds)
- in discussion with users, some have expressed a preference that troves
would act as pure mirrors
- so any work we or they would need to do, would happen elsewhere (say
on a gitlab server), and thereafter be mirrored into the trove
Clearly your proposed transition could happen without resolving all of
the above, but we should aim to minimise confusion and tidy things up as
we go if possible.
br
Paul
2587
days inactive
2598
days old
5 comments
3 participants
participants (3)
-
Javier Jardón -
Paul Sherwood -
Paul Sherwood