1600657 - first l10n bumper on beta should build without "DONTBUILD"

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: L10N, task)

Description

[Mihai Tabara [:mtabara]⌚️GMT]

Starting 72.0 cycle on beta, we're no longer using the l10n bumper from the bm01 but instead the cron hook from https://firefox-ci-tc.services.mozilla.com/hooks/project-releng/cron-task-releases-mozilla-beta%2Fl10n-bumper

RelMan mentioned earlier today in #releaseduty that ideally, the first l10n bump we have after mergeduty, does not have "DONTBUILD" in its commit message since it's the perfect candidate for automation to pick it up as b1.

Given that treescript has this function, I reckon we can play with the in-tree payload from [here](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/transforms/task.py#l1317 to adjust that.

Comment 1

[Mihai Tabara [:mtabara]⌚️GMT]

Example:

• when we did it manually via bm01 - https://hg.mozilla.org/releases/mozilla-beta/rev/e1479d4d94da4261b90f09b0246f8de6d49756bb
• earlier today via cron job automation - https://hg.mozilla.org/releases/mozilla-beta/rev/d16a6310a393bc0714765da380377d64a7a52292

Comment 2

[Jordan Lund (:jlund)]

@mihai - where are we at with this? I guess if we want the hook to be updated to do this properly, we need to resolve this ticket by Monday, Jan 6th?

Comment 3

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Jordan Lund (:jlund) from comment #2)

@mihai - where are we at with this? I guess if we want the hook to be updated to do this properly, we need to resolve this ticket by Monday, Jan 6th?

Yes, that's correct. I'll dig into it this week. Should be relatively straightforward patch in treescript.
Keeping the NI open until then.

Comment 4

[Mihai Tabara [:mtabara]⌚️GMT]

Note to self: we fixed https://github.com/mozilla-releng/scriptworker-scripts/pull/126 for some unrelated-l10n-bumper bug earlier today and forgot to add some tests. Whenever we push the PR for this, might be nice to add the following too:

diff --git a/treescript/tests/test_l10n.py b/treescript/tests/test_l10n.py
index b073977..dc98782 100644
--- a/treescript/tests/test_l10n.py
+++ b/treescript/tests/test_l10n.py
@@ -269,4 +269,4 @@ async def test_l10n_bump_closed_tree(mocker):
     # we're supposed to
     mocker.patch.object(l10n, "get_l10n_bump_info", return_value=[{}])
 
-    await l10n.l10n_bump({}, {}, "")
+    assert await l10n.l10n_bump({}, {}, "") == 0

Comment 5

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #4)

Note to self: we fixed https://github.com/mozilla-releng/scriptworker-scripts/pull/126 for some unrelated-l10n-bumper bug earlier today and forgot to add some tests. Whenever we push the PR for this, might be nice to add the following too:

diff --git a/treescript/tests/test_l10n.py b/treescript/tests/test_l10n.py
index b073977..dc98782 100644
--- a/treescript/tests/test_l10n.py
+++ b/treescript/tests/test_l10n.py
@@ -269,4 +269,4 @@ async def test_l10n_bump_closed_tree(mocker):
     # we're supposed to
     mocker.patch.object(l10n, "get_l10n_bump_info", return_value=[{}])
 
-    await l10n.l10n_bump({}, {}, "")
+    assert await l10n.l10n_bump({}, {}, "") == 0

Nvm - https://github.com/mozilla-releng/scriptworker-scripts/pull/127 took care of it and it's merged.

Comment 6

[Mihai Tabara [:mtabara]⌚️GMT]

@Callek -

I'm trying to understand whether this is something that can actually be solved easily or not.
I see we have the cron job running every hour (at :45 minutes) to run the l10n bumper and it naturally runs with donbuild = true wthin its payload (e.g. https://firefox-ci-tc.services.mozilla.com/tasks/QFdz1bEsQdaJ6njZsQMLIA)

Once a month, after mergeduty, we're using the associated hook to trigger the same job from here. RelMan said it'd be ideally if this l10n bump was in fact triggered without a DONTBUILD so that we benefit of a first good beta commit after mergeduty.

I wonder, is there an easy way to maybe tweak the hook task somehow in order to change the payload in the decision task to donbuild = false somehow?

Comment 7

[Justin Wood (:Callek)]

I think we could make l10n-bump happen as part of merge-automation, but that may mean that we still have a DONTBUILD variant on monday, unless we want to temporarily flip the kind.yml pref in tree to be "false" at merge time, and as soon as first bump lands we have sheriffs land an =true flip back

Comment 8

[Aki Sasaki (not active)]

I believe we can pass in context when triggering a hook. We should investigate whether doing so could allow us to flip the DONTBUILD boolean.

Comment 9

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Aki Sasaki [:aki] (he/him) (UTC-7) from comment #8)

I believe we can pass in context when triggering a hook. We should investigate whether doing so could allow us to flip the DONTBUILD boolean.

Hm, just noticed the Context before triggering the hook. Likely that's doable too. But since 72 was the last cycle with manual labor, I suppose we're okay moving this bug in treescript. Since both l10n bumper and mergeduty jobs are living there, I'm assuming we can simply trigger l10n bumper directly from there in the mergeduty so that we can tweak the payload directly there.

CC'ing Simon here as he's going to be next releaseduty and he has also done amazing work in adding mergeduty within automation.

Comment 10

[Aki Sasaki (not active)]

(In reply to Mihai Tabara [:mtabara]⌚️GMT from comment #9)

Hm, just noticed the Context before triggering the hook. Likely that's doable too. But since 72 was the last cycle with manual labor, I suppose we're okay moving this bug in treescript. Since both l10n bumper and mergeduty jobs are living there, I'm assuming we can simply trigger l10n bumper directly from there in the mergeduty so that we can tweak the payload directly there.

Ah, yeah, if l10n bumper runs during merge day, then it can happen at the same time, with the right behavior.

Comment 11

[Aki Sasaki (not active)]

Attachment: Bug 1600657 - l10n-bumper should use the latest revisions. r=#releng-reviewers

• disable esr l10n-bumper on 81
• use l10n-repo-url instead of revision-url (l10n-central instead of elmo)

Depends on D87691

Comment 12

[Phabricator Automation]

Comment on attachment 9171115 [details]
Bug 1600657 - l10n-bumper should use the latest revisions. r=#releng-reviewers

Revision D87693 was moved to bug 1659898. Setting attachment 9171115 [details] to obsolete.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/13982be6ff5e
l10n-bumper should use the latest revisions. r=releng-reviewers,bhearsum DONTBUILD

Comment 14

[Aki Sasaki (not active)]

Doh, that should be for bug 1659898.

Comment 15

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/13982be6ff5e

Comment 16

[Julien Cristau [:jcristau]]

This doesn't actually seem fixed?

Comment 17

[Mihai Tabara [:mtabara]⌚️GMT]

(In reply to Julien Cristau [:jcristau] from comment #16)

This doesn't actually seem fixed?

Judging by http://docs.mozilla-releng.net/en/latest/procedures/release-duty/merge-duty/merge_duty.html#run-the-l10n-bumper and https://github.com/mozilla-releng/scriptworker-scripts/pull/275 I think this is set to run during central -> beta migration which is next Monday (given beta is closed anyway during this week and l10n bumper de-activated as per https://hg.mozilla.org/releases/mozilla-beta/rev/0179c3bbcad3b837e91047f4047625b9bf22c6ed )

Comment 18

[Julien Cristau [:jcristau]]

Ah thanks I didn't know about that PR.