definitions migration to gitlab (was Re: Proposal: gitlab.com/baserock/definitions as definitions canonical source)
2:54 p.m.
Hi all,
On 28 October 2016 at 17:45, Javier Jardón <jjardon(a)gnome.org> wrote:
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
Seems nobody has any big problem with the migration, so
gitlab.com/baserock/definitions will stop mirroring
git.baserock.org/baserock/baserock/definitions tomorrow at some point
I've already migrated the active merge request to the new location
[1], and I will try to edit the wiki over the weekend
To mirror back definitions to
https://git.baserock.org/delta/definitions I need the trove
credentials (user/pass) so gitlab can push there; can anyone give me
them in private? (or join the gitlab.com/baserock/definitions project
, and configure the mirror here [2] :))
Cheers,
Javier
[1] https://gitlab.com/baserock/definitions/merge_requests
[2] https://gitlab.com/baserock/definitions/mirror
7:01 a.m.
On 03/11/16 19:54, Javier Jardón wrote:
<snip>
> 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
Seems nobody has any big problem with the migration, so
gitlab.com/baserock/definitions will stop mirroring
git.baserock.org/baserock/baserock/definitions tomorrow at some point
I'm not sure about that, there was an email waiting for moderation
from Paul. Apologies I didn't approve it earlier.
I've already migrated the active merge request to the new location
[1], and I will try to edit the wiki over the weekend
To mirror back definitions to
https://git.baserock.org/delta/definitions I need the trove
credentials (user/pass) so gitlab can push there; can anyone give me
them in private? (or join the gitlab.com/baserock/definitions project
, and configure the mirror here [2] :))
I don't understand this requirement. Can you explain this better?
Why would you need an user/pass in the trove for this? User/pass
access is disabled in the Trove for security reasons, and only the
infrastructure team has access to it using ssh keys.
What would you do with them? change something internally? Some kind of
configuration? Anything that implies configuring the trove should be
scripted so that we can do it again anytime.
I don't think you will be able to (git) push anything to the Trove
with this kind of credentials (if they existed)... Or is it the case
that Gitlab does something "clever" and `rsync`s the contents?
If Gitlab can push (when configured properly) why do we have to move
it to delta/definitions? I thought that the only way to do this was to
create a lorry for definitions from gitlab.
If what you are looking for is for a Gitano user that can push via
https using User/pass, I think that's disabled as well, but we could
have a look.
--
Pedro
6:09 a.m.
Hi Pedro,
On 4 November 2016 at 12:01, Pedro Alvarez
<pedro.alvarez(a)codethink.co.uk> wrote:
On 03/11/16 19:54, Javier Jardón wrote:
<snip>
>> 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
>
> Seems nobody has any big problem with the migration, so
> gitlab.com/baserock/definitions will stop mirroring
> git.baserock.org/baserock/baserock/definitions tomorrow at some point
I'm not sure about that, there was an email waiting for moderation
from Paul. Apologies I didn't approve it earlier.
Oh, ok; is the email I've replied on th 1th of November? I do not seem
to have any other email from Paul in my inbox
> I've already migrated the active merge request to the new
location
> [1], and I will try to edit the wiki over the weekend
>
> To mirror back definitions to
> https://git.baserock.org/delta/definitions I need the trove
> credentials (user/pass) so gitlab can push there; can anyone give me
> them in private? (or join the gitlab.com/baserock/definitions project
> , and configure the mirror here [2] :))
>
I don't understand this requirement. Can you explain this better?
Why would you need an user/pass in the trove for this? User/pass
access is disabled in the Trove for security reasons, and only the
infrastructure team has access to it using ssh keys.
What would you do with them? change something internally? Some kind of
configuration? Anything that implies configuring the trove should be
scripted so that we can do it again anytime.
I don't think you will be able to (git) push anything to the Trove
with this kind of credentials (if they existed)... Or is it the case
that Gitlab does something "clever" and `rsync`s the contents?
If Gitlab can push (when configured properly) why do we have to move
it to delta/definitions? I thought that the only way to do this was to
create a lorry for definitions from gitlab.
If what you are looking for is for a Gitano user that can push via
https using User/pass, I think that's disabled as well, but we could
have a look.
Yeah, this last one is what we need to alloy gitlab to push in the trove.
As I said, we can do it this way or we can setup a lorry to mirror the
definitions repo in gitlab to g.b.o
Cheers,
Javier
7:12 a.m.
On 2016-11-07 12:09, Javier Jardón wrote:
>> Seems nobody has any big problem with the migration, so
>> gitlab.com/baserock/definitions will stop mirroring
>> git.baserock.org/baserock/baserock/definitions tomorrow at some point
>
> I'm not sure about that, there was an email waiting for moderation
> from Paul. Apologies I didn't approve it earlier.
Oh, ok; is the email I've replied on th 1th of November? I do not seem
to have any other email from Paul in my inbox
Sorry, I changed email systems. The mail that got moderated is the same
text as the one you replied to.
5:26 a.m.
On 07/11/16 12:09, Javier Jardón wrote:
>> I've already migrated the active merge request to the new
location
>> [1], and I will try to edit the wiki over the weekend
>>
>> To mirror back definitions to
>> https://git.baserock.org/delta/definitions I need the trove
>> credentials (user/pass) so gitlab can push there; can anyone give me
>> them in private? (or join the gitlab.com/baserock/definitions project
>> , and configure the mirror here [2] :))
>>
>
> I don't understand this requirement. Can you explain this better?
>
> Why would you need an user/pass in the trove for this? User/pass
> access is disabled in the Trove for security reasons, and only the
> infrastructure team has access to it using ssh keys.
>
> What would you do with them? change something internally? Some kind of
> configuration? Anything that implies configuring the trove should be
> scripted so that we can do it again anytime.
>
> I don't think you will be able to (git) push anything to the Trove
> with this kind of credentials (if they existed)... Or is it the case
> that Gitlab does something "clever" and `rsync`s the contents?
>
> If Gitlab can push (when configured properly) why do we have to move
> it to delta/definitions? I thought that the only way to do this was to
> create a lorry for definitions from gitlab.
>
> If what you are looking for is for a Gitano user that can push via
> https using User/pass, I think that's disabled as well, but we could
> have a look.
Yeah, this last one is what we need to alloy gitlab to push in the trove.
As I said, we can do it this way or we can setup a lorry to mirror the
definitions repo in gitlab to g.b.o
Sorry for not answering earlier, I'm quite busy these days :/
I'd prefer to set up Gitlab to Push. That will mean that we will not
need to change the location in g.b.o. but also we will need to do some
changes like:
- Create an user for Gitlab in g.b.o using Ansible setup scripts of
infrastructure.git
- Research if https user/password login is safe
- Enable https user/password login
- Ensure nobody else, only Gitlab, can push to "baserock/" epositories.
- Document the Gitlab integration with g.b.o in infrastructure.git
If we want to go with the lorring approach (uglier IMO)
- Create a lorry for all of the repositories in Gitlab
- Deprecate the migrated repos in g.b.o. and even make them read-only
if possible
Common: Deprecate Gerrit
- Move relevant patches to Gitlab
- Kill (or shutdown) instance
- Stop the backups of Gerrit database
- Adjust infrastructure.git to remove Gerrit from there
- Remove mentions about Gerrit in the wiki, and replace with docs
about Gilab
I don't think I will find time this week to help with this. So, feel
free to go with the approach to want.
Cheers,
Pedro.
--
Pedro
7:16 a.m.
Hi all,
gitlab.com/baserock/definitions doesn't mirror
https://gerrit.baserock.org/baserock/baserock/definitions anymore.
Also, several other projects (import, baserock-chroot,
lorry-controler, lorry ...) have been moved to gitlab.com/baserock.
I tihnk the only relevent one I didn't mirror yet is
https://gerrit.baserock.org/baserock/local-config/lorries ; do we want
to move this repo to gitlab.com/baserock or keep it in the trove only?
Active merge request for definitions has been moved to [1]; feel free
to send more!
Below some of the action points in progress
On 8 November 2016 at 11:26, Pedro Alvarez
<pedro.alvarez(a)codethink.co.uk> wrote:
On 07/11/16 12:09, Javier Jardón wrote:
>>> I've already migrated the active merge request to the new location
>>> [1], and I will try to edit the wiki over the weekend
>>>
>>> To mirror back definitions to
>>> https://git.baserock.org/delta/definitions I need the trove
>>> credentials (user/pass) so gitlab can push there; can anyone give me
>>> them in private? (or join the gitlab.com/baserock/definitions project
>>> , and configure the mirror here [2] :))
>>>
>>
>> I don't understand this requirement. Can you explain this better?
>>
>> Why would you need an user/pass in the trove for this? User/pass
>> access is disabled in the Trove for security reasons, and only the
>> infrastructure team has access to it using ssh keys.
>>
>> What would you do with them? change something internally? Some kind of
>> configuration? Anything that implies configuring the trove should be
>> scripted so that we can do it again anytime.
>>
>> I don't think you will be able to (git) push anything to the Trove
>> with this kind of credentials (if they existed)... Or is it the case
>> that Gitlab does something "clever" and `rsync`s the contents?
>>
>> If Gitlab can push (when configured properly) why do we have to move
>> it to delta/definitions? I thought that the only way to do this was to
>> create a lorry for definitions from gitlab.
>>
>> If what you are looking for is for a Gitano user that can push via
>> https using User/pass, I think that's disabled as well, but we could
>> have a look.
>
> Yeah, this last one is what we need to alloy gitlab to push in the trove.
> As I said, we can do it this way or we can setup a lorry to mirror the
> definitions repo in gitlab to g.b.o
Sorry for not answering earlier, I'm quite busy these days :/
I'd prefer to set up Gitlab to Push. That will mean that we will not
Yeah, me too
need to change the location in g.b.o. but also we will need to do
some
changes like:
- Create an user for Gitlab in g.b.o using Ansible setup scripts of
infrastructure.git
- Research if https user/password login is safe
- Enable https user/password login
- Ensure nobody else, only Gitlab, can push to "baserock/" epositories.
- Document the Gitlab integration with g.b.o in infrastructure.git
I do not have access to the trove infra to do this changes; can anyone
with access make this?
If we want to go with the lorring approach (uglier IMO)
- Create a lorry for all of the repositories in Gitlab
- Deprecate the migrated repos in g.b.o. and even make them read-only
if possible
I think is better the previous approach
Common: Deprecate Gerrit
- Move relevant patches to Gitlab
done
- Kill (or shutdown) instance
- Stop the backups of Gerrit database
- Adjust infrastructure.git to remove Gerrit from there
No access to gerrit instance to do this; but I think we can hold on
this until everything is migrated
- Remove mentions about Gerrit in the wiki, and replace with docs
about Gilab
I'm working on this
Cheers,
Javier
[1] https://gitlab.com/baserock/definitions/merge_requests
2276
days inactive
2281
days old
5 comments
3 participants
participants (3)
-
Javier Jardón -
Paul Sherwood -
Pedro Alvarez