@Koli14 Could you try changing this in roles/deploy/defaults/main.yml, then re-run deploy.yml a couple times and tell us if it works correctly each time?
- project_source_path: "{{ project_root }}/shared/source"
+ project_source_path: "{{ project_root }}/shared/source/{{ project.repo }}"
(Edit: I originally had a regex_replace filter on project.repo, but @swalkinshaw pointed out that it is unnecessary, so I removed it.)
No need to read on, but here’s my guess at what was happening – none of it your fault.
I’m guessing you first ran deploy.yml with the default repo: git@github.com:roots/bedrock.git.
- Now there is a copy of the roots bedrock repo at
project_source_path.
I’m guessing you later ran deploy.yml with repo: git@github.com:koli14/example.com.git.
- The git module ran
git ls-remote originin theproject_source_pathand saw that there were no updates (checking against roots/bedrock cloned earlier), so… - No new clone was made, and…
- The roots/bedrock repo was copied to your release directory.
- Your sync task still put your
distdirectory on the server, in the roots/bedrock empty theme directory. It looked like some empty version of your theme had been cloned/copied, but really it was never cloned.
So, I think the problem was that we didn’t realize the git module wouldn’t pick up on changes to the repo variable. We assumed the module would check the remote repo specified, but I think it just compares the local clone with the latest updates to that local clone’s remote.
This phenomenon may be responsible for other threads reporting the git module not updating: here and here.
The above edit to project_source_path should make it so that the git ls-remote origin always checks the remote repo we specify in the repo variable.