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

Tinderbox auto-update should update to a stable tag, not to HEAD

RESOLVED WONTFIX

Status

Webtools Graveyard
Tinderbox
P3
normal
RESOLVED WONTFIX
11 years ago
3 years ago

People

(Reporter: preed, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
The tinderbox auto-update code (part of bug 329573) should not always update to HEAD; it should update to a known stable tag.

This is so if bad code goes into Tinderbox, all of them don't suddenly start breaking.
(Reporter)

Comment 1

11 years ago
Created attachment 232813 [details] [diff] [review]
Take 1
Attachment #232813 - Flags: review?(rhelmer)
Attachment #232813 - Flags: review?(rhelmer) → review+
QA Contact: timeless → tinderbox
(Reporter)

Comment 2

11 years ago
Reassigning bugs I'm not actively working on back into the triage pool.
Assignee: preed → build
Priority: -- → P3
We're implementing something similar to this over in bug 397554; Nick do you think we should roll this out as well? We'll continue to have multi-tinderbox builders for some time as well..

I'm not sure if we should do a tag or HEAD for nightly builders, honestly. We talked about doing HEAD over in bug 397554, to make sure that it stays building, and then cut a tag for releases (e.g. latest known-good nightly). 
my 2ยข (adjusted for inflation and exchange) is that a tag would probably be better. We could use the unittest machines as part of the tagging process, ensuring their results were clean (and green) before applying the tag.
My concern about using a stable tag relates to how we manage that tag, in particular how we test new patches against Tinderbox. The unittest boxes seem like they're a fairly risky place to try things, because they aren't delivering builds to the ftp server, and they've become so critical to developers. We could use the staging environments for the release automation, if we think we can separate issues from Bootstrap, and don't mind about not testing multi-tinderbox. Otherwise we're into a dedicated staging environment for tinderbox.

Bonsai says there have been 130 checkins in mozilla/tools/tinderbox since this bug was filed 2006, and I (boldly!) assert there haven't been anywhere near that many farm-killing events. Sure we're vulnerable, but I'm not it's worth the effort given we have a fairly strong review process. That's my 1 pence worth any way.
Tentatively WONTFIXing based on Nick's comments.

Robcee, maybe I am misunderstanding, but unit tests don't use Tinderbox code right, how would it help to make sure that the Tinderbox code wasn't broken?
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WONTFIX
Product: Webtools → Webtools Graveyard
You need to log in before you can comment on or make changes to this bug.