Is using relative paths in a task's `run.dir` config bad?

Hi there,

I have a Docker image that has all the dependencies and source code baked in. I want to run the unit tests in this container. Based on the documentation for run-config here I can see that for the dir option is says:

Optional. A directory, relative to the initial working directory, to set as the working directory when running the script.

When I hijack the container, I can see the initial working directory is in the format /tmp/build/b504838c or similar. In order to use the source code already baked into the image I have been using relative paths to get to the correct directory. For example ../../../opt/project_name.

My question is, is this bad? Is there any reason I should not do this? Is there a better way to access the filesystem outside the initial working directory that I should use instead?

Any help appreciated, thanks!

I think Concourse is designed with the assumption that all dependencies are pulled in via resources thus meaning they are mounted in that default working directory.

An alternative to your relative path could be using the default working directory then cding to /opt/project_name as the first step of the script. That said, I can’t think of any reason why doing what you’re doing would cause problems.

Is there any reason I should not do this?

The /tmp/build/<random> build directory isn’t documented and isn’t guaranteed. If, for some reason, the directory were to change in a new version of Concourse to something like /tmp/concourse/worker/build/<random>, then your pipeline would break.

You are, of course, permitted to put whatever you like in your build images, at whichever fixed locations - otherwise image_resource wouldn’t be a field at all, and every task would use a blank (scratch) image, expecting the user to define as resources binaries etc. So you’re better off putting a test script in a resource that references the absolute path of /opt/project_name directly.

Thank you for this. Will definitely look at doing something as suggested. Appreciate your help Ari (and you too @crsimmons!)