Closed
Bug 611670
Opened 14 years ago
Closed 12 years ago
Drop the use of sendchange in favor of trigger, or equiv that keeps sourcestamp
Categories
(Release Engineering :: General, defect)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: Pike, Unassigned)
References
Details
(Whiteboard: [l10n][automation])
The extensive use of sendchange makes our build status a confusing mess. There shouldn't be anything in sendchange that we can't reproduce on top of scheduler db, hopefully. With http://buildbot.net/trac/ticket/1039, plain trigger should probably do it. The dependent/triggered builds should keep the sourcestamp of the original build, as that's, for one, the right thing to do, and it will make reporting so easy that we don't need to restrict the build infrastructure to only change in ways that the reporting hacks wouldn't break. I.e., if our builds were organized such that the reporting on top just had to show what's there, we can improve our builds without worrying that the reporting would break, or how it would show today's and last week's builds.
Comment 1•14 years ago
|
||
This is something we've been thinking about for a while, so thanks for filing the bug! We could actually use Trigger/Triggerable right now, but it makes the configs a bit ugly since all the Triggerable schedulers have to be active on each master. I'm not sure I understand all that you're saying about reporting...In some cases you would share the same sourcestamp, but I'm not sure if that's true across the board?
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > I'm not sure I understand all that you're saying about reporting...In some > cases you would share the same sourcestamp, but I'm not sure if that's true > across the board? The only challenge I saw was determening the sourcestamp for triggered l10n nightlies. There are arguments in favor of using the en-US sourcestamp and against. Like, it makes all the nightlies report is probably both pro and con, depending on how you look at it.
Updated•14 years ago
|
Priority: -- → P4
Updated•12 years ago
|
Component: Release Engineering → Release Engineering: Automation
Priority: P4 → --
QA Contact: release → catlee
Whiteboard: [l10n][automation]
Comment 3•12 years ago
|
||
Axel, does build 'builduid' property cover what you need here? This is created by the scheduler for the builds, and propagated down to tests, repacks, etc.
Reporter | ||
Comment 4•12 years ago
|
||
I don't have concrete ideas these days. This might impact what can be done with the web reporting for l10n builds, though, which is now bug 698910.
Blocks: 698910
Comment 5•12 years ago
|
||
If you have some concrete changes we can make, please open up a new bug at that point. Thanks!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Updated•6 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•