1381130 - Tier 1 windows build work reverts part of Bug 1379603

Status: RESOLVED INCOMPLETE

(Infrastructure & Operations :: RelOps: General, task)

Description

[Justin Wood (:Callek)]

Hey :grenade,

After hitting a complicated merge conflict, I went and manually grafter your work then merged central to date.

The end result is that we are *not* using tc windows hardware for talos on try on date, and when this lands to central (ideally within a few weeks) we'll be doing talos via BBB, so you'd need a different solution/patch to run on hardware.

Our alternate version of your patch was https://hg.mozilla.org/projects/date/rev/6763fad71546ff3c9fbae49cf41e51867fdabdd3

Comment 1

[Rob Thijssen [:grenade (EET/UTC+0300)]]

noted. i think we're going to just live with it for a bit. my patch was to support taskcluster windows hardware which is not yet ready. when the date patches land, we'll just compensate by altering the transform in try pushes for our hardware testing until we're ready to switch over or we find a way to enable both (tc & bbb).

Comment 2

[Mark Cornmesser [:markco]]

Callek: It sounds like we can't put these test in tree for TaskCluster until we switch them fully to TaskCluster?

Comment 3

[Justin Wood (:Callek)]

(In reply to Mark Cornmesser [:markco] from comment #2)
> Callek: It sounds like we can't put these test in tree for TaskCluster until
> we switch them fully to TaskCluster?

I think that's a fair assessment. We likely don't want them being scheduled with every push until we have some suspicion of them being ready or near ready, even if we demote to tier 3, we also don't want those jobs to confuse developers pushing to try "wait do I need these, why are they pending".

For anyone actively working on greening them up on try we can work from a shared patch queue, project branch, or write temporary logic in tree to activate them, should it come to that.

Comment 4

[Amy Rich [:arr] [:arich]]

callek: we wanted them in tree but disabled by default so we could actually do testing. This sems like a bit of chicken/egg problem. We can't add them till they're ready, but we can't tell they're ready without doing much more testing. What do you recommend?

Comment 5

[Justin Wood (:Callek)]

(In reply to Amy Rich [:arr] [:arich] from comment #4)
> callek: we wanted them in tree but disabled by default so we could actually
> do testing. This sems like a bit of chicken/egg problem. We can't add them
> till they're ready, but we can't tell they're ready without doing much more
> testing. What do you recommend?

The problem here was that the patch was effectively scheduling them on try, with any push that had windows testing needs. So even before the switchover I had heard of a handful of devs asking why they hadn't gotten windows 10 results "yet".

We/you can craft a patch to enable them for any try push you need when they are "ready for validation/testing". And that patch can be pushed to try, and we can see the results (if any) on that push, without needing the code checked in for every developer to run it.

If your testing needs are that you do need every developer to run it and see signs of what the load is, we can write some sort of transform to enable them on try, but as tier 3, and if necessary use similar logic to chunking, so that it also runs the proper testing the dev would expect. Unless you do have a need for most checkins to try to be scheduling these suites I'd rather not go down this route.

I feel the testing that can be done on try via individual pushing should be sufficient, do you disagree, or is this more of a misunderstanding of possibilities and needs that just needs a meeting and maybe a whiteboard to get us on the same page?

Comment 6

[Amy Rich [:arr] [:arich]]

(In reply to Justin Wood (:Callek) from comment #5)

Ah, no we did NOT want to schedule a task on every push from try. Can someone help craft a patch that would only enable push on demand? That was the original desire/intention, and it sounds like it was just mistaken execution.