Closed
Bug 1020131
Opened 10 years ago
Closed 9 years ago
Request for a new git & hg repository: build/mapper
Categories
(Developer Services :: Mercurial: hg.mozilla.org, defect)
Developer Services
Mercurial: hg.mozilla.org
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: pmoore, Assigned: pmoore)
Details
(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1373] )
Attachments
(1 file)
1.02 KB,
patch
|
hwine
:
review+
|
Details | Diff | Splinter Review |
Currently I am using https://github.com/petemoore/mapper for storing the code for mapper. Information about mapper can be found here:
https://wiki.mozilla.org/ReleaseEngineering/Applications/Mapper
I would like to have https://hg.mozilla.org/build/mapper created for hosting this code instead. Then I would like have the repo mirrored to https://github.com/mozilla/build-mapper (i.e. creating the github repo, and then adding mapper to build_repos here: http://hg.mozilla.org/build/mozharness/file/tip/configs/vcs_sync/build-repos.py).
I see it as making more sense to host under hg.mozilla.org, rather than git.mozilla.org, since all the other build/* repos are hosted in hg.
The commit access level should be the same as the other build/* repositories.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → server-ops-devservices
Component: Repos and Hooks → Server Operations: Developer Services
Product: Release Engineering → mozilla.org
QA Contact: hwine → nmaul
Assignee | ||
Comment 1•10 years ago
|
||
(In reply to Pete Moore [:pete][:pmoore] from comment #0)
> Then I would like have the repo mirrored to
> https://github.com/mozilla/build-mapper (i.e. creating the github repo, and
> then adding mapper to build_repos here:
> http://hg.mozilla.org/build/mozharness/file/tip/configs/vcs_sync/build-repos.
> py).
I should have mentioned - I can take care of this, once the repository has been created.
Comment 2•10 years ago
|
||
relengapi mirrors from gitmo to both hgmo and github. Is that what you want for mapper, too?
Comment 3•10 years ago
|
||
Git is also ror for slaveapi and releaserunner just fyi
Assignee | ||
Comment 4•10 years ago
|
||
lol, ok - so from my side I don't really mind, but probably we should have a convention, shouldn't we?
I mean, is there an easy way to see if you are on a mirror or the RoR?
I think if we normalise, there is less risk people will push to the wrong repo, and then lose their changes.
Comment 5•10 years ago
|
||
IMHO the standard should be gitmo.
https://github.com/djmitche/build-relengapi/compare/issue44 tried to standardize, but didn't work out very well.
Comment 6•10 years ago
|
||
So, hg or git? /cc hal
Comment 7•10 years ago
|
||
So,
a) bug filed in completely wrong component - please see https://wiki.mozilla.org/ReleaseEngineering/RepositoryCreationRequest for future requests. Moving back until we have an actionable item for dev-services.
b) since we don't have a standard, we should have the RoR be what is referenced by puppet to deploy/upgrade the app.
Dustin: what's the RoR for relengapi applications?
Assignee: server-ops-devservices → nobody
Component: Server Operations: Developer Services → Repos and Hooks
Flags: needinfo?(dustin)
Product: mozilla.org → Release Engineering
QA Contact: nmaul → hwine
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Hal Wine [:hwine] (use needinfo) from comment #7)
> So,
>
> a) bug filed in completely wrong component - please see
> https://wiki.mozilla.org/ReleaseEngineering/RepositoryCreationRequest for
> future requests. Moving back until we have an actionable item for
> dev-services.
>
> b) since we don't have a standard, we should have the RoR be what is
> referenced by puppet to deploy/upgrade the app.
>
> Dustin: what's the RoR for relengapi applications?
Hey Hal,
a) I did read the wiki page - and you will see that the bug started in "Product: Release Engineering; Component: Repos and Hooks" and moved to "Product: mozilla.org; Component: Server Operations: Developer Services", as described by the wiki page. What was wrong with this? (I also corrected the wiki page while I was at it, since it referred to an out-of-data component that no longer existed).
b) My preference is hg.mozilla.org, not git.mozilla.org, which is why I asked for this in the request (https://bugzilla.mozilla.org/show_bug.cgi?id=1020131#c0). I'm not sure why I am being overruled here.
Please can you advise which data is missing/inaccurate or why you say this is in the wrong component, and why my original request is not sufficient, which asks for hg.m.o, not git.m.o?
Thanks,
Pete
Flags: needinfo?(hwine)
Comment 10•10 years ago
|
||
Relengapi itself is already on git.mozilla.org, and I think it makes sense to keep all of the relengapi components there, just for simplicity of combining them. I didn't realize you were leaning toward hg.m.o. I don't care particularly deeply - it just seems like an extra hurdle for the next person to come along to hack on it to have to straddle git and hg.
Assignee | ||
Comment 11•10 years ago
|
||
OK guys, let's go with git. You've convinced me. :)
So the modified request is:
==========
* Please can you create a git repo available here: ssh://gitolite3@git.mozilla.org/build/mapper [1]
* Please can you create a hg repo available here: ssh://hg.mozilla.org/build/mapper [2]
* I will take care of updating vcs sync so that it mirrors repo [1] to both:
o repo [2]
o https://github.com/mozilla/build-mapper
In other words, git.m.o will be the RoR, github and hg.m.o will be downstream (read-only) mirrors.
The commit access level for [1] should be the same as for ssh://gitolite3@git.mozilla.org/build/relengapi.
The commit access level for [2] should be the same as for other downstream mirrors (e.g. https://hg.mozilla.org/build/relengapi).
Many thanks in advance!
Pete
Flags: needinfo?(hwine)
Assignee | ||
Comment 12•10 years ago
|
||
Hal,
When is a good time to go through this with you?
Thanks,
Pete
Flags: needinfo?(hwine)
Updated•10 years ago
|
Product: Release Engineering → Developer Services
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/198]
Assignee | ||
Comment 13•10 years ago
|
||
Is this something I could self-serve on?
Thanks,
Pete
Comment 14•10 years ago
|
||
(In reply to Pete Moore [:pete][:pmoore] from comment #13)
> Is this something I could self-serve on?
Oops - way too long in responding :(
Yes, you can self serve the legacy conversion work. You can't self serve the repo creation (neither of these is the 'auto create from vcs-sync' case), but legacy mirror can be set up in advance (just will silently error).
Leaving NI me to create the repos
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://kanbanize.com/ctrl_board/6/198] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1363] [kanban:engops:https://kanbanize.com/ctrl_board/6/198]
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1363] [kanban:engops:https://kanbanize.com/ctrl_board/6/198] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1364] [kanban:engops:https://kanbanize.com/ctrl_board/6/198]
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1364] [kanban:engops:https://kanbanize.com/ctrl_board/6/198] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1366] [kanban:engops:https://kanbanize.com/ctrl_board/6/198]
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1366] [kanban:engops:https://kanbanize.com/ctrl_board/6/198] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1373] [kanban:engops:https://kanbanize.com/ctrl_board/6/198]
Updated•10 years ago
|
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1373] [kanban:engops:https://kanbanize.com/ctrl_board/6/198] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/1373]
Assignee | ||
Comment 15•10 years ago
|
||
Thanks Hal. Do you have a rough ETA?
Many thanks,
Pete
Assignee | ||
Comment 16•10 years ago
|
||
ping
Assignee | ||
Comment 17•10 years ago
|
||
Hey Hal,
Let me know if there is anything I can do to help here.
Thanks,
Pete
Comment 18•10 years ago
|
||
git repo created as RoR, can be cloned as either:
URL ssh://gitolite3@git.mozilla.org/build/mapper.git
https://git.mozilla.org/build/mapper.git
Status: NEW → ASSIGNED
Flags: needinfo?(hwine)
Summary: Request for a new hg repository: build/mapper → Request for a new git & hg repository: build/mapper
Comment 19•10 years ago
|
||
hg repo created to be read only mirror
Pete: over to you to set up mirroring
Assignee: nobody → pmoore
Status: ASSIGNED → NEW
Assignee | ||
Comment 20•10 years ago
|
||
Many thanks Hal!
Assignee | ||
Comment 21•10 years ago
|
||
Are there manual steps to roll this out Hal, or does the new config get picked up automatically?
Many thanks!
Pete
Attachment #8576062 -
Flags: review?(hwine)
Assignee | ||
Comment 22•10 years ago
|
||
(BTW I opted above to have github.com as the RoR, like we have for build-cloud-tools)...
Comment 23•10 years ago
|
||
Comment on attachment 8576062 [details] [diff] [review]
bug1020131_repo-sync-configs_v1.patch
Review of attachment 8576062 [details] [diff] [review]:
-----------------------------------------------------------------
looks reasonable - this is a complex case not fully supported by the scripted method, so you'll need to watch after deployment. (Other approach is to set up a single mirror using scripted, then mod the configs for the complexity later.)
Deployment instructions are in docs (I just added notes on the extra added work since you're non-scripted):
https://people.mozilla.org/~hwine/tmp/vcs2vcs/cookbook.html#scripted-method-for-configuration-creation
Start with the note before step 4 and go from there.
Updated•10 years ago
|
Attachment #8576062 -
Flags: review?(hwine) → review+
Comment 24•10 years ago
|
||
(In reply to Pete Moore [:pete][:pmoore] from comment #22)
> (BTW I opted above to have github.com as the RoR, like we have for
> build-cloud-tools)...
So this is a change from the original, and requires rework of the work done in comment 18.
Mirroring to git.mozilla.org will fail until that work is done.
Assignee | ||
Comment 25•9 years ago
|
||
This is now moved to relengapi codebase, I believe. Closing...
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•