Closed Bug 422759 Opened 12 years ago Closed 11 years ago

l10n builds should upload once ready

Categories

(Release Engineering :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Pike, Unassigned)

References

(Blocks 1 open bug)

Details

Currently, tinderbox runs through all locales and tries to repack builds, and once it's through all locales, uploads the successful builds.

That yields to a timewindow between the point in time when the locale tinderbox reports a successful build and that build showing up on ftp.

This likely blocks any automated l10n runtime testing, i.e., Minotaur on buildbot, bug 416228.
Do you have any plans to work on this ? I think it would be good too. 
Severity: normal → enhancement
Component: Build & Release → Release Engineering: Projects
Priority: -- → P3
QA Contact: build → release
No, I don't have plans to work on this.
We talked about this in a L10n/Minotaur meeting with joduinn, robcee, clint on March 13th.  My understanding was that joduinn owned this, but he wasn't sure when the Build team could get to it.  

Joduinn- could we get and ETA on this?
joduinn- any ETA on this?  I'll follow-up with an email also.
1) We have some l10n projects in mind for Q2, which should streamline a lot of things, including I believe, the problem in comment#1. I dont have a ETA on this yet, but I'll have more details once we've scoped the work, and set our Q2 goals.

2) Note: The stage migration project includes now virus checking newly uploaded files *before* they are made visible on FTP. This means that customers can never download infected files, which is good. However, it also adds a delay after uploading files before the files are visible...which I suspect will cause Minotaur problems. 

3) In the meanwhile, can Minotaur look on FTP for new builds, rather then relying on tinderbox as a reliable trigger? This change would be better in the "after stage migration" world, imho.
(In reply to comment #5)
> 1) We have some l10n projects in mind for Q2, which should streamline a lot of
> things, including I believe, the problem in comment#1. I dont have a ETA on
> this yet, but I'll have more details once we've scoped the work, and set our Q2
> goals.

Are there bugs on file for those? I'd like to be on CC.

> 2) Note: The stage migration project includes now virus checking newly uploaded
> files *before* they are made visible on FTP. This means that customers can
> never download infected files, which is good. However, it also adds a delay
> after uploading files before the files are visible...which I suspect will cause
> Minotaur problems. 
> 
> 3) In the meanwhile, can Minotaur look on FTP for new builds, rather then
> relying on tinderbox as a reliable trigger? This change would be better in the
> "after stage migration" world, imho.

How does Talos deal with that?
(In reply to comment #5)
> 2) Note: The stage migration project includes now virus checking newly uploaded
> files *before* they are made visible on FTP. This means that customers can
> never download infected files, which is good. However, it also adds a delay
> after uploading files before the files are visible...which I suspect will cause
> Minotaur problems. 

Fixing this bug would minimize this effect, since it spreads out the virus-scanning load rather than dumping them all at the end of the t'box run.

(In reply to comment #6)
> How does Talos deal with that?

The builds that will be used by Talos will have a dedicated fast-path through the virus scanning, to minimize the lag between build finish and being available on the FTP. Talos currently polls quickparse.txt and waits 5 minutes before triggering a slave.
To lead this discussion totally off-topic, is a bug or a feature that our builds go through virus checking before they get to testing?
(In reply to comment #5)
<...>
> 3) In the meanwhile, can Minotaur look on FTP for new builds, rather then
> relying on tinderbox as a reliable trigger? This change would be better in the
> "after stage migration" world, imho.

We don't have a buildbot change source for that, though. So that'd be a different bug to file and fix.
With builds coming from buildbot per locale now, this is FIXED.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Moving closed Future bugs into Release Engineering in preparation for removing the Future component.
Component: Release Engineering: Future → Release Engineering
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.