Initially I implemented this feature to solve the problem about how to
make a path absolute to protect against a task changing the working
directory. This is a problem because generic-worker creates a random
task user for each task, so the absolute path can't be known at runtime.
Before my patches, we "solved" this by hardcoding a set of envs in the
`run-task` script, and then calling `os.path.abspath` on them. This
worked for the most part, except for Windows tasks that don't run
through a shell. In that case, the paths would remain relative, which
tbh, mostly just works.
Still, I thought it would be best if we could guarantee that paths are
absolute, and also would be best to avoid hardcoding specific envs in
`run-task`. To that end, I introduced a `{task_workdir}` substitution
where any env containing this string would be interpolated with the
task user's home directory.
In hindsight, this was a bad idea. My patch got backed out 4-5 times due
to subtle errors it introduced to miscellaneous tasks. Then after
finally getting it landed, it started causing havoc in Thunderbird.
What's more is I still had to avoid using `{task_workdir}` in the
Windows without a shell case and rely on relative paths. So the feature
didn't even accomplish what I originally intended it to.
Instead, I recently landed a patch to generic-worker, so *it* will
populate the $TASK_WORKDIR env. this will be available across all
platforms, whether the task is using a shell or not.
So for all these reasons, I'm reverting the `{task_workdir}` change and
returning to using `os.path.abspath`. It's not perfect, but it's good
enough for now. Once we have a modern generic-worker in all our pools,
we can start relying on $TASK_WORKDIR and get the best of both worlds.
Differential Revision: https://phabricator.services.mozilla.com/D238217
d2d17b6243