investigate alternate solutions for the taskcluster directory

[escapewindow]

Things work the smoothest by nuking and linking the xpi-template taskcluster/ directory into the xpi source dir. There are potentially other options as mentioned in this thread.

I'm avoiding doing so because:

• using --root implies the source is in the xpi-template directory, which breaks
• we could also run in the xpi-template directory (with or without --root), and specify a known location for the xpi source.
  • I believe this will reuse the level from the xpi-template repo instead of the source repo. I'm intentionally keeping xpi-template level 3 and the source repos level 1, to reflect the amount of trust given to each repo. I'd rather not treat the source repos as level 3, or treat the xpi-template repo as level 1, since we want to restrict what changes go into the template repo.

Opening this to track investigating other solutions, or revisit the above reasoning.

[tomprince]

* using `--root` implies the source is in the xpi-template directory, which breaks

I haven't looked at all the test failures, but the one I looked it, it appears that various bits of the docker support code assumes that docker images are in the current directory, under taskcluster/docker. This did not affect comm-central, since it was re-using the m-c images, so that was correct. This is definitely something we can address, by passing down the correct directory to taskgraph.util.docker in various places.

* we could also run in the xpi-template directory (with or without `--root`), and specify a known location for the xpi source.

This is how ci-config works with ci-admin (ci-config is checked out in config/).

  * I believe this will reuse the level from the xpi-template repo instead of the source repo

The level should come entirely from the arguments to taskgraph decision, which comes from .taskgraph.yml.