1035458 - Investigation of automation between ship-it (aka release-kickoff) and l10n.mozilla.org

Status: RESOLVED FIXED

(Webtools Graveyard :: Elmo, enhancement, P2)

Description

[Sylvestre Ledru [:Sylvestre]]

When creating a new release on ship-it, we are performing the same tasks again and again without really paying attention on what l10n says (yeh, I know, it is bad).

However, all beta that I managed, I have been doing the same exact step without any issue.
Description:
https://wiki.mozilla.org/Release:Release_Automation_on_Mercurial:Starting_a_Release#L10N_Changesets

My proposal would be to update ship-it (or build farm release runner) to make it automatically:
* create a new milestone (we have the data in ship-it)
* ship it
* retrieve the json file for mobile or two columns data for desktop (first column: locale, second: revision)

This would remove the risk of human mistakes (That is a selfish request because I do plenty!) and saves a few minutes for every release for the release managers.

Comment 1

[Axel Hecht [:Pike]]

Caveats:

Releases may need tweaking of removing locales from l10n-changesets that aren't ready to go from beta to release.

Authentication of one webtool to modify data in another webtool.

Not exactly sure if this bug should be in ship-it or elmo

Comment 2

[[e-mail] (:bhearsum)]

(In reply to Axel Hecht [:Pike] from comment #1)
> Caveats:
> 
> Releases may need tweaking of removing locales from l10n-changesets that
> aren't ready to go from beta to release.

It was for precisely this reason that we didn't try have ship it talk to the l10n dashboard from the start.

Comment 3

[Sylvestre Ledru [:Sylvestre]]

(In reply to Ben Hearsum [:bhearsum] from comment #2)
> It was for precisely this reason that we didn't try have ship it talk to the
> l10n dashboard from the start.
* that rarely happens. 
* even if we build it, does not mean that we have to publish it

Suggestions to tackle to this specific issue:
* we could a prefill of the textarea and leave to the release manager the removal
* we could go on the l10n before release build day and disable the locale

Comment 4

[[e-mail] (:bhearsum)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #3)
> (In reply to Ben Hearsum [:bhearsum] from comment #2)
> > It was for precisely this reason that we didn't try have ship it talk to the
> > l10n dashboard from the start.
> * that rarely happens. 
> * even if we build it, does not mean that we have to publish it

Well...it happens with every single RC build, doesn't it? We remove a couple of locales from the list it returns IIRC.

> Suggestions to tackle to this specific issue:
> * we could a prefill of the textarea and leave to the release manager the
> removal

I'm really concerned about how this makes it more likely that the person submitting the release will forget to adjust the locales. It seems to me that having it prefilled will encourage someone not to think about it at all, especially after no changes were needed for the 6 weeks of beta prior to the RC.

Comment 5

[Lukas Blakk [:lsblakk] use ?needinfo]

Actually, I disagree - having it pre-filled in ship-it (never having to go do an *extra* 'ship-it' in l10n dash) wouldn't prevent me from editing the locales in the RC kickoff but it would go a *long* way towards reducing overall time of filling it out and also would be great to have less interaction with l10n dash by relman, for whom there is zero value of interaction with it.

Comment 6

[Axel Hecht [:Pike]]

The discussion here is helpful, and guides me to

What's best practices for such a tool-tool communication? The naive ways would probably violate best-practices in terms of elmo security, so we'd need something that does auth and CSRF-protection right, and maybe more. My problem is that I know enough to be scared, and not enough to provide answers.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Ben, Rail, what would you recommend wrt the question in comment #6? Thanks

Comment 8

[[e-mail] (:bhearsum)]

(In reply to Sylvestre Ledru [:sylvestre] from comment #7)
> Ben, Rail, what would you recommend wrt the question in comment #6? Thanks

We've implemented a client for Balrog that respects CSRF, so that part is probably easy. I've never done non-HTTP auth in code, so I'm not sure what to say there. AppSec might be helpful.

Before we move too far with this I think we should figure out a couple of things:
1) Exactly how will this integration happen. I'd suggest that Ship It (the backend webapp) should not be talking to another webapp while processing its own requests. A possible alternative could be to do it on the frontend (which might make the security parts easier, because a web browser will be making the requests to Elmo). Another could be to have release runner do it after bug 847424 is fixed.
2) Does Elmo's API support everything we need already? What sort of guarantees do we have about stability of those APIs going forward? If Elmo's APIs could change without notice (and potentially break our ability to trigger releases), that's going to be an issue.

Comment 9

[Axel Hecht [:Pike]]

Elmo doesn't have an "API" in a strict sense, and no external dependants like this one.

We would have to establish that, including a process for error handling, etc.

I'm pondering to change a bunch of URLs around including using something better to the current /shipping/, but that may or may not affect this bug. That's also something we'll probably resolve in 2 weeks or so.

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

An additional idea that came up at the Portland work week is to have the l10n dashboard provide a GET API that ship-it can use to pull the latest changesets that l10n deems ready to ship and to have ship-it provide a GET API that publicizes the changesets that were shipped with each release. Using this dual GET model, we can remove the need to authenticate with either system.

Comment 12

[Axel Hecht [:Pike]]

Filed bug 1152854 with my sparse UX ideas to remove the use of milestones in the UI on elmo.

Comment 13

[Axel Hecht [:Pike]]

I think we FIXED the intents here by now.