How to working directory when using monorepo

In our monorepo, we want to set the working directory as a subfolder of the checkout out code. Doing a pwd after running the checkout command shows the working directory to be a random path generated at runtime. eg for us it outputs:

/opt/********/workdir/20220730102306-802f4a95

given this, since working_directory parameter takes a static param, how do we tell circleci that the working directory should be a specific subfolder of ‘current’ directory

The working directory is either random or hardcoded at run time by defining it as a parameter.

The workaround is that you can provide a path to the checkout command relative to the working_directory or past posts indicated it can be absolute to the file system.

So
working_directory: ~/git-store/sub-directory

  checkout:
      path: ~/git-store

Should place (or maintain) a copy of the monorepo in ~/git-store while the working_directory should be set to ~/git-store/sub-directory

when using a ‘self-hosted runner’ with the checkout command with the hardcoded path param, will circleci ‘clean’ the path before checking out files to that path?

or is it possible that files from previous builds might be leftover? in that case do we need to do a rm -rf ~/git-store before calling checkout in your example ?

When using self-hosted runners (that are not docker instances) The file structure remains between jobs unless you write an explicit step to do a tidy-up. The checkout step has been written to support this as it checks the contents of the path it has been given and does a clone or fetch depending on what it finds. It is possible to check this by looking at the script as it is shown in the checkout step in the GUI.

I use self-hosted runners mainly because of the persistence of the file system. It means I gain local caching for the repo, artefacts and docker images without needing to use additional circleci features, while also having full control over the definition of the runner. There are also some cost benefits, but those are secondary to the reduced time it takes to complete a build cycle.