pre_workflow_hooks scope only works on the default workspace

[jamengual]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story

Pre workflow hooks happen before any atlantis.yaml file is parsed and they are generally used to generate atlantis.yaml files dynamically which work in that case since the generated atlantis.yaml file is parsed on the default workspace, but if you generate an atlantis.yaml file that uses a different workspace any run command that tries to generate other files on the fly will work but save the files within the default workspace dir instead of the one that will be used in the generated atlantis.yaml file.

atlantis/server/events/pre_workflow_hooks_command_runner.go

Line 50 in 485c4b5

unlockFn, err := w.WorkingDirLocker.TryLock(baseRepo.FullName, pull.Num, DefaultWorkspace, DefaultRepoRelDir)

a server side repo config like this :

pre_workflow_hooks:
        - run: generate_file_for_workspace.sh
        - run: generate_atlantis.yaml

will save all generated files on the repo dir structure inside the atlantis dir like so:

.atlantis/repos/jamengual/atlantmos/1/default\

and the DefaultWorkspace = `default.

Describe the solution you'd like

it will be ideal if the pre_workflow_hooks can allow for the selection of the $WORKSPACE dir instead of assume the default workspace will be used

for example:

pre_workflow_hooks:
        - run: WORKSPACE=`select_workspace.sh`
        - run: generate_file_for_workspace.sh
        - run: WORKSPACE="default" generate_atlantis.yaml

or any other way that makes it easier to define and use.

Describe the drawbacks of your solution

This could potentially require changes to how the atlantis.yaml file could be parsed when generated dynamically or at the very least updated documentation explaining how this happens so the user is aware that the default workspace must be used for the parsing of the atlantis.yaml file.

[giuli007]

I am a bit familiar with this use-case as in the past I fixed some issue related to dynamically generating the atlantis.yaml and using it for different workspaces #1620

Something to highlight is that the use-case for using multiple workspaces is the way we are able to plan and apply multiple projects from the same PR at the same time (via parallel_plan and parallel_apply).
In our case this is the only actual reason to use separate workspaces, which we might be able to stop using if/when #260 get solved.

I remember reading the atlantis code for the first time and being surprised to find out the same code is first cloned to create the default workspace and then cloned again multiple times to create the directories for other workspaces if the projects affected by the PR use any.

potential alternative idea: what if the mechanism for instantiating workspaces was changed to copy all the contents of the default workspace (including potentially generated files) instead of re-cloning the repo multiple times for each workspace?
This would have the advantage of reducing the number of git clones that are fired from PRs that affect multiple workspaces and at the same time continue to require the pre_workflow_hooks steps to be run only once.

[jamengual]

@giuli007 yes we have discussed it with Luke and that is definitely an option and it will decrease the github connections as you said.

if you are willing to give it a try ( since you have experience with that part of the code) we could see this merged soon.