962769 - Determine how to support non-gaia try code on "gaia try"

Status: VERIFIED FIXED

(Developer Services :: Mercurial: hg.mozilla.org, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

Now that bug 899969 is (mostly?) landed, in theory it's possible to use the try server to test changes to non-gecko parts of b2g — as long as the revisions to test are present in a repository on git.mozilla.org.

In particular, I'm working on seccomp-bpf (system call filtering for content processes) support for b2g, which needs kernel patches.  (Bug 790923 is the tracker.)  I'd like to be able to do try runs with the modified kernel before landing it, for the usual reasons.

So, if I could have a project branch on git.mozilla.org/b2g/platform_prebuilts_qemu-kernel that I could push to, that would be helpful.

Comment 1

[Hal Wine [:hwine] use NI!]

Other than avoiding specific naming of release branches, RelEng has no concerns with this. 

Any branch created by devs in the github/mozilla-b2g/* repo will be mirrored to the matching git.mozilla.org repository and thus:
 a) be available to builders/testers for use as a "try server"
 b) be visible to all downstream partners

If (b) is okay with the ffos dev managers, you're good to go, and no action by releng is needed.

If you need other options to keep try code out of the published repo, please morph this bug into a request for those.

Comment 2

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

How does that synchronization handle non-fast-forward pushes or branch deletion?

If the answer to that is "not well", maybe it would make more sense for me to request a personal repo for this?  (I'm assuming that anything hosted on git.mozilla.org is acceptable to the build process TBPL uses.)

Comment 3

[Hal Wine [:hwine] use NI!]

(In reply to Jed Davis [:jld] from comment #2)
> How does that synchronization handle non-fast-forward pushes or branch
> deletion?

These operations are not allowed on any "partner-visible" repository.

> 
> If the answer to that is "not well", maybe it would make more sense for me
> to request a personal repo for this?  

It's not clear that personal repos can be setup on git.mozilla.org (That's an IT policy decision, but since the location wouldn't "map" as below, it's moot for this bug.)

> (I'm assuming that anything hosted on
> git.mozilla.org is acceptable to the build process TBPL uses.)

It's not clear that "any" would work, as we have to re-write the manifest.xml to point to the git.mozilla.org - that mapping follows very specific rules. I'm not sure if that mapping is done only for release builds, or for dep builds as well.

There are 2 other alternatives I see, assuming the mapping issue is solved (as it blocks any alternate repository solution):
 a) wait for bug 914651 to be resolved, and allow any github repo to be used
 b) create a convention for "try repos" that minimizes time to setup a mirror, doesn't cause partner confusion, and helps with the mapping issue

If (a) works for you, that would be easiest, and you could weigh in on bug 914651 that it's blocking you. 

(b) is straightforward, but more complex to implement. I'm hoping (a) works for you and there's a solution to the manifest mapping problem for that. (In many ways it would better if the manifest mapping could be disabled for these "try" jobs, as that would be a safeguard against try code ever ending up in the product accidentally.)

I've changed summary to match what you're trying to do, and asking :catlee to verify my statements about the manifest mapping issue.

Comment 4

[Chris AtLee [:catlee]]

If in-tree manifests are used (ala bug 899969), no manifest rewriting is done as part of the build. You should be able to modify the in-tree manifest and push it to try.

Comment 5

[Hal Wine [:hwine] use NI!]

Summary: The following process should work:
 - publish your code-to-test in a repository on github (not in mozilla account)
 - update your the intree manifest to point to that repository
 - submit to try

Comment 6

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Chris AtLee [:catlee] from comment #4)
> If in-tree manifests are used (ala bug 899969), no manifest rewriting is
> done as part of the build. You should be able to modify the in-tree manifest
> and push it to try.

This is actually what I tried originally — but I used a git:// URL instead of https://, which might have been the actual problem.  The result of that was https://tbpl.mozilla.org/?tree=Try&rev=f35931747805; I asked on IRC about whether remotes had to be git.m.o before filing this bug, but I think we were talking about different things and didn't realize it.

And it looks like https://tbpl.mozilla.org/?tree=Try&rev=53e523d8a9c3 (with https://github.com) succeeded.  Sorry for the noise.

Comment 7

[Hal Wine [:hwine] use NI!]

Thanks for the confirmation. That's great to have.