Can't cancel or repeat task on C-C treeherder

RESOLVED FIXED in Thunderbird 64.0

Status

Product:
Thunderbird
Component:
Build Config
Type:
defect
Status:
RESOLVED FIXED
Opened:
10 months ago
Updated:
4 months ago

People

(Reporter: jorgk, Unassigned)

Tracking

Version:
unspecified
Target:
Thunderbird 64.0

Thunderbird Tracking Flags

(thunderbird_esr6066+ fixed)

Details

Attachments

(2 attachments)

Bug 1492219 - Update .taskcluster.yml with (some) changes from M-C
46 bytes, text/x-phabricator-request
tomprince
: review+
Details | Review
66c355e529f5 rebased to ESR60
4.42 KB, patch
rail
: feedback+
Details | Diff | Splinter Review 
Trying to repeat a task I get:
Taskcluster: While firing hook: InterpreterError at template.payload.env[2]["ACTION_TASK"]: unknown context value task --- * method: triggerHook * errorCode: InputError * statusCode: 400 * time: 2018-09-18T17:21:24.776Z 

Tom said on IRC:
19:51:00 - tomprince: The error message you quote suggests the `.taskcluster.yml` may have diverged from firefox's in a way that impacts actions.
19:55:24 - tomprince: https://bugzilla.mozilla.org/show_bug.cgi?id=1491371 is also related (but not the issue you are seeing on c-c).

Apparently also part of the problem was bug 1470622 which has been resolved.
Flags: needinfo?(rob)
> Apparently also part of the problem was bug 1470622 which has been resolved.

That bug is what caused the issue to become visible, as it caused treeherder to start using in-tree actions for things like retrigger/cancel, instead of ad-hoc implementations.
I talked to Tom about this briefly last night. I think I know what needs to be changed, but I don't have all of the necessary access to test. We'll be working on it today.
Flags: needinfo?(rob)
The idea is to make actions work again from treeherder
Comment on attachment 9010653 [details]
Bug 1492219 - Update .taskcluster.yml with (some) changes from M-C

Tom Prince [:tomprince] has approved the revision.
Attachment #9010653 - Flags: review+
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/66c355e529f5
Update .taskcluster.yml with (some) changes from M-C r=tomprince
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 64.0
Should that go to the comm-beta tree as well?
Flags: needinfo?(rob)
Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/bdd596274fb1
Follow-up: Fixed indentation/white-space issues. rs=white-space-only DONTBUILD
Hmm, tried to retrigger a job on TreeHerder and got:

Taskcluster: No such hook --- * method: triggerHook * errorCode: ResourceNotFound * statusCode: 404 * time: 2018-09-21T08:39:35.255Z
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
It will probably need to go to comm-beta and comm-esr60 once it works on central. Tom mentioned something about needing to make changes in the ci-admin repository I believe.
Flags: needinfo?(rob) → needinfo?(mozilla)
ci-admin needs to be run by someone with permissions after changes to `.taskcluster.yml`. You can ask in #taskcluster. There is Bug 1491371 about figuring out how to pin versions on release branches without changing that file (and thus requiring a ci-admin run to allow actions to work).
Flags: needinfo?(mozilla)
Cancel seems to work again on the C-C tree, I've just cancelled a bunch of stuff.
Repeat works, too.
Status: REOPENED → RESOLVED
Closed: 10 months ago → 10 months ago
Resolution: --- → FIXED
It worked for a while, now I get this on try:
Taskcluster: No such hook --- * method: triggerHook * errorCode: ResourceNotFound * statusCode: 404 * time: 2018-10-18T18:51:01.662Z
Flags: needinfo?(rob)
I just reran a couple jobs on try without any problems. Can you try again and if it's still not working I'll look at it more.
Flags: needinfo?(rob)
Modifying .taskcluster.yml breaks actions. See bug 1491371.

Is there any chance to uplift https://hg.mozilla.org/comm-central/rev/66c355e529f5 to ESR60 as well? Ship-it v2 relies on this if you need to cancel a release.

Yes, I can. The question is whether we can use the release we built
https://treeherder.mozilla.org/#/jobs?repo=comm-esr60&revision=ec1b1f6de68c18251ec3699b88dd4575ffdda628
or whether we need to build a new one.

In the former case I'd push that with DONTBUILD (which doesn't appear to be popular amongst releng people).

Flags: needinfo?(jorgk)

Part of that hunk here, BTW
https://hg.mozilla.org/comm-central/rev/66c355e529f5#l1.12

+      # Hardcode cron push info for now, so that we can transition to using real values without breaking callers of Chain of Trust
+      _pushId: {$if: 'tasks_for == "cron"', then: '-1', else: {$eval: 'push.pushlog_id'}}
+      # action tasks can fail because of no pushdate or push comment information in context, so include them in
+      # hardcodes (even though they don't use these variables)
+      _pushDate: {$if: 'tasks_for == "cron" || tasks_for == "action"', then: '0', else: {$eval: 'push.pushdate'}}
+      _pushComment: {$if: 'tasks_for == "cron" || tasks_for == "action"', then: '', else: {$eval: 'push.comment'}}

would have been removed when uplifting
https://hg.mozilla.org/releases/comm-beta/rev/80b01cce09596e7e664cb5e356bf8a8b061fe45f#l1.67

-      # action tasks can fail because of no pushdate or push comment information in context, so include them in
-      # hardcodes (even though they don't use these variables)
-      _pushDate: {$if: 'tasks_for == "cron" || tasks_for == "action"', then: '0', else: {$eval: 'push.pushdate'}}
-      _pushComment: {$if: 'tasks_for == "cron" || tasks_for == "action"', then: '', else: {$eval: 'push.comment'}}

but since it wasn't there, I didn't remove it ;-) - I guess we want the _pushId?

Like so?

Attachment #9051122 - Flags: feedback?(rail)

(In reply to Jorg K (GMT+1) from comment #17)

Yes, I can. The question is whether we can use the release we built
https://treeherder.mozilla.org/#/jobs?repo=comm-
esr60&revision=ec1b1f6de68c18251ec3699b88dd4575ffdda628
or whether we need to build a new one.

The patch won't affect the existing task group, so we can't cancel the existing release this way. I'll figure out a way to make the release disappear from the dashboard. :)

In the former case I'd push that with DONTBUILD (which doesn't appear to be
popular amongst releng people).

I'd land it without DONTBUILD in case we decide to use the new revision for the next release build.

Attachment #9051122 - Flags: feedback?(rail) → feedback+

Thank you!

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