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•9 years ago
|
||
Hey Hal, Let me know if there is anything I can do to help here. Thanks, Pete
Comment 18•9 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•9 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•9 years ago
|
||
Many thanks Hal!
Assignee | ||
Comment 21•9 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•9 years ago
|
||
(BTW I opted above to have github.com as the RoR, like we have for build-cloud-tools)...
Comment 23•9 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•9 years ago
|
Attachment #8576062 -
Flags: review?(hwine) → review+
Comment 24•9 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
•