Drop the use of sendchange in favor of trigger, or equiv that keeps sourcestamp

RESOLVED WORKSFORME

Status

Release Engineering
General Automation
RESOLVED WORKSFORME
7 years ago
4 years ago

People

(Reporter: Pike, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [l10n][automation])

(Reporter)

Description

7 years ago
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.
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

7 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.
Priority: -- → P4
Blocks: 614548
No longer blocks: 614548

Updated

5 years ago
Component: Release Engineering → Release Engineering: Automation
Priority: P4 → --
QA Contact: release → catlee
Whiteboard: [l10n][automation]
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

5 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
If you have some concrete changes we can make, please open up a new bug at that point. Thanks!
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.