Closed Bug 1007370 Opened 10 years ago Closed 10 years ago

Decide which Gecko to download for gaia-try runs at test runtime

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jhford, Unassigned)

Details

Gaia branches each target a specific branch of Gecko.  Right now, we hardcode to 

http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-linux64_gecko/latest/

This is valid for most Pull Requests other than v1.3t and v1.4 where we need a different gecko build.  This also means that we can't handle the case where a developer needs a very specific build of gecko.

What we'd love to see is a releng.json file in the root of the gaia repository which the mozharness script can read to find out values like where the gecko build to use is.  Having a default value in case of the absence of this file would be nice.

rough psuedo-code for what I would like to see is:

cloneGaia(data='gaia.json', toDir='gaia')
if os.path.exists('gaia/releng.json'):
  config = json.load(open('gaia/releng.json'))
else
  config = {'gecko_url': getDefault('gecko_url')}
downloadGecko(baseUrl=config['gecko_url'])
We might be able to do this by specifying the releng.json as an additional mozharness config file, and having it specify the installer_url and test_url.  If so, we would need one per platform.

Who would update these files, and how?

(In reply to John Ford [:jhford] -- please use 'needinfo?' instead of a CC from comment #0)
> This is valid for most Pull Requests other than v1.3t and v1.4 where we need
> a different gecko build.

This assumes that releng.json would change for a specific pull request, or that we have separate branches in gaia-try with different releng.json files.

> This also means that we can't handle the case
> where a developer needs a very specific build of gecko.

How would they specify this?  By special strings in their pull request?  If so, would your code update the releng.json appropriately?
(In reply to Aki Sasaki [:aki] from comment #1)
> We might be able to do this by specifying the releng.json as an additional
> mozharness config file, and having it specify the installer_url and
> test_url.  If so, we would need one per platform.
> 
> Who would update these files, and how?

This file would be checked into the gaia repository itself as the root, much like how https://github.com/mozilla-b2g/gaia/blob/master/.travis.yml is.  Updates to this file would be done per branch and could be modified by either releng or a b2g dev using the standard Bug + PR workflow.  The added benefit of this approach is that submitting the change tests the change at the same time.

The goal here isn't to point to a specific nightly, but rather to be able to say that the v1.4 branch of gaia can point to

http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-b2g30_v1_4-linux64_gecko/latest/ 

I don't really know how mozharness config files would factor into this.

> This assumes that releng.json would change for a specific pull request, or
> that we have separate branches in gaia-try with different releng.json files.

Nope, it would only change when someone wants it to.  99% of the time it won't change.  We still want to point to latest of something, we just want to be configure which latest we want.

The idea is that the master branch points to m-c, v1.4 to m-b2g30_v1_4.  

> How would they specify this?  By special strings in their pull request?  If
> so, would your code update the releng.json appropriately?

Nope, the contents of the releng.json in the commit that they push would point to the base URL that contains the gecko they need.
We're now using the <platform>.json files to determine which build to download, so that lets us move the decision of which build to download up to jhford's infra: bug 1023007 ; http://hg.mozilla.org/integration/gaia-try/file/fff26b21a616

I'm going to mark the RelEng portion (this bug) done.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.