Open Bug 1252999 Opened 5 years ago Updated 2 years ago

Pushing to try from a specific head should schedule the set of jobs associated to that specific head/repository


(Firefox Build System :: Try, defect)

Not set


(Not tracked)


(Reporter: ahal, Unassigned)


(Blocks 1 open bug)


This isn't a priority or anything, just a neat idea that I wanted to write down somewhere before I forgot.

The Problem:
Often people want to push to try based from another tree, e.g aurora, beta or release. This works, except the try push will have the set of jobs for mozilla-central run against it. Even though this set of jobs may be different than the set of jobs for e.g mozilla-release.

We could add some logic to automatically detect which tree a push is based off of, and automatically use the corresponding set of configs. So if I do:

$ hg update release
$ hg commit -m "try: -a"
$ hg push -f -r . try

I'd automatically get the set of jobs that normally run on mozilla-release. We could also do some crazy things like add a --branch argument to try syntax if there was a need.

We'd have to figure out what to do with jobs that are *only* run on try. I guess they'd be run no matter what tree is pushed from.
Blocks: awesome-try
Depends on: 1243759
Andrew, I suspect that this would be rolled into the new try mechanism (bug 1262165), right?
Component: Scheduler → Integration
Component: Integration → General
Product: Taskcluster → Testing
Possibly? I'm not really sure :).

Though to clarify, this is more about choosing what the "default set" is, rather than picking specific jobs within the default set. So for example right now the try branch configs mirror the m-c branch configs. I was thinking they should mirror whatever branch configs were pushed from. There's probably a way to do that client side..
What does it mean to push "from" a branch?  Like, if I'm on a bookmark named "aurora" it uses the aurora configs?  That's probably *not* what I want in most cases..
More or less yes, though we'd need some light hg magic to determine the changeset we're pushing from is actually based on top of the aurora head. I haven't thought much about how to do that, but maybe it could make use of the fxtree namespace that firefoxtree creates. Out of curiosity, why wouldn't you want that? I think this will primarily benefit sheriffs who regularly push to try based off of different heads.

Fwiw, I wouldn't worry too much about this bug. It was a neat idea I had that I wanted to get a bug on file for. But I don't think it's worth the effort it will take to get done just yet. It may be easier to implement in the future.
Well, my workflow is generally to update to one of the integration branches - central or inbound - and then hack, and push to try.  I would want *try* behavior in that case, not central or inbound.
Right, I'm still suggesting we get *try* behaviour. I just mean the set of possible jobs to select from would be different.

For example, let's pretend "mochitest-gl" is defined in the mozilla-central branch configs here:

But it's not defined in the (theoretical) aurora job flags. If I run |try: -all| from the aurora head, then the mozilla-central job configuration will be used and "mochitest-gl" will be run on my push. Even though there are 0 expectations that that job should work on aurora. The proposal here, is to instead of having a try branch config, we re-use whatever one is being pushed from.

Feel free to ping me in irc if I'm not making sense :).
I want to change the title of the bug to easily understand what the goal is to:
"Pushing to try from a specific repository should schedule the set of jobs associated to that specific repository"

Would this work for you?
Sure, but specific repository can be misleading because of the firefox-unified repo. It's more like "pushing from a specific head that's correlated to a repository".
Good point.
Summary: Dynamically choose which branch configs to use for Try pushes → Pushing to try from a specific head should schedule the set of jobs associated to that specific head/repository
This is starting to come up as we introduce nightly builds -- for example, we've discussed doing "nightly" builds on-push on mozilla-beta.  So maybe we need some larger concept that "nightly" and "release" and "dep" and whatnot fall into, and a way to specify that per-tree and in try syntax?
No longer depends on: 1243759
From a release management perspective I think this sounds great. If we know the right set of tests are running for a particular branch, I would feel more sure that it would be useful to ask developers to push to try before they request uplift to beta, release, etc.   

Especially for beta and release, we are under a fair amount of pressure to act quickly, so waiting for a sheriff to land their changes, tests to pass, then back out a failure, can delay a release. That might put the extra time onto the developer, and might mean they lose context by the time the try push is finished.  Still, less time for them than if they request uplift and their patch lands on beta a week later only to have to be backed out.
Component: General → Try
Product: Testing → Firefox Build System
You need to log in before you can comment on or make changes to this bug.