Please report any other irregularities here.
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.
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
(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.
(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
(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.
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.
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.
Ben, Rail, what would you recommend wrt the question in comment #6? Thanks
(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.
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.
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.
Filed bug 1152854 with my sparse UX ideas to remove the use of milestones in the UI on elmo.
I think we FIXED the intents here by now.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.