Closed Bug 1048290 Opened 10 years ago Closed 10 years ago

Automatic filling of the branch field in ship-it

Categories

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

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: Sylvestre, Assigned: Sylvestre)

References

Details

(Whiteboard: [shipit])

Attachments

(2 files)

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)
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.
(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: nobody → sledru
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+
in production
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: