Just an update that Bug 1387640 is progressing and soon the “Excluded Jobs” button in Treeherder will disappear.
We have rolled out the changes to our staging environment (treeherder.allizom.org <http://treeherder.allizom.org/>) and will let it soak for a day or so before pushing to production. Going forward, to view “hidden” jobs, you will need to check “tier 3” in the tiers menu. To hide a job, you would follow these instructions: https://treeherder.readthedocs.io/common_tasks.html#hide-jobs-with-tiers <https://treeherder.readthedocs.io/common_tasks.html#hide-jobs-with-tiers> If you find a job that was previously hidden, but which no longer is, then please file a bug against Treeherder for BuildBot jobs and Taskcluster for TC jobs. Thanks for your time! -Cam > On Sep 8, 2017, at 12:30 PM, Cameron Dawson <cdaw...@mozilla.com> wrote: > > == Summary == > Remove the use of Exclusion Profiles to hide jobs and set Tier values. We > will expect the correct tier value to be set in a test’s Task Definition > (default to 1). > Anything hidden from BuildBot will be managed in the Treeherder code-base > directly. > > == Use cases / Motivation == > > The mechanism that is currently used in Treeherder for hiding jobs is overly > cumbersome and redundant with the Tier system. > > The main issues we are trying to solve for Treeherder users are: > Make the mechanism for hiding jobs simpler (reduce from 2 paths to 1) > Put the tier and hiding capability in the hands of the test authors > Make it easier for 3rd party tools to identify which tests are hidden > > The current system has several drawbacks: > > There are three different ways we track/apply tiers/visibility (in-tree, in > Treeherder at time of ingestion, in Treeherder at time of retrieval) > Confusing logic for setting Tiers in TaskCluster definitions. This tier > setting can be overridden (intentionally or unintentionally) by the > treeherder visibility/tier profiles. > We have 6 different states (3 tiers x hidden+not hidden) > Considerable business logic in Treeherder that is cumbersome to understand > and maintain. > Unnecessary burden on Sheriffs: > on merge day, they must manually change visibility for eg mozilla-beta (since > the in-tree logic will follow the code around) > when people stand up new tests - the sheriffs are asked to add a job to the > exclusion profile instead of the tier being in the in-tree code. > Unnecessarily hard for tooling to analyze mozilla-central and determine what > proportion of jobs are not even visible and could be switched off, or set to > a lower priority. > > > == Timeframe == > > I expect to complete this work by end of September 2017 > > == Tracking progress == > > https://bugzilla.mozilla.org/show_bug.cgi?id=1387640 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1387640> > > == Additional Details (optional) == > More detail can be found here: > https://docs.google.com/document/d/1-BzCN97aCZKovWeh1zU6ASyp_FVtg0mbITN7C_iWXzg/edit# > > <https://docs.google.com/document/d/1-BzCN97aCZKovWeh1zU6ASyp_FVtg0mbITN7C_iWXzg/edit#> > > Please let me know if you have any comments or suggestions. > Thanks!! > -Cam _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
