422759 - l10n builds should upload once ready

Status: RESOLVED FIXED

(Release Engineering :: General, enhancement, P3)

Description

[Axel Hecht [:Pike]]

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.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

Do you have any plans to work on this ? I think it would be good too. 

Comment 2

[Axel Hecht [:Pike]]

No, I don't have plans to work on this.

Comment 3

[Tim Riley [:timr]]

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?

Comment 4

[Tim Riley [:timr]]

joduinn- any ETA on this?  I'll follow-up with an email also.

Comment 5

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

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.

Comment 6

[Axel Hecht [:Pike]]

(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?

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

(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.

Comment 8

[Axel Hecht [:Pike]]

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?

Comment 9

[Axel Hecht [:Pike]]

(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.

Comment 10

[Axel Hecht [:Pike]]

With builds coming from buildbot per locale now, this is FIXED.

Comment 11

[Chris Cooper [:coop] (he/him)]

Moving closed Future bugs into Release Engineering in preparation for removing the Future component.