1037005 - Master/branch and try jobs shouldn't be lumped into one gaia-try repo

Status: RESOLVED INCOMPLETE

(Taskcluster :: General, defect)

Description

[Ed Morley [:emorley]]

"Try" type repos (ie individuals testing out arbitrary commits as part of their development cycle) are really quite different from master/branch repos - however at present we abuse one repo (gaia-try) for both purposes.

I can't face reading though pages of bugs to find out why we did this, but regardless we have to do something about it now, for the following reasons:

1) Try repos can't clobber whereas master/branches can. We're clobbering everything at the moment, which is a waste.

2) The sheriffs are apparently going to be asked to sheriff a subset of the current gaia-try repo jobs (master and branches), which is only possible if they are on their own repo.

3) Gaia Try jobs should have a lower priority than master/branches, the same as gecko's try having a lower priority than integration repos/release branches.

We need a separate repo on TBPL for each of:
* Try
* Master
* {Each branch}

Comment 1

[Ryan VanderMeulen [:RyanVM]]

IIRC, John is the person who needs looping in on this.

Comment 2

[John Ford [:jhford] CET/CEST Berlin Time]

(In reply to Ed Morley (Away 12th-20th July) from comment #0)
> "Try" type repos (ie individuals testing out arbitrary commits as part of
> their development cycle) are really quite different from master/branch repos
> - however at present we abuse one repo (gaia-try) for both purposes.
> 
> I can't face reading though pages of bugs to find out why we did this, but
> regardless we have to do something about it now, for the following reasons:
> 
> 1) Try repos can't clobber whereas master/branches can. We're clobbering
> everything at the moment, which is a waste.

Actually, this is not a concern for PR testing.  We only clobber the repo when the slave has an HG copy of Gaia instead of a Git one.  When the slave already has a copy of Git, I've gone through great lengths to ensure that we fetch the absolute minimum amount remote data.  Theoretically, if a slave got two pull requests for the same user's branch and only a single commit was added, we'd only need to fetch that single commit object.

As for the actual profile builds, they're fairly cheap to do so we do delete those between builds.

> 2) The sheriffs are apparently going to be asked to sheriff a subset of the
> current gaia-try repo jobs (master and branches), which is only possible if
> they are on their own repo.

Because I've tried to have this done before and was told it was a huge project, I've decided to just work around this and build something for Gaia devs that mimics TBPL.  It's not ideal to have a different dashboard for Gaia-Try, but it's not too hard to do.

For PRs, the goal is to use the Github Status API to inform developers of the outcome.

If IT were to make me different user accounts for branches and prs, we could theoretically filter by pusher name to distinguish between PRs and Branches on TBPL.

> 3) Gaia Try jobs should have a lower priority than master/branches, the same
> as gecko's try having a lower priority than integration repos/release
> branches.

Lower priority, but I still think that it's *very* important these have a better start time SLA than 8 hours.  One of the main reasons for moving away from travis was to decrease the wait times for the start of jobs.

> We need a separate repo on TBPL for each of:
> * Try
> * Master
> * {Each branch}

I support this happening.  It turns out that having more than a single 'gaia-try' branch is very complicated.  See bug 1026246 comment 3 for more details on why it's complex.

If we do this, please, let's name the branches in an easily computable way like:

def nameRepo(gaiaBranch):
  return 'gaia-' + gaiaBranch

e.g. /integration/gaia-master /integration/gaia-v2.0 /integration/gaia-v1.3t

Please name the branch for pull requests: gaia-pull-requests or leave it as gaia-try