Closed Bug 1534204 Opened 5 years ago Closed 5 years ago

Try builds don't work under certain circumstances

Categories

(Thunderbird :: Build Config, enhancement)

Product:
Thunderbird
Component:
Build Config
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jorgk-bmo, Assigned: dustin)

References

Details

Attachments

(1 obsolete file)

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=b893a357341b9c6dd2d4589de68ba3e5f21d572d has in its parameters.yml:

comm_base_repository: https://hg.mozilla.org/comm-central
comm_head_ref: b893a357341b9c6dd2d4589de68ba3e5f21d572d
comm_head_repository: https://hg.mozilla.org/try-comm-central
comm_head_rev: b893a357341b9c6dd2d4589de68ba3e5f21d572d
head_ref: THUNDERBIRD_60_VERBRANCH
head_repository: https://hg.mozilla.org/releases/mozilla-esr60
head_rev: 12fc7a7ee5502c265c7900dbf02915db7d755816
hg_branch: 'THUNDERBIRD_60_VERBRANCH
message: merge 8883195c64fa to THUNDERBIRD_60_VERBRANCH. a=jorgk DONTBUILD

and indeed, that message is from https://hg.mozilla.org/releases/mozilla-esr60/rev/12fc7a7ee5502c265c7900dbf02915db7d755816 on the mozilla-esr60 branch, not the try-comm-central branch.

And indeed, in mozilla-esr60:taskcluster/taskgraph/decision.py:

231     parameters['message'] = get_hg_commit_message(GECKO)

I suspect, then, that the fix is to change GECKO there to os.path.join(GECKO, product_dir)? In Firefox that shouldn't make a difference, but would fix this issue for TB.

See Also: → 1535264
Assignee: nobody → dustin

On current M-C trunk we have:
https://searchfox.org/mozilla-central/rev/f1c7ba91fad60bfea184006f3728dd6ac48c8e56/taskcluster/taskgraph/decision.py#236

    parameters['message'] = try_syntax_from_message(
            get_hg_commit_message(os.path.join(GECKO, product_dir)))

which is the fix, right? That's from here:
https://hg.mozilla.org/mozilla-central/rev/7d289fe21aec#l1.40 (pushed Thu, 07 Feb 2019 09:46:04 +0000)
from bug 1525421.

So to fix try pushes from comm-beta and comm-esr60 that would need uplift. We won't do another beta, but it should go onto m-esr60. I'll request this now.

That said, the comm-central try comment #0
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=504471665b96f7102949684018f647aa9270ccb4
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=f95f9a7f3e7f92d52d785b1ad62386e3269bcea8
are after the fix from bug 1525421, that is Thu, Mar 7, 17:14:42 and later and still didn't work.

What am I missing?

I'm totally confused now. In D23556 you're changing parameters['message'] = get_hg_commit_message(GECKO) to parameters['message'] = get_hg_commit_message(os.path.join(GECKO, product_dir)) but the current code shown in comment #4 is already different. I must be blind.

Attachment #9051063 - Attachment is obsolete: true

Yeah, this would be a patch specifically to m-esr60 (where it does apply), but as you've noted another alternative is to uplift bug 1525421 there instead. So we can do that.

As to why those didn't work, I'm not sure. https://tools.taskcluster.net/groups/Apr0Y8pgSyCgs1GVbWUWNg/tasks/Apr0Y8pgSyCgs1GVbWUWNg has parameters

message: 'try: -b o -p macosx64 -u all'

and some filtering went on:

[task 2019-03-07T16:15:05.361Z] Full task graph contains 2790 tasks and 10099 dependencies
...
[task 2019-03-07T16:15:07.238Z] Filter filter_target_tasks pruned 2780 tasks (10 remain)

those ten tasks are (from target-tasks.json):

[
  "test-macosx64/opt-xpcshell-1",
  "build-macosx64/opt",
  "test-macosx64/opt-xpcshell-2",
  "test-macosx64/opt-xpcshell-4",
  "test-macosx64/opt-mozmill-3",
  "test-macosx64/opt-mozmill-2",
  "test-macosx64/opt-mozmill-1",
  "test-macosx64/opt-xpcshell-3",
  "test-macosx64/opt-mozmill-4",
  "test-macosx64/opt-mochitest-thunderbird"
]

and it seems to find the right metadata:

[task 2019-03-07T16:15:07.248Z] Querying version control for metadata: https://hg.mozilla.org/mozilla-central/json-automationrelevance/c89f024c023fa816d700b151e8e0cbb9a1907cb8
[task 2019-03-07T16:15:07.248Z] attempt 1/10
[task 2019-03-07T16:15:07.248Z] retry: calling get_automationrelevance, attempt #1
[task 2019-03-07T16:15:07.972Z] 2 commits influencing task scheduling:
[task 2019-03-07T16:15:07.972Z]  f84b1b428d42 Bug 1523175 - land NSS a306d84e4c70 UPGRADE_NSS_RELEASE, r=me
[task 2019-03-07T16:15:07.972Z]  c89f024c023f Merge mozilla-inbound to mozilla-central. a=merge
[task 2019-03-07T16:15:07.972Z] Querying version control for metadata: https://hg.mozilla.org/try-comm-central/json-automationrelevance/504471665b96f7102949684018f647aa9270ccb4
[task 2019-03-07T16:15:07.972Z] attempt 1/10
[task 2019-03-07T16:15:07.972Z] retry: calling get_automationrelevance, attempt #1
[task 2019-03-07T16:15:08.267Z] 1 commits influencing task scheduling:
[task 2019-03-07T16:15:08.267Z]  504471665b96 try: -b o -p macosx64 -u all

All of those tasks get optimized away because nothing relevant changed in the push, so https://taskcluster-artifacts.net/Apr0Y8pgSyCgs1GVbWUWNg/0/public/task-graph.json is empty. I think that's normal operation, in the context of the deprecated and not-very-expressive try syntax at least (there's long been a vim/emacs-style philosophical battle over whether or not to optimize tasks specified in try syntax, and it turns out the solution is just to not use try syntax).

OK, uplift of https://hg.mozilla.org/mozilla-central/rev/7d289fe21aec is complete as part of 1534283.

Can you confirm that wraps things up?

Thanks, but not right now since we build TB from our branch THUNDERBIRD_60_VERBRANCH. These changes
b18ece2f0408 Dustin J. Mitchell — Bug 1534283 - use default parameters for mach try fuzzy r=tomprince, a=tomprince, DONTBUILD
aecd2582501a Dustin J. Mitchell — Bug 1534283 - filter out tasks when DONT-BUILD is in the message r=aki,tomprince, a=tomprince
7b8bb76f6afe Dustin J. Mitchell — Bug 1525421 - parse out just the try syntax from the commit message r=tomprince
b0130d317c55 Dustin J. Mitchell — Bug 1534283 - add a 'tasks_for' property; r=tomprince, a=tomprince
haven't been merged into it.

I'm sure I'll come back to it when it doesn't work in the future ;-) - Or do you want me to pull those changes into our branch and try it now?

Thanks for all your help.

I'll close this as WFM since it was fixed by other bugs.

Status: NEW → RESOLVED
Closed: 5 years ago
Flags: needinfo?(rob)
Resolution: --- → WORKSFORME

It's really up to you -- I'm happy to help debug any time.

I'll leave it for now. Our TB 60.6 has been built, so next I need a try build, I'll do the merge. Thanks again!

OK, I needed another TB 60 ESR try so I merged bug 1525421 and bug 1534283 into our branch here:
https://hg.mozilla.org/releases/mozilla-esr60/rev/e018f02de5fc

The try run seems to work, see here:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=82bbb02e82d4006e709a46527e28964b69b9dd34

Well, in fact it failed, but that seems unrelated. The reminded me that I also need to uplift
https://hg.mozilla.org/comm-central/rev/f2b728425eaf
Port bug 1534283: Add --tasks-for='${tasks_for}' to .taskcluster.yml to fix DONTBUILD. r=me

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: