848860 - Use a URL to kick releases

Status: RESOLVED WONTFIX

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

Description

[Armen [:armenzg]]

Currently we have to specify the repo, the revision and sometimes the branch.

Would it make sense to use a URL?

https://hg.mozilla.org/releases/mozilla-esr17/rev/587a4acda7d3
this returns these values:
repo: releases/mozilla-esr17
revision: 587a4acda7d3
branch: GECKO1703_2013021512_RELBRANCH

This would also make the life of rel-drivers easier as they have always been emailing to use a URL.

Comment 1

[[e-mail] (:bhearsum)]

Not sure how well this will interact with relbranches...we take the tip of those, so a revision on one that isn't the tip ends up being ignored.

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #1)
> Not sure how well this will interact with relbranches...we take the tip of
> those, so a revision on one that isn't the tip ends up being ignored.

If we're OK with ignoring the revision given when it's on a relbranch, this seems like it would work.

Implementation-wise, it's easiest to do this in JS. We'd have to do a lot of refactoring of the forms to do it on the server.

Comment 3

[Massimo Gervasini [:massimo]]

Attachment: added release url in submit_release

Hi Ben,

This is a simple prototype.

I have added the release url in the form and  moved the Branch/Mozilla Revision under Advanced Options, javascript takes care of keeping everything in sync when one of these field changes. 

Do you think that we should have a stronger validation mechanism in place like checking if the release url exists?

Comment 4

[[e-mail] (:bhearsum)]

Comment on attachment 750445 [details] [diff] [review]
added release url in submit_release

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

I gave this some local testing and found a few small things:
* When a relbranch is used instead of a revision, the URL should be populated with that instead of staying the same. For example, if I enter "foo" for the revision and "bar" for the branch, I end up with "https://hg.mozilla.org/bar/rev/foo" as the populated URL. If I then delete the revision and change enter a relbranch of "baz", the new URL should be "https://hg.mozilla.org/bar/rev/baz". Currently, the URL stays the same.
* Relbranch should be disabled as soon as an URL is entered. Currently, this doesn't happen unless you focus and then lose focus on "revision".
* Comm revision should be supported too. We don't have to worry about a branch for that (not yet, at least), but the URL should be able to be copy/pasted to fill in the revision.

Some verbiage change:
* "Release url" should be "Mozilla Revision URL".
* Let's use this for the URL help text: An URL to the revision you want to build this release from. Use this if you don't want to fill in branch/revision individually. At this time, the server portion is ignored and assumed to be "hg.mozilla.org".

::: kickoff/static/kickoff.js
@@ +88,5 @@
> +       .blur( function(){updateBranchRevision(product) });
> +      $( "#" + product + "\-branch" )
> +       .blur( function() {updateBranchRevision(product) });
> +      // preserve the state after a refresh
> +      if ( getLastBlurredItem(product) == 'url' ) {

Is this supposed to make sure that the correct fields are disabled after refreshing the page? If so, I think it's better to do this by looking at the contents of fields rather than assuming the local storage is correct. There could be cases where what's in the form and what's in local storage don't match...and it's better to make decisions based on user visible things in that case.

@@ +107,5 @@
> +    localStorage.getItem('last_blurred_item_' + release_type)
> +}
> +
> +function updateReleaseUrl(release_type) {
> +  var regex = /https:\/\/hg.mozilla.org\/(.*)\/rev\/(.*)/;

If it's relatively easy to, can we avoid hardcoding "https" and "hg.mozilla.org"? Using something like http://blog.stevenlevithan.com/archives/parseuri might be useful here.

::: kickoff/templates/submit_release.html
@@ +32,5 @@
>     </div>
>     {% endfor %}
>  </div>
> +<script>
> +  $(document).ready(function(){ submitRelease(); });

submitRelease needs a better name :). This line sounds like it's going to submit the form as soon as the page loads. How about

Comment 5

[Sylvestre Ledru [:Sylvestre]]

I don't think we are going to need this feature.

Our goal is to have an automatic retrieval of the last green changeset in TBPL/treeherder.
Moreover, with all the automatic features in ship-it, it is pretty much useless.