Closed Bug 1274311 Opened 4 years ago Closed 3 years ago

Tier 2 TC tasks submitting to the same index key as tier 1 BB jobs

Categories

(Release Engineering :: General, defect)

defect
Not set

Tracking

(firefox50 fixed)

RESOLVED FIXED
Tracking Status
firefox50 --- fixed

People

(Reporter: rail, Assigned: mshal)

References

Details

Attachments

(1 file)

This is the log of a buildbot linux64 opt build:

http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1463665129/mozilla-inbound-linux64-bm72-build1-build1516.txt.gz

According to the log, it generates a TC task https://tools.taskcluster.net/task-inspector/#Cgszc2O4RNerKjJizDNUNA/ for artifacts and indexes itself as

index.gecko.v2.mozilla-inbound.revision.2fb9523055a61f02804393dc6f479bfd0427a1a8.firefox.linux64-opt


At the same time we have a tier 2 build in TC:
https://tools.taskcluster.net/task-inspector/#Na7XoA9PQiaK8dO-e1E52w/

It also indexes itself using the same index.

ATM, the index points to the BB job:
https://tools.taskcluster.net/index/#gecko.v2.mozilla-inbound.revision.2fb9523055a61f02804393dc6f479bfd0427a1a8.firefox.linux64-opt/gecko.v2.mozilla-inbound.revision.2fb9523055a61f02804393dc6f479bfd0427a1a8.firefox.linux64-opt

but it's not impossible to get it point to the tier 2 task, what would be a blocker for release promotion, which uses the index service to find the corresponding tasks and artifacts.

Maybe we should add another route to make sure we have a way to distinguish these tasks?
Duplicate of this bug: 1280614
Given that BB jobs are going away we should maybe add another key or suffix for it like:

gecko.v2.mozilla-inbound.revision.2fb9523055a61f02804393dc6f479bfd0427a1a8.firefox.linux64-opt.buildbot
I don't think we want to use a separate route with buildbot in the name - for some more details, see also this discussion here: https://bugzilla.mozilla.org/show_bug.cgi?id=1277666#c6

Though we do still need to address tier 2 builds. I think they should probably just have a rank of 0, so while the Taskcluster build is being worked on, it won't impact the route that points to the buildbot task. After Taskcluster is promoted to tier 1, we can shut off the equivalent buildbot build and not impact any users of the index.
TC was recently updated to use the pushdate in bug 1277666 - previously it was the pushlog id.

I think I have a patch that will just set the rank to 0 for tier > 1, so if we have both a tier 1 and tier 2 job, only the tier 1 job will show up in the index. Tier 2+ jobs will still show up in the index if there is no tier 1 equivalent, though.
Assignee: nobody → mshal
(In reply to Michael Shal [:mshal] from comment #6)
> I think I have a patch

Whee! :)

Thanks for the explanation. If the rank solves the issue, it totally WFM!
Depends on: 1282515
Comment on attachment 8765941 [details]
Bug 1274311 - tier-2 jobs should have rank 0 in the index;

https://reviewboard.mozilla.org/r/61052/#review57914

::: taskcluster/taskgraph/kind/legacy.py:459
(Diff revision 1)
> +            if 'treeherder' in task_extra:
> +                tier = task_extra['treeherder'].get('tier', 1)
> +                if tier != 1:
> +                    # Only tier 1 jobs use the build time as rank. Everything
> +                    # else gets rank 0 until it is promoted to tier 1.
> +                    task_extra['index']['rank'] = 0

I like this!
Attachment #8765941 - Flags: review?(dustin) → review+
Pushed by mshal@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/47c2b7937aa7
tier-2 jobs should have rank 0 in the index; r=dustin
Woot!
https://hg.mozilla.org/mozilla-central/rev/47c2b7937aa7
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.