Closed Bug 396290 Opened 12 years ago Closed 10 years ago

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

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: joduinn, Unassigned)

References

Details

Attachments

(1 file)

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.
Priority: -- → P3
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.
Assignee: build → rhelmer
Status: NEW → ASSIGNED
Attachment #282507 - Flags: review?(preed)
Attachment #282507 - Flags: review?(preed) → review+
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
Attachment #282507 - Attachment description: fix a few small bugs in respin support → [checked in]fix a few small bugs in respin support
Assignee: rhelmer → build
Status: ASSIGNED → NEW
Assignee: build → nobody
QA Contact: mozpreed → build
This looks done, can it be closed?
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?
(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).
(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.
Component: Release Engineering → Release Engineering: Future
QA Contact: build → release
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
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.