Closed Bug 1109074 Opened 9 years ago Closed 9 years ago

Add a check on the tagging a release as shipped or not

Categories

(Release Engineering :: Applications: Shipit, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Sylvestre, Unassigned)

References

Details

Attachments

(1 file, 2 obsolete files)

In bug 1097661, we introduced the capability to tag if a release has been shipped or not.
However, it is easy to have both 34.0build1 and build2 tagged with status=postrelease
We should check and block that.
Can you elaborate on this? Do you mean mercurial tags? The patch in bug 1097661 doesn't look like it tags something...
Sorry, I have been lazy in the description :)
By tag, I didn't mean an actual hg tag. It is just a way to update status to postrelease (to be used in the partial generation).
Comment on attachment 8534385 [details] [diff] [review]
0001-Bug-1109074-Only-one-product-version-can-have-the-po.patch

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

::: kickoff/views/forms.py
@@ +152,5 @@
> +
> +            # Check if there is an other product-version already shipped
> +            similar = getReleases(status="postrelease", productFilter=release.product,
> +                                  versionFilter=release.version)
> +            if similar <> []:

This is probably better written as a simple "if similar", which will be True if similar is a non-empty list.

::: kickoff/views/releases.py
@@ +66,5 @@
> +
> +            if 'postrelease' in errors:
> +                # We are dealing with the ajax errors
> +                return Response(status=400, response=errors['postrelease'])
> +

This doesn't seem like a very stable assumption to make. We could easily lose error messages if we're modifying postrelease and something else at the same time. Is there a reason why the AJAX request can't cope with multiple error messages? Perhaps we should be returning JSON with key/value pairs instead of just values below?
Attachment #8534385 - Flags: review?(bhearsum) → feedback+
(In reply to Ben Hearsum [:bhearsum] from comment #4)


> ::: kickoff/views/releases.py
> @@ +66,5 @@
> > +
> > +            if 'postrelease' in errors:
> > +                # We are dealing with the ajax errors
> > +                return Response(status=400, response=errors['postrelease'])
> > +
> 
> This doesn't seem like a very stable assumption to make. We could easily
> lose error messages if we're modifying postrelease and something else at the
> same time. Is there a reason why the AJAX request can't cope with multiple
> error messages? Perhaps we should be returning JSON with key/value pairs
> instead of just values below?

Well, that is a good question! :)
Seems like errors.values() does not really work. It make the 
/releases/Firefox-28.0b2-build1
with :
INFO:werkzeug:127.0.0.1 - - [11/Dec/2014 16:56:17] "POST /releases/Firefox-28.0b2-build1 HTTP/1.1" 500 -
Traceback (most recent call last):
  File "/usr/share/pyshared/flask/app.py", line 1836, in __call__
    return self.wsgi_app(environ, start_response)
  File "/usr/share/pyshared/paste/auth/basic.py", line 95, in __call__
    return self.application(environ, start_response)
  File "/usr/share/pyshared/flask/app.py", line 1821, in wsgi_app
    return response(environ, start_response)
  File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1206, in __call__
    app_iter, status, headers = self.get_wsgi_response(environ)
  File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1194, in get_wsgi_response
    headers = self.get_wsgi_headers(environ)
  File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1145, in get_wsgi_headers
    for x in self.response)
  File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1145, in <genexpr>
    for x in self.response)
  File "/usr/lib/python2.7/dist-packages/werkzeug/_compat.py", line 106, in to_bytes
    raise TypeError('Expected bytes')
TypeError: Expected bytes


So, since I don't want to break the other behavior, that is why I did a special case...
Attachment #8535027 - Flags: review?(bhearsum)
(In reply to Sylvestre Ledru [:sylvestre] from comment #5)
> Created attachment 8535027 [details] [diff] [review]
> 0001-Bug-1109074-Only-one-product-version-can-have-the-po.patch
> 
> (In reply to Ben Hearsum [:bhearsum] from comment #4)
> 
> 
> > ::: kickoff/views/releases.py
> > @@ +66,5 @@
> > > +
> > > +            if 'postrelease' in errors:
> > > +                # We are dealing with the ajax errors
> > > +                return Response(status=400, response=errors['postrelease'])
> > > +
> > 
> > This doesn't seem like a very stable assumption to make. We could easily
> > lose error messages if we're modifying postrelease and something else at the
> > same time. Is there a reason why the AJAX request can't cope with multiple
> > error messages? Perhaps we should be returning JSON with key/value pairs
> > instead of just values below?
> 
> Well, that is a good question! :)
> Seems like errors.values() does not really work. It make the 
> /releases/Firefox-28.0b2-build1
> with :
> INFO:werkzeug:127.0.0.1 - - [11/Dec/2014 16:56:17] "POST
> /releases/Firefox-28.0b2-build1 HTTP/1.1" 500 -
> Traceback (most recent call last):
>   File "/usr/share/pyshared/flask/app.py", line 1836, in __call__
>     return self.wsgi_app(environ, start_response)
>   File "/usr/share/pyshared/paste/auth/basic.py", line 95, in __call__
>     return self.application(environ, start_response)
>   File "/usr/share/pyshared/flask/app.py", line 1821, in wsgi_app
>     return response(environ, start_response)
>   File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1206,
> in __call__
>     app_iter, status, headers = self.get_wsgi_response(environ)
>   File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1194,
> in get_wsgi_response
>     headers = self.get_wsgi_headers(environ)
>   File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1145,
> in get_wsgi_headers
>     for x in self.response)
>   File "/usr/lib/python2.7/dist-packages/werkzeug/wrappers.py", line 1145,
> in <genexpr>
>     for x in self.response)
>   File "/usr/lib/python2.7/dist-packages/werkzeug/_compat.py", line 106, in
> to_bytes
>     raise TypeError('Expected bytes')
> TypeError: Expected bytes
> 
> 
> So, since I don't want to break the other behavior, that is why I did a
> special case...

If it doesn't work, now is a good time to fix it :). AFAICT, the only place we hit that endpoint is https://github.com/mozilla/build-tools/blob/master/buildfarm/release/release-runner.py#L82, and all it does is print, so you should be safe to change the response in whatever way you need to there.
Right, here it is :)
Attachment #8534385 - Attachment is obsolete: true
Attachment #8535027 - Attachment is obsolete: true
Attachment #8535027 - Flags: review?(bhearsum)
Attachment #8535090 - Flags: review?(bhearsum)
Attachment #8535090 - Flags: review?(bhearsum) → review+
Component: Release Automation → Ship It
fixed and deployed
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: Applications: ShipIt (backend) → Applications: ShipIt
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: