554749 - Release tagging should only operate on release branches

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P3)

Description

[Chris AtLee [:catlee]]

For 3.6.2 build 2 the release automation ended up tagging the default branch with FIREFOX_3_6_2_RELEASE, which caused issues later on with l10n repacks.

The release tagging should never be tagging revisions that aren't on a relbranch.

Comment 1

[Rail Aliiev [:rail]]

Attachment: Switch to relbranch

Switch to relbranch without any condition.

Comment 2

[Chris AtLee [:catlee]]

Comment on attachment 458307 [details] [diff] [review]
Switch to relbranch

Hmmm...How did 3.6.2 build2 end up tagging the default branch?

Also, I think this will fail on build 1, since the new branch hasn't been really created yet.

Comment 3

[[e-mail] (:bhearsum)]

Planning to fix this this quarter.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to comment #2)
> Comment on attachment 458307 [details] [diff] [review]
> Switch to relbranch
> 
> Hmmm...How did 3.6.2 build2 end up tagging the default branch?
> 
> Also, I think this will fail on build 1, since the new branch hasn't been
> really created yet.

For posterity, what happened here was that sourceRepoRevision was pointing at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/827a6883442f in build2, so the tag commits were on the relbranch, but they pointed at a revision on default. So what we _really_ want to do here is add a check that verifies that the revision we're going to tag is on the relbranch that's been specified, when buildNumber > 1.

Comment 5

[[e-mail] (:bhearsum)]

bug 607372 added some verification that ensure we have the expected number of changesets on the relbranch/default. Therefore, this is FIXED by that.