813538 - Tagging which uses an existing relbranch can fail to bump version files

Status: RESOLVED WONTFIX

(Release Engineering :: Release Automation: Other, defect, P3)

Description

[Mark Banner (:standard8)]

We saw this with Thunderbird 17.0esr build 3 - the tagging re-used the Firefox relbranch, but didn't bump the version files.

What had happened:

1) Firefox had already tagged mozilla-esr17 and bumped the version files for Thunderbird.

Firefox relbranch was GECKO170_2012111907_RELBRANCH, signed-off changeset for Firefox was http://hg.mozilla.org/releases/mozilla-esr17/rev/1ba852d4cdee

2) Within the same hour, Thunderbird release was also kicked off.

Thunderbird release was signed off for the same changeset.

Probably then what happened in code:

- Thunderbird release tagging decided to use GECKO170_2012111907_RELBRANCH as the relbranch
- It decided that the head of the relbranch was correct wrt versions, so didn't bump the versions
- because it didn't bump the versions, it then tagged the signed-off changeset (1ba852d4cdee) as the release revision rather than the head of the relbranch.

Comment 1

[[e-mail] (:bhearsum)]

In general I think it's good to use a changeset from the relbranch when we're using a relbranch. Otherwise, we're putting tags on one branch with the commits they're pointing to on another. I wonder if the "fix" for this is to add a check to release sanity about that instead of changing the tagging scripts?

I'm not sure how to fix this in the tagging scripts without causing us to version bump for ALL rebuilds. We do the bumping after we create or switch to the relbranch (https://github.com/mozilla/build-tools/blob/master/scripts/release/tag-release.py#L65). If we do the bumping beforehand, we'll always do bumping on a build > 2 for cases where the versions on default don't match what we want to ship with (currently this is only the case for ESRs).

Making this a P3 because it only affects ESRs.

Comment 2

[Mark Banner (:standard8)]

Attachment: Possible concept patch

How about something like this - I'm not sure if it is fully right, but here's what I'm thinking:

- After attempting to bump the version files, we update the revision to tag regardless of if we bumped the versions or not.

Effects:

* In a build 1 situation, with no existing relbranches, the version file will be bumped and the revision updated just as it is now.

* In a situation with existing relbranch that has already have versions bumped, then the versions won't be bumped, but the revision to tag will be updated to the head of the relbranch (the repo previously having been updated to the head earlier in the function).

This probably needs some more thinking about to make sure all the cases are covered, but I think it might work.

Comment 3

[[e-mail] (:bhearsum)]

Comment on attachment 684624 [details] [diff] [review]
Possible concept patch

Review of attachment 684624 [details] [diff] [review]:
-----------------------------------------------------------------

Apologies for the long delay here, I somehow missed this patch.

(In reply to Mark Banner (:standard8) from comment #2)
> Created attachment 684624 [details] [diff] [review]
> Possible concept patch
> 
> How about something like this - I'm not sure if it is fully right, but
> here's what I'm thinking:
> 
> - After attempting to bump the version files, we update the revision to tag
> regardless of if we bumped the versions or not.
> 
> Effects:
> 
> * In a build 1 situation, with no existing relbranches, the version file
> will be bumped and the revision updated just as it is now.
> 
> * In a situation with existing relbranch that has already have versions
> bumped, then the versions won't be bumped, but the revision to tag will be
> updated to the head of the relbranch (the repo previously having been
> updated to the head earlier in the function).

Hm. This basically means that we're ignoring the 'revision' argument we get if the relbranch exists, doesn't it? I guess that would be the same thing we used to do in CVS.

Assuming we can make sure this works, I'm OK with the plan. It's better than having broken releases, that's for sure :(.

Comment 4

[Wayne Mery (:wsmwk)]

This has a stalled patch

Comment 5

[Rail Aliiev [:rail]]

We stopped tagging/bumping implicitly in release promotion.