1274716 - mozilla-taskcluster should use, and grant, the repo's role to decision tasks

Status: RESOLVED FIXED

(Taskcluster :: Services, defect)

Description

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

A decision task should run with the role assume:repo:hg.mozilla.org/whatever:branch:default 

I made a real hash of this, though: currently .taskcluster.yml has "assume:repo:hg.mozilla.org/try:*" in it, which is definitely not cool.  https://github.com/taskcluster/mozilla-taskcluster/pull/69 fixes that up by adding the scopes configured for the branch to the task's scopes, and adding "assume:repo:hg.mozilla.org/try:*" to those scopes so that the hard-coded instance of that scope doesn't cause issues.

The better solution is for mozilla-taskcluster to calculate the appropriate role based on the repository name, and then substitute that in as `{{repositoryRole}}` into `.taskcluster.yml`, and use that role when calling `scheduler.createTaskGraph()`.

Comment 1

[Greg Arndt [:garndt]]

With the changes we have made since May, does this still apply?

Comment 2

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

Yes, it would simplify all this stuff:

https://github.com/taskcluster/mozilla-taskcluster/blob/master/src/config/default.yml#L99

Comment 3

[Pete Moore [:pmoore][:pete]]

If we plan to deprecate mozilla-taskcluster, maybe we need this only in https://github.com/taskcluster/taskcluster-mercurial?

Comment 4

[Greg Arndt [:garndt]]

I suppose that's a matter of deciding if taskcluster-mercurial will deprecate mozilla-taskcluster before this is 100% necessary.  Last update was 4 months ago so it's not being actively worked on right now it seems.  Not sure how far along it is to be deployed into prod.

Also, taskcluster-mercurial will not handle cancels or retriggers, so it won't be a complete replacement, and mozilla-taskcluster will still need to do something with scopes for those actions.

Comment 5

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

Greg's workign on this..

Comment 6

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

We discovered that this is a bit more difficult: m-t does some operations (retriggering) without reference to the full repository name, just the "treeherder project" which serves as a key into the properties.

Removing the try scope (the hash I made) should be easy quickly.

This doesn't block any of the migration -- it's just a minor improvement to how mozilla-taskcluster is configured.

Comment 7

[Greg Arndt [:garndt]]

I believe with all the scope work that's been done and using the productions.json file, this is resolved.