1338933 - cron.yml scopes are missing the jar signing scope for fennec nightlies

Status: RESOLVED FIXED

(Firefox Build System :: Task Configuration, task)

Description

[Aki Sasaki (not active)]

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&filter-searchStr=nightly&selectedJob=76571108

https://tools.taskcluster.net/task-inspector/#N-cSl1F8Shux4rgxCP4QHg/0

[task 2017-02-12T11:03:09.598153Z] In other words you are missing scopes from one of the options:
[task 2017-02-12T11:03:09.598179Z]  * Option 0:
[task 2017-02-12T11:03:09.598209Z]     - "project:releng:signing:format:jar"

Comment 1

[Aki Sasaki (not active)]

I was going to edit the hook-id:project-releng/cron-task-mozilla-central role and retrigger, but the description says

"""
DO NOT EDIT

Scopes for the cron task for https://hg.mozilla.org/mozilla-central

This role is configured automatically by taskcluster-admin.
"""

Currently thinking it might be best to leave this bug for the tc team.

Comment 2

[Aki Sasaki (not active)]

http://gecko.readthedocs.io/en/latest/taskcluster/taskcluster/cron.html?highlight=cron#scopes pointed me at https://tools.taskcluster.net/auth/roles/#repo:hg.mozilla.org%252fmozilla-central:cron:nightly-* which pointed me at https://tools.taskcluster.net/auth/roles/#project:releng:nightly:level-3:* which I was able to add the jar scope to.

Retriggered the android nightly decision task on m-c; that's https://tools.taskcluster.net/task-inspector/#C5_wx697TsydQOxUWH9vbg/0 and just finished successfully.

Comment 3

[Bill Gianopoulos [:WG9s]]

Does this mean I should soon be able to update soon, or do I have to wait for tomorrow's nightly?

Comment 4

[Aki Sasaki (not active)]

You should be able to update once this graph finishes: https://tools.taskcluster.net/task-group-inspector/#/C5_wx697TsydQOxUWH9vbg?_k=p15zz3

That means the build has to finish, as well as the en-US signing, beetmover, and balrog tasks.  The single locale tasks aren't strictly blocking the en-US/multi steps.

I think since we've triggered the graph without errors, this bug is resolved.

Comment 5

[Aki Sasaki (not active)]

Looks like retriggering the decision task means we have chain of trust errors, since the new decision task isn't in the old decision task's task-graph.json (and we pick up the old decision task because retriggering gives the new decision the old decision task's taskGroupId).

I'm not sure how to manually trigger decision tasks through cron.yml, if we're not scheduled to have a decision task at this time.  Dustin?

At worst, we should have a working graph tonight.

Comment 6

[Aki Sasaki (not active)]

(In reply to Aki Sasaki [:aki] from comment #5)
> Looks like retriggering the decision task means we have chain of trust
> errors, since the new decision task isn't in the old decision task's
> task-graph.json (and we pick up the old decision task because retriggering
> gives the new decision the old decision task's taskGroupId).

It's quite possible I shouldn't care if a decision task has a different taskGroupId, since the decision task should point at the tree.  I filed https://github.com/mozilla-releng/scriptworker/issues/77.

> I'm not sure how to manually trigger decision tasks through cron.yml,
> if we're not scheduled to have a decision task at this time.

I retriggered the original decision task via tctalker, which should get around both the scopes and chain of trust issues.  No guarantees about further errors.

Comment 7

[Aki Sasaki (not active)]

Green! https://tools.taskcluster.net/task-group-inspector/#/N-cSl1F8Shux4rgxCP4QHg?_k=1vlo8s

The only thing left here that's not tracked elsewhere is figuring out how to manually trigger a cron task outside of the normal cron times.

Comment 8

[Dustin J. Mitchell [:dustin] (he/him)]

Callek has that story, and as I understand it has updated the docs to correspond.  It involves triggering some hooks manually.

Comment 9

[Bill Gianopoulos [:WG9s]]

Thank you so much for getting this fixed over the weekend!

Comment 10

[Aki Sasaki (not active)]

Np, we need these to stay green for our own migration work, so it wasn't purely selfless :)

Comment 11

[Bill Gianopoulos [:WG9s]]

But I should have brought this up on Friday when more people were around. But a one day thing I usually just ignore.

Comment 12

[Aki Sasaki (not active)]

https://hg.mozilla.org/build/puppet/rev/7155e263c999a1b2daeb0382831e7ac2ffa98fb4
bug 1338933 - bump signing,beetmover,balrog to scriptworker 2.2.0. r=callek