Closed Bug 1109074 Opened 10 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: