James Lal [:lightsofapollo] Reporter
	Description • 10 years ago

      No description provided.

	James Lal [:lightsofapollo] Reporter
	Comment 1 • 10 years ago

Adding flatfish builds here not mission critical but still important and another good show case for us.

	Armen [:armenzg]
	Comment 2 • 9 years ago

I'm analyzing this bug to have a better understanding what are the current issues that sheriffs are facing with TC.
From looking at it, it seems that this bug tracks general transition issues + sheriff issues.

Sheriff issues (which we should consider as MAJOR):
###################################################
Bug 1147867 - Run failed with no usable log output to Treeherder

Bug 1147963 - tc-tools: Copying text from log viewer (Inspect Task) has very poor UX

Bug 1148847 - Remove pip errors from builder logs

Bug 1148941 - gecko, tc-vcs: Decision tasks should fail if tc-vcs fails to pull hg.m.o
* Patched becked out because missing redo module

Bug 1154669 - *CRITICAL* Taskcluster B2g Build fails with bustage
* Depends on Bug 1132574 - gecko: Use branch specific caches for builds

Bug 1165759 - *CRITICAL* Intermittent TC build failures due to failing to fetch
* Depends on Bug 1156326 - [garndt-q2-goal] Investigate/implement pushing/pulling docker images to s3
* Depends on Bug 1165760 - Jobs which fail fetching a Docker image need to improve output

Bug 1170701 - Taskcluster B2G-emulator test runs don't provide a crash stack for reftests

Bug 1171809 - docker-worker: Listen to pulse exchange to blow away named caches (proposal)

Releng issues:
##############
* Bug 1174263 - Update the clobberer tool to support clobbering Taskcluster-based builds

General migration issues (not sheriff specific):
################################################
* Bug 1130763 - gecko: Emulator ICS Mochitest 11 perma fail
* Bug 1130764 - gecko: Permafail emulator-ics mochitest 12
* Bug 1130773 - gecko: Permafail emulator-ics X(pcshell) fail due to what looks like b2g startup failure

Support issues:
###############
* bug 1108154 - Create try-extender
** The idea is to have a UI to help us extend which platforms are run on a try push
** This is similar to the trychooser UI, however, it would also allow you to select platforms and request them
** This can be easily be built with a self-serve for TC plus a UI
** This does not sound like a blocker but it will be more pressing as more platforms move
** In fact, we might be able to use the buildbot bridge to schedule buildbot jobs (bonus)

	Armen [:armenzg]
	Comment 3 • 9 years ago

We can also look at this bug as tier-1 issues and/or requirements to fullfil the visibility needs:
https://wiki.mozilla.org/Sheriffing/Job_Visibility_Policy

	Armen [:armenzg]
	Comment 4 • 9 years ago

selena: I would like to remove bug 1108154 from the list of dependencies since it is not related to keeping up to par with the buildbot setup (i.e. this is an enhancement that we don't have on the current buildbot setup).

I have my intern working on a tool like this but I don't believe it is a blocker to bringing TaskCluster up to par (bug 1185537).

	Armen [:armenzg]
	Comment 5 • 9 years ago

Removed bug 1108154. ack through IRC.

	Armen [:armenzg]
	Comment 6 • 8 years ago

Do we need this for TaskCluster? I don't think so but wanted to ask.

Jobs taken by individual hosts https://secure.pub.build.mozilla.org/builddata/reports/slave_health/slave.html?class=test&type=tst-emulator64-spot&name=tst-emulator64-spot-125

	Armen [:armenzg]
	Comment 7 • 8 years ago

Adding a bunch of bugs that need polishing from bug 1243024 since they don't specifically block Linux from becoming a tier1 platform but they're deficiencies of the TaskCluster set up or optimizations.

	Armen [:armenzg]
	Comment 9 • 8 years ago

In one of the email threads about Linux64 debug transition one of the developers raised the inability to "add new jobs" for L64 debug TC jobs.

martianwars is working on it in bug 1254325.

Adding it as a dependency.

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 10 • 8 years ago

I'd close this, but I see armen adding deps..

	Armen [:armenzg]
	Comment 11 • 8 years ago

There's no need to have an assignee for this.
It's simple to track what features are left to reach parity.

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 12 • 8 years ago

Ed, I sort of feel like this in your scope, then?  I suspect that the dependencies of this bug are a partial list of features that do not exist in TaskCluster and will, at some point, be required in order to port some functionality to TaskCluster.

	Dustin J. Mitchell [:dustin] (he/him)
	Comment 13 • 8 years ago

Geoff, I'm not sure how using, or not using, MOZ_SIMPLE_NAMES is related to feature parity between Buildbot and TaskCluster..

	Geoff Brown [:gbrown]
	Comment 14 • 8 years ago

(In reply to Dustin J. Mitchell [:dustin] from comment #13)
> Geoff, I'm not sure how using, or not using, MOZ_SIMPLE_NAMES is related to
> feature parity between Buildbot and TaskCluster..

My thinking was, buildbot tests can work with or without MOZ_SIMPLE_PACKAGE_NAME, whereas taskcluster tests can only work with MOZ_SIMPLE_PACKAGE_NAME. We're just discovering ways around that now. Still, practically, Linux and Android taskcluster build artifacts are currently generated with MOZ_SIMPLE_PACKAGE_NAME, so installers, etc are named differently (arguably in an inferior way) from those created by buildbot jobs.