Closed Bug 500473 Opened 11 years ago Closed 10 years ago

Mercurial release automation should be able to do final release tagging

Categories

(Release Engineering :: General, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

(Whiteboard: [automation])

Attachments

(1 file, 1 obsolete file)

When we do a final release, as we're about to for 3.5, we need to tag the latest _RELEASE changeset with a final tag as well. Eg, FIREFOX_3_5rc3_RELEASE and FIREFOX_3_5_RELEASE will point to the same changeset soon. We can do this with a bit of hackery currently but because we have to tag en-US + all locales we really need to able to do this in a better way.
Whiteboard: [automation]
Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.
Component: Release Engineering: Future → Release Engineering
Priority: -- → P3
Assignee: nobody → bhearsum
This should be made easier when tagging is moved to an external script, in bug 508896.
Depends on: 508896
This didn't turn out as clean as I wanted, but it does the job. We don't use a plain two octet version for anything except final releases at this time (RCs use version=4.0rc1, appVersion=4.0), so I believe this is safe.

When we come to final tagging of 4.0, I expect us to be using the following in the config:
sourceRepoRevision = (changeset of final RC)
relbranchOverride = (relbranch of final RC)
baseTag = FIREFOX_4_0
version = 4.0
appVersion = 4.0
skip_build = 1

...and then kick off the automation as normal, which will then run tag, source, and xulrunner_source.

I also toyed around with having a flag passed that controlled final tagging behaviour, but I didn't go with that for a couple of reasons. We'd have to either:
- Decide in Buildbot that we want to pass it (forces us to reconfig for final tagging) or decide in tagging.sh (which would be messy, and not the right place IMHO)
- Use a separate Builder for it, which seems unnecessarily burdensome, and would require us to fire Source separately or have a final-release specific source builder.
Attachment #493416 - Flags: review?(catlee)
Comment on attachment 493416 [details] [diff] [review]
add final tagging support to tag-release.py

>+# If version is two octects with no trailing specifiers like "rc", we
>+# consider it a "final" release for which we only create a _RELEASE tag.
>+FINAL_RELEASE_REGEX = "^\d+\.\d+$"

Small typo of "octet" there....and I'm not sure that octet is the right term for these?

>+def isFinalRelease(version):
>+    # "not not" is used to avoid returning a match object
>+    return not not re.match(FINAL_RELEASE_REGEX, version)

Would bool(re.match(...)) work?

r+ either way here
Attachment #493416 - Flags: review?(catlee) → review+
Carrying forward r+
Attachment #493416 - Attachment is obsolete: true
Attachment #493757 - Flags: review+
Comment on attachment 493757 [details] [diff] [review]
address catlee's review comments

changeset:   1327:a13ca99a1384
Attachment #493757 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.