Closed
Bug 1186676
Opened 9 years ago
Closed 9 years ago
conversion of partner-repacks to github
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: mixedpuppy, Unassigned)
References
Details
Attachments
(1 file)
1.75 KB,
patch
|
coop
:
review+
|
Details | Diff | Splinter Review |
Move partner-repacks to a private github repo. This repo will contain git submodules for each parter repo so a single clone/pull will contain/update everything needed to do a full run of repacks. - partner-repacks has been imported (with history) to https://github.com/mozilla-partners/partner-repacks - each existing partner has also been imported individually (without history) to individual private repos in mozilla-partners - submodules added to git partner-repacks repo, old directory structure largely removed The directory structure has changed slightly to support this. Attached patch fixes partner-repacks.py to work with the new directory structure.
Attachment #8637511 -
Flags: review?(coop)
Comment 1•9 years ago
|
||
Can we get release folks added to the access lists of these repositories? That's the following people: bhearsum nthomas-mozilla rail hwine
Comment 2•9 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #0) > Move partner-repacks to a private github repo. This repo will contain git > submodules for each parter repo so a single clone/pull will contain/update > everything needed to do a full run of repacks. I spoke to catlee today about submodules because he has more experience there than I do. submodules are apparently pretty fragile. Have we considered alternatives like git subtree or google's repo as is used for b2g?
Reporter | ||
Comment 3•9 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #1) > Can we get release folks added to the access lists of these repositories? > That's the following people: > bhearsum > nthomas-mozilla > rail > hwine @bhearsum, you should have admin privi on the mozilla-partners account, but I've added nthomas and hwine who were missing from the list
Comment 4•9 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #3) > (In reply to Ben Hearsum [:bhearsum] from comment #1) > > Can we get release folks added to the access lists of these repositories? > > That's the following people: > > bhearsum > > nthomas-mozilla > > rail > > hwine > > @bhearsum, you should have admin privi on the mozilla-partners account, but > I've added nthomas and hwine who were missing from the list Hmm, this might be PEBKAC, but I only see two repos on https://github.com/mozilla-partners, and https://github.com/mozilla-partners/partner-repacks gives me a 404.
Comment 5•9 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #4) > Hmm, this might be PEBKAC, but I only see two repos on > https://github.com/mozilla-partners, and > https://github.com/mozilla-partners/partner-repacks gives me a 404. Shane's still in the process of moving things. I suspect he has it as local changes right now.
Reporter | ||
Comment 6•9 years ago
|
||
Look now. I just added all the repos to the "mozilla" team, which is probably what the problem was
Comment 7•9 years ago
|
||
Comment on attachment 8637511 [details] [diff] [review] repackfix Review of attachment 8637511 [details] [diff] [review]: ----------------------------------------------------------------- r+ with nits fixed. ::: scripts/partner-repacks.py @@ +875,5 @@ > continue > + > + for f in files: > + if f == 'repack.cfg': > + print root, _, f Don't need the print in production. @@ +879,5 @@ > + print root, _, f > + partner_dirs[os.path.split(root)[-1]] = (root, os.path.join(root, f)) > + # partner_dirs.append(root) > + # print partner_dirs > + # sys.exit(0) These 3 commented lines can disappear.
Attachment #8637511 -
Flags: review?(coop) → review+
Comment 8•9 years ago
|
||
Shane - when you're ready for the old hg repos to go read only, open a bug against Developer Services :: Mercurial: hg.mozilla.org
Comment 9•9 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #6) > Look now. I just added all the repos to the "mozilla" team, which is > probably what the problem was Got it, thanks!
Reporter | ||
Comment 10•9 years ago
|
||
ok, I have this working using google repo (a modified version to fix private repo's). Just go to https://github.com/mozilla-partners/repack-manifests and follow the readme (copy/paste) to pull everything down. You'll end up with a structure similar to partner-repacks repo. Just run scripts/partner-repacks.py as usual and everything "should" work. @hwine I'm happy to move to this after the 40.0b8 builds are done, given someone else gives this a test spin.
Flags: needinfo?(hwine)
Comment 11•9 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #10) > @hwine I'm happy to move to this after the 40.0b8 builds are done, given > someone else gives this a test spin. Bug 1188219 is opened to let you give the okay when developer services can make that change.
Updated•9 years ago
|
Flags: needinfo?(hwine)
Comment 13•9 years ago
|
||
I've already tested the setup steps in https://github.com/mozilla-partners/repack-manifests#readme and verified that they work. From the releng-side, I need to replace the existing hg checkout of the partner-repacks ScriptFactory with the git setup steps, This may require a migration to mozharness.
Flags: needinfo?(coop)
Reporter | ||
Comment 14•9 years ago
|
||
IMO we can make the mercurial repo read-only at this point.
Flags: needinfo?(hwine)
Flags: needinfo?(coop)
Comment 15•9 years ago
|
||
(In reply to Shane Caraveo (:mixedpuppy) from comment #14) > IMO we can make the mercurial repo read-only at this point. I agree, especially if we need to further mirror github back into git.m.o.
Flags: needinfo?(coop)
Reporter | ||
Comment 16•9 years ago
|
||
@hwine ping
Comment 17•9 years ago
|
||
As noted in comment 11, bug 1188219 is where the actual setting to read only will occur. But only after this bug is r/f (it's the only reasonable way to handle cross product/team handoffs) As I understand the situation, there is no functional problem with leaving the repos r/w, it's just cleanup we need to do after this bug is closed. Is there any other reason to change the repos to r/o before this bug is resolved? If so, removing the dependency will free things up (best done from bug 1188219 so it's clear it's a "go")
Flags: needinfo?(hwine)
Reporter | ||
Comment 18•9 years ago
|
||
@hwine, sorry, had dependencies backwards. I am r/f with this bug, @coop is building from the git repos and there are other bugs for various pieces left for getting automation done.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•