396290 - adjust staging-build-console master.cfg to include respins

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P3)

Description

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

How about changing staging-build-console to test respins every time. Currently, the staging console master.cfg does a full end-to-end run, intentionally identical to the live build-console master.cfg:

tag
(source, linuxbuild, macbuild, winbuild)
sign
(l10nverify, update)
(linuxupdateverify, macupdateverify, winupdateverify, stage)


However, this does not test respins. If we changed *only* staging-build-console to do:

tag
(source, linuxbuild, macbuild, winbuild)
*** script change to bootstrap.cfg ***
tag
(source, linuxbuild, macbuild, winbuild)
sign
(l10nverify, update)
(linuxupdateverify, macupdateverify, winupdateverify, stage)

...then we would know that all automation scripts tests both normal/first process codepath as well as respins. 

Otherwise, we would only be testing respin logic during a real live production respin.

Comment 1

[Robert Helmer [:rhelmer]]

Attachment: [checked in]fix a few small bugs in respin support

Pretty minor stuff:

1) use "cvs -q diff" in GetDiffFileList(), otherwise you get junk from CVS like:

cvs [tag aborted]: no such directory `he/other-licenses/bracvs diff: Diffing he'
log: Bootstrap::Step::Tag::CvsTag failed; rv: 1, timeout: 0, output: cvs [tag aborted]: no such directory `he/other-licenses/bracvs diff: Diffing he'

2) call GetDiffFileList() as a regular function and not a method on Bootstrap::Tag

It's either this or add a "my $this=shift", I think this is more consistent with how Bootstrap::Util has been used up til now.

Respin support seems to work fine by setting "rc" to greater than 1 in the bootstrap.cfg, with these changes.

Comment 2

[Robert Helmer [:rhelmer]]

Comment on attachment 282507 [details] [diff] [review]
[checked in]fix a few small bugs in respin support

Checking in Bootstrap/Util.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Util.pm,v  <--  Util.pm
new revision: 1.6; previous revision: 1.5
done
Checking in Bootstrap/Step/Tag.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Step/Tag.pm,v  <--  Tag.pm
new revision: 1.16; previous revision: 1.15
done
Checking in Bootstrap/Step/Tag/Mozilla.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Step/Tag/Mozilla.pm,v  <--  Mozilla.pm
new revision: 1.5; previous revision: 1.4
done
Checking in Bootstrap/Step/Tag/l10n.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Step/Tag/l10n.pm,v  <--  l10n.pm
new revision: 1.8; previous revision: 1.7
done

Comment 3

[[e-mail] (:bhearsum)]

This looks done, can it be closed?

Comment 4

[[e-mail] (:bhearsum)]

I like the idea of doing respins every night in general, but it will add many hours to the nightly run :(. Given those two options, I'd opt for not doing respins every night. What do others think?

Comment 5

[Robert Helmer [:rhelmer]]

(In reply to comment #4)
> I like the idea of doing respins every night in general, but it will add many
> hours to the nightly run :(. Given those two options, I'd opt for not doing
> respins every night. What do others think?

I think we only really need to run this for the Tag step (e.g. create a tag, then bump rc and create a respin, then build).

Comment 6

[[e-mail] (:bhearsum)]

(In reply to comment #5)
> (In reply to comment #4)
> > I like the idea of doing respins every night in general, but it will add many
> > hours to the nightly run :(. Given those two options, I'd opt for not doing
> > respins every night. What do others think?
> 
> I think we only really need to run this for the Tag step (e.g. create a tag,
> then bump rc and create a respin, then build).
> 

Hmm, that's a much easier hit to take.

Comment 7

[[e-mail] (:bhearsum)]

We haven't done a mock release on staging-1.9 in a very long time (to my knowledge). We certainly don't do them on a regular basis. More to the point, I don't think the work it will take to resolve this bug is worth the effort at this point.

Comment 8

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

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