How will this work with release branches like ESR52? On Wed, Sep 13, 2017 at 1:25 PM, Cameron Dawson <cdaw...@mozilla.com> wrote:
> 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) 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 > > 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: > > 1. Make the mechanism for hiding jobs simpler (reduce from 2 paths to > 1) > 2. Put the tier and hiding capability in the hands of the test authors > 3. Make it easier for 3rd party tools to identify which tests are > hidden > > > The current system has several drawbacks: > > > 1. There are three different ways we track/apply tiers/visibility > (in-tree, in Treeherder at time of ingestion, in Treeherder at time of > retrieval) > 2. Confusing logic for setting Tiers in TaskCluster definitions. This > tier setting can be overridden (intentionally or unintentionally) by the > treeherder visibility/tier profiles. > 3. We have 6 different states (3 tiers x hidden+not hidden) > 4. Considerable business logic in Treeherder that is cumbersome to > understand and maintain. > 5. Unnecessary burden on Sheriffs: > 1. on merge day, they must manually change visibility for eg > mozilla-beta (since the in-tree logic will follow the code around) > 2. 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. > 6. 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 > == Additional Details (optional) == More detail can be found here: > > https://docs.google.com/document/d/1-BzCN97aCZKovWeh1zU6ASyp_FVtg0mbITN7C_iWXzg/edit# > > > Please let me know if you have any comments or suggestions. > > Thanks!! > > -Cam > > > > _______________________________________________ > Sheriffs mailing list > sheri...@mozilla.org > https://mail.mozilla.org/listinfo/sheriffs > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
