Per https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.b2g/QhsFilCEsCs, we are going to create a gaia-try repo in hg, that developers can use to push gaia changes to try. In subsequent quarters, we can work on transitioning to a git repo for gaia-try. In the near term, gaia try pushes will work as follows: - developer pushes gaia patch to gaia-hg-try - developer updates the gaia pointer in gecko-hg-try, and pushes it to initiate the tryserver run This is dependent on the gecko-gaia coupling being tracked in bug 868597.

Per a conversation last week with :joduinn, we decided we could provide a better workflow for gaia-try by creating the gaia-try repo at git.mozilla.org. This would allow gaia developers to add gaia-try as a remote and push to it without having to clone an hg repo. The gecko try-server in hg works by using a new head for every push, so that people's changes don't stomp on each other. For a git-based approach, I'm not positive how we would achieve the same effect; we may have to use a different (new) branch for every push. I believe that the git.mozilla.org -> hg mirroring process works with all branches, but we'd have to figure a way of passing the branch name that will trigger a try run to buildbot. I.e., - gaia developer pushes to git.mozilla.org git-try with a branch 'bug123456' - hg mirroring copies branch to https://hg.mozilla.org/integration/gaia-try - try run gets triggered based on new branch being available at https://hg.mozilla.org/integration/gaia-try :hwine, do you think this approach is workable?

(In reply to Jonathan Griffin (:jgriffin) from comment #1) > Per a conversation last week with :joduinn, we decided we could provide a > better workflow for gaia-try by creating the gaia-try repo at > git.mozilla.org. This would allow gaia developers to add gaia-try as a > remote and push to it without having to clone an hg repo. minor point: I'd recommend we name the repo try/gaia.git on git.mozilla.org. This will scale better for the future I believe. > The gecko try-server in hg works by using a new head for every push, so that > people's changes don't stomp on each other. For a git-based approach, I'm > not positive how we would achieve the same effect; we may have to use a > different (new) branch for every push. fwiw, a branch in git is mapped to a new head in hg (which happens to be bookmarked as well). I don't _think_ we'll care about a branch name on the hg side, but that can be an implementation detail. > I believe that the git.mozilla.org -> hg mirroring process works with all > branches, but we'd have to figure a way of passing the branch name that will > trigger a try run to buildbot. I.e., I don't believe the branch name is the issue. However, specifying the try syntax will be a challenge. A git precommit hook would need to be written to mimic the behavior of the hook on hg. (And kept in sync as modifications are made in the future.) > - gaia developer pushes to git.mozilla.org git-try with a branch 'bug123456' > - hg mirroring copies branch to https://hg.mozilla.org/integration/gaia-try > - try run gets triggered based on new branch being available at We do _not_ want to use hg branches. The trigger on try is the same as any build-on-commit repository -- pushlog starts the ball rolling. > https://hg.mozilla.org/integration/gaia-try minor point: I'd recommend the name be hg.mozilla.org/try/gaia (or try-gaia). > :hwine, do you think this approach is workable? We're covering a lot of new territory here, so I'd recommend a small proof of concept be done early. I'm pretty sure (70%) this will work and pretty darn sure (90%) some variation would work. Assuming the continuous integration plumbing will work, the major challenge will be setting up a process and structure for handling hooks that need to work identically on git and hg. Any solution has to both work at the code level, and work at the IT deployment level (this would be the first git hook).

> We're covering a lot of new territory here, so I'd recommend a small proof of > concept be done early. I'm pretty sure (70%) this will work and pretty darn > sure (90%) some variation would work. Sounds like a good approach; let me know if you need anything from the a-team side for this.

It's been a month, where are we on getting some kind of "try-like" support for gaia testing? Hal are you the right person to ask?

I'm not the right person -- the bulk of the work here is buildbot related.

From talking with Joduinn, this is dependent on rolling out the new hg <--> git <--> github replication system, and that is just going to move us right out of any near-term ballpark in terms of getting this done. So we came up with a work around so that we can still provide a temporary short term solution while we continue to work toward a long term solution. I filed bug 905837 for that solution. And I'll mark this bug dependent on that one since by doing the short term prototype, I'm sure we'll learn things that will influence this bug.

I don't follow why this is dependent on hg <-> git <-> github replication. Do we need hg in here at all?

Some of the tests require us to clone gaia on the test slaves; and currently we can't do this (git isn't available everywhere). Additionally, test runs involve lots of pointers: there's the gaia.json pointer to gaia in gecko, and there is a gaia-ui-tests.json pointer to the the gaia-ui-tests repo in gaia. All of these things are currently hg-specific. I would love to get rid of the hg dependency; if doing that is faster than the hg <-> git <-> github replication, I'm all for it.

WONTFIXING - due to some meetings at b2g work week we have a better simpler solution. Going to open some new bugs because this is all getting confusing.