Closed Bug 869568 Opened 7 years ago Closed 6 years ago

adjust ship it version suggestion logic for new style esr versioning

Categories

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

x86_64
Linux
defect
Not set

Tracking

(firefox24+ fixed)

RESOLVED FIXED
Tracking Status
firefox24 + fixed

People

(Reporter: bhearsum, Assigned: bhearsum)

References

Details

(Whiteboard: [shipit])

Attachments

(2 files, 1 obsolete file)

Starting with ESR24 we may be moving to a new style of versioning that allows for easy distinguishing between planned and unplanned releases. Under this plan, we'd have version numbers like:
24.x.y

Where x is incremented for a planned version, and y is incremented for an unplanned one. Currently, ship it will only suggest a version with y bumped. We'll want it to suggest a version with X bumped (and y reset to 0) too. A couple examples:
24.4.0 -> 24.4.1, 24.5.0
24.8.1 -> 24.8.2, 24.9.0

Holding off on doing this until we know for sure that we're moving in this direction.
Blocks: 870540
Assigning to Ben for now, tracking for 24, re-assign to another relenger as desired.
Assignee: nobody → bhearsum
Need to import this into ship it if this looks OK.
Attachment #760406 - Flags: review?(rail)
Comment on attachment 760406 [details] [diff] [review]
support both styles

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

::: lib/python/build/versions.py
@@ +107,2 @@
>      if esr:
> +        first, second, _ = version.split('.')

A nit. Can you use version.split('.', 2) instead to make sure that the code doesn't fail for versions with 3 and more dots. A test for this case is welcome. :)
Attachment #760406 - Flags: review?(rail) → review+
Comment on attachment 760406 [details] [diff] [review]
support both styles

Landed, with the split limitation.
Attachment #760406 - Flags: checked-in+
Looked fine in ship it dev, pushed to stage and prod.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
tl;dr: this new code doesn't handle versions with only a single dot, like 24.0. Was it intended we should use 24.0.0 ?

For 24.0 ESR we didn't want any partials, but ship-it required something in that form field. We decided to put in a fake release of '24.0build0' and set 
   releaseConfig['partialUpdates']      = {}
in the release config template.

This caused 500 errors for these urls:
  https://ship-it.mozilla.org/release.html?name=Firefox-24.0esr-build1
  https://ship-it.mozilla.org/submit_release.html
This was still OK:
  https://ship-it.mozilla.org/releases/Firefox-24.0esr-build1

The exception behind the 500s was:
2013-09-10 17:05:27,566 - kickoff.log_exception#1306: Exception on /release.html [GET]
Traceback (most recent call last):
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/app.py", line 1687, in wsgi_app
    response = self.full_dispatch_request()
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/app.py", line 1360, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/app.py", line 1358, in full_dispatch_request
    rv = self.dispatch_request()
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/app.py", line 1344, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/views.py", line 83, in view
    return self.dispatch_request(*args, **kwargs)
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/flask/views.py", line 150, in dispatch_request
    return meth(*args, **kwargs)
  File "/data/www/ship-it.mozilla.org/release-kickoff/kickoff/views/releases.py", line 132, in get
    form = getReleaseForm(name)()
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/wtforms/form.py", line 178, in __call__
    return type.__call__(cls, *args, **kwargs)
  File "/data/www/ship-it.mozilla.org/release-kickoff/kickoff/views/forms.py", line 291, in __init__
    ReleaseForm.__init__(self, prefix='firefox', product='firefox', *args, **kwargs)
  File "/data/www/ship-it.mozilla.org/release-kickoff/kickoff/views/forms.py", line 170, in __init__
    self.addSuggestions()
  File "/data/www/ship-it.mozilla.org/release-kickoff/kickoff/views/forms.py", line 271, in addSuggestions
    ReleaseForm.addSuggestions(self)
  File "/data/www/ship-it.mozilla.org/release-kickoff/kickoff/views/forms.py", line 228, in addSuggestions
    for v in getPossibleNextVersions(version):
  File "/data/www/ship-it.mozilla.org/release-kickoff/vendor/lib/python/mozilla/build/versions.py", line 55, in getPossibleNextVersions
    first, second, _ = version.split('.', 2)
ValueError: need more than 2 values to unpack
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
More readable version.

======================  test_build_versions.py  ======================
.................................
----------------------------------------------------------------------
Ran 33 tests in 0.003s

OK
*******************************************************************************
Attachment #802728 - Attachment is obsolete: true
Attachment #802728 - Flags: review?(nthomas)
Attachment #802729 - Flags: review?(nthomas)
Attachment #802729 - Flags: review?(nthomas) → review+
Ack, sorry that this caused you trouble. My bad.
Ben, was the intention to use 24.0.0 ? After writing and testing the fix I found some releases on the dev instance of ship-it like that.

Do you want to back this out and change our process, or leave it in ?
Flags: needinfo?(bhearsum)
(In reply to Nick Thomas [:nthomas] from comment #13)
> Ben, was the intention to use 24.0.0 ? After writing and testing the fix I
> found some releases on the dev instance of ship-it like that.

Definitely not my intention.

> Do you want to back this out and change our process, or leave it in ?

Nope, this is exactly what we want!
Flags: needinfo?(bhearsum)
All done then.
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.