905871 - release sanity fails for x.y.z build 2 on same rev as build 1

Status: RESOLVED FIXED

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

Description

[hwine]

Attachment: log from release runner

For FF desktop 23.0.1 build 2, release sanity failed as shown in attached logs. Workaround was to change the hg revision from the build1 value to the one where build 1 was tagged. That is, in the log below:
 b41d7bb7cae8 was used for build 1
 d5e6d9b5b57b was used for build 2

o  changeset:   144019:d5e6d9b5b57b
|  parent:      144016:b41d7bb7cae8
|  user:        ffxbld
|  date:        Wed Aug 14 09:12:27 2013 -0400
|  summary:     Automated checkin: version bump for firefox 23.0.1 release. DONTBUILD CLOSED TREE a=release
|
| o  changeset:   144018:d6b5b6b8777f
| |  branch:      GECKO2301_2013081409_RELBRANCH
| |  user:        ffxbld
| |  date:        Wed Aug 14 09:12:20 2013 -0400
| |  summary:     Added FIREFOX_23_0_1_RELEASE FIREFOX_23_0_1_BUILD1 tag(s) for changeset a55c55edf302. DONTBUILD CLOSED TREE a=release
| |
| o  changeset:   144017:a55c55edf302
|/   branch:      GECKO2301_2013081409_RELBRANCH
|    tag:         FIREFOX_23_0_1_BUILD1
|    user:        ffxbld
|    date:        Wed Aug 14 09:12:16 2013 -0400
|    summary:     Automated checkin: version bump for firefox 23.0.1 release. DONTBUILD CLOSED TREE a=release
|
o  changeset:   144016:b41d7bb7cae8
|  user:        Jan-Ivar Bruaroey <[e-mail]>
|  date:        Tue Aug 13 16:36:59 2013 -0400
|  summary:     Bug 904598: Disable TURN by default (Set media.peerconnection.turn.disable=true) r=jesup a=lsblakk

Comment 1

[[e-mail] (:bhearsum)]

I'm pretty sure that release runner/sanity has this check to help catch situations where we do a build #2 and screw up the changeset. If it's a valid use case to do a build2 of the same version but NOT do it off the relbranch, we should remove this check. Tagging will always make sure that we end up with the right version.

Comment 2

[hwine]

I forgot to mention this is new behavior. When doing 23.0 build 2, release sanity passed fine with the identical revision. It only failed with 23.0.1 build 2. 

Either something changed between Aug 1 & Aug 15, or the behavior is different for x.y.z releases.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Hal Wine [:hwine] from comment #2)
> I forgot to mention this is new behavior. When doing 23.0 build 2, release
> sanity passed fine with the identical revision. It only failed with 23.0.1
> build 2. 
> 
> Either something changed between Aug 1 & Aug 15, or the behavior is
> different for x.y.z releases.

Yeah, the special part here is that for x.y.z, the version you want doesn't match the version that's already on default. We always have the current x.y version on default but we never have an x.y.z one.

(In reply to Ben Hearsum [:bhearsum] from comment #1)
> I'm pretty sure that release runner/sanity has this check to help catch
> situations where we do a build #2 and screw up the changeset. If it's a
> valid use case to do a build2 of the same version but NOT do it off the
> relbranch, we should remove this check. Tagging will always make sure that
> we end up with the right version.

I was right about this. The "verify build" check is false in today's world of tagging always ensuring the version is correct.

Comment 4

[[e-mail] (:bhearsum)]

Attachment: remove now-useless check

Comment 5

[Rail Aliiev [:rail]]

Comment on attachment 797929 [details] [diff] [review]
remove now-useless check

With Fire!