If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Make Treestatus part of Treeherder

RESOLVED WONTFIX

Status

Release Engineering
TreeStatus
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: KWierso, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Waaaay down the road, since treeherder is supposed to become the single point of truth about the state of the trees, I think that at some point the treestatus api should be moved to be part of Treeherder, so I can close a tree (or all trees) directly from Treeherder's UI.

Comment 1

3 years ago
I know one of the intentions with the current tree status site was to make it simple, reliable and separate from other services that have worse uptime.

I'd very much like better control of the trees from treeherder - however that may be best done using the treestatus API and the persona logins that both will be using.

For example one problem with including treestatus in treeherder, is that at least for the moment, pushing a treeherder deploy causes server errors whilst the processes are being restarted (a la bug 1088226) - which would cause disruption to people to hg.m.o, since the hook would fail closed.

Also, I know gps et al see autoland becomming the main entrypoint for code in the future (ie !sheriffs never go near the tree), in which case closing the tree becomes "telling autoland to pause", which really becomes "make autoland clever enough to not push on a broken tree". As such, I'm wondering if it's worth spending too much time on rewriting treestatus to be a reliable part of treeherder, until those workflows and requirements are clearer?
OS: Windows 8.1 → All
Priority: -- → P5
Hardware: x86_64 → All

Comment 2

3 years ago
(In reply to Ed Morley [:edmorley] from comment #1)
> I'd very much like better control of the trees from treeherder - however
> that may be best done using the treestatus API and the persona logins that
> both will be using.

ie: Have treestatus remain separate, but have quick access controls in treeherder, that allow easier opening/closing without having to leave the treeherder UI (similar to the buildapi retrigger/cancel buttons that save having to visit self-serve).

Comment 3

2 years ago
Moving this to TreeStatus, since I think the discussion needs to happen with the stakeholders there first :-) (And hopefully some of those are watching the TreeStatus component)
Component: Treeherder → TreeStatus
Priority: P5 → --
Summary: Treestatus should become part of Treeherder → Decide if Treestatus should become part of Treeherder
(Reporter)

Comment 4

2 years ago
Comment 1/2 seems good enough to me. Wouldn't mind trying to do the work myself if we choose to go that way.
(Assignee)

Updated

2 years ago
Product: Tree Management → Release Engineering
This could be done via RelengAPI now, if desired.  I don't think this is a treestatus issue anymore.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
QA Contact: dustin
Resolution: --- → FIXED

Comment 6

2 years ago
I think this is a WONTFIX.
Resolution: FIXED → WONTFIX
Summary: Decide if Treestatus should become part of Treeherder → Make Treestatus part of Treeherder
You need to log in before you can comment on or make changes to this bug.