Automatic filling of the branch field in ship-it

RESOLVED FIXED

Status

Release Engineering
Release Automation
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: sylvestre, Assigned: sylvestre)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [shipit])

Attachments

(2 attachments)

(Assignee)

Description

3 years ago
Created attachment 8467075 [details] [diff] [review]
0001-Autofill-the-branch-field.patch

In ship-it, the branch field has to be provided by the user. 

AFAIK, in all cases, this can be guess by the version. So, let's delegate this to the machine.

= Firefox / Fennec =

32.0b2 =>
releases/mozilla-beta

31.0esr or 31.1.0esr =>
release/mozilla-esr31

31.0 or 31.0.1 =>
release/mozilla-release

= Thundebird =

31.0b1 =>
releases/comm-beta

31.0 or 31.1.0 =>
releases/comm-esr31

The attached patch proposes an implementation of this.

The field remains editable in case of bad guess.
Attachment #8467075 - Flags: review?(bhearsum)
(Assignee)

Updated

3 years ago
Blocks: 1049689
Comment on attachment 8467075 [details] [diff] [review]
0001-Autofill-the-branch-field.patch

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

I also have little doubt that this will become out of date, and will cause issues. Eg, after months of getting it right, the wrong thing will be populated, and then the wrong release will start. We've already seen this sort of thing with partials. I'm going to try to get over my paranoia about this, but I still wanted to mention it.

Implementation wise, I've really tried to avoid hardcoding things like this, even in suggestions. We used to have this sort of thing all over the place in many different systems, and it was a huge pain. I really, really want to avoid repeating that. Already with this, we need to bump it every time we create a new ESR branch. A few possible alternatives:
1) Look for similar version numbers and use that branch. We have a a version class that may be able to help with this if it can be done in Python: https://github.com/mozilla/balrog/blob/master/auslib/util/versions.py#L4
2) Flip the problem on its head and ask for the branch as the primary thing, it should be easier to guess the next version number based on that.
3) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=848860 instead. This might need #2 as well.
(Assignee)

Comment 2

3 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #1)
> 
> Implementation wise, I've really tried to avoid hardcoding things like this,
> even in suggestions. We used to have this sort of thing all over the place
> in many different systems, and it was a huge pain. I really, really want to
> avoid repeating that.
Sure, make sense.

However, I need at some point, to have a "database" to do the matching version <=> branch. 



> Already with this, we need to bump it every time we create a new ESR branch.
That is incorrect in my current implementation.

If you, as release manager, enter 42.1.0esr, the regexp will construct that the branch is 
releases/mozilla-esr42




> 1) Look for similar version numbers and use that branch. We have a a version
> class that may be able to help with this if it can be done in Python:
> https://github.com/mozilla/balrog/blob/master/auslib/util/versions.py#L4
Not sure how this can help me? That is just a basic regexp (just like mine).


> 2) Flip the problem on its head and ask for the branch as the primary thing,
> it should be easier to guess the next version number based on that.
I like the idea. However, after trying to implement it, it seems that the next version inference from the branch
is going to be uglier than my patch.



> 3) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=848860 instead. This
> might need #2 as well.
Using the link here would not help to guess the version
and one of our ultimate goal is to have an 'automatic' retrieval of the last green patchset.
Comment on attachment 8467075 [details] [diff] [review]
0001-Autofill-the-branch-field.patch

(In reply to Sylvestre Ledru [:sylvestre] from comment #2)
> (In reply to Ben Hearsum [:bhearsum] from comment #1)
> > 
> > Implementation wise, I've really tried to avoid hardcoding things like this,
> > even in suggestions. We used to have this sort of thing all over the place
> > in many different systems, and it was a huge pain. I really, really want to
> > avoid repeating that.
> Sure, make sense.
> 
> However, I need at some point, to have a "database" to do the matching
> version <=> branch. 

I think there are cleverer ways to do this, but given that we don't need to bump this for every ESR, I'm not going to block on it.

> > Already with this, we need to bump it every time we create a new ESR branch.
> That is incorrect in my current implementation.
> 
> If you, as release manager, enter 42.1.0esr, the regexp will construct that
> the branch is 
> releases/mozilla-esr42

Oh, that's great. I misread that, sorry!

> > 3) Fix https://bugzilla.mozilla.org/show_bug.cgi?id=848860 instead. This
> > might need #2 as well.
> Using the link here would not help to guess the version
> and one of our ultimate goal is to have an 'automatic' retrieval of the last
> green patchset.

Can you comment in this bug? It sounds like we should probably wontfix it.
Attachment #8467075 - Flags: review?(bhearsum) → review+
(Assignee)

Updated

3 years ago
Assignee: nobody → sledru
(Assignee)

Comment 4

3 years ago
Comment on attachment 8467075 [details] [diff] [review]
0001-Autofill-the-branch-field.patch

http://git.mozilla.org/?p=build/release-kickoff.git;a=commitdiff;h=10eff1aadc6885c8d2ec6c3bba797bd7cba4dd30;hp=1f24d5c5528f4c39295047ee27a32d3ed338a642
Attachment #8467075 - Flags: checked-in+
(Assignee)

Comment 5

3 years ago
Created attachment 8471450 [details] [diff] [review]
0001-Refactor-the-code-to-have-a-dedicated-function-to-do.patch

Ben, thinking about your Twitter message of yesterday, I did a minor refactoring (move the branch guessing into a dedicated function). That is more clean.
Attachment #8471450 - Flags: review?(bhearsum)
Attachment #8471450 - Flags: review?(bhearsum) → review+
(Assignee)

Comment 6

3 years ago
Merged too:
http://git.mozilla.org/?p=build/release-kickoff.git;a=commitdiff;h=e78dfaa7e6f7a564097b4786fa2a205047d7796a;hp=10eff1aadc6885c8d2ec6c3bba797bd7cba4dd30
in production
(Assignee)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.