Update git remote URL before cloning on deploys

[fullyint]

Problem: The git module doesn't always pick up on changes to the repo variable, sometimes failing to clone the new repo. Potential examples: one, two, three.

Steps to reproduce

• run deploy.yml with default repo: git@github.com:roots/bedrock.git
• change repo: git@github.com:roots/roots-example-project.com.git (and uncomment subtree: site)
• run deploy.yml again

Exepected outcome: New clone should be made on second run of deploy.yml after changing repo.

Actual outcome: "Clone project files" task reports ok instead of changed and no new clone is made. The old roots/bedrock.git clone remains and is copied to new release directory, despite repo variable indicating roots/roots-example-project.com.git.

Why it happens: The git module doesn't check for updates by comparing the clone with the repo specified. Instead, it compares the clone with the clone's remote by running git ls-remote origin -h HEAD in the clone's path.

(Edit: The rest of this comment is now out-dated.)

Fix: This PR puts clones in paths that are unique to each repo. Previously, the "Steps" above only yielded a clone directly in shared/source. If this PR were merged, the "Steps" above would yield clones in
shared/source/bedrock.git-aedf427
shared/source/roots-example-project.com.git-55f77f1

Now, when the git module runs git ls-remote while checking for updates, it only ever runs it in a clone directory corresponding to the repo the user specified.

The hash at the end of the filename is created from the full path of the repo. Adding the hash ensures that a new clone will still be made when the basename stays the same but there is a change in git user and/or git host.

[louim]

Note that it's actually gonna be fixed in ansible core module soon ansible/ansible-modules-core#721. I would prefer a task that just run git remote set-url origin {{the_specified_url}} before running the git module, but your solution work as well until it is patched in core.

[fullyint]

Thanks @louim! That's good news. I should have researched this more thoroughly.

I like your idea better, especially because it will avoid altering the structure of the shared/source directory for existing Trellis projects. So, I switched the PR to just be a task to run git remote set-url. We can remove the task when Ansible core is updated.

[louim]

As it is right now, the task will always be marked as changed, and will alway update the remote url, even if it hasn't changed. Something like this would prevent that and would only update the url if the project has already been created and the remote changed:

- name: Check if project folder exists
  stat: path={{ project_source_path }}
  register: git_project_path

- name: Get remote URL
  cmd: git config --get remote.origin.url 
  args:
    chdir: {{ project_source_path }}
  register: remote_origin_url
  when: git_project_path.stat.exists

- name: Update git remote URL
  cmd: git remote set-url origin {{ project_git_repo }}
  args:
    chdir: {{ project_source_path }}
  when: remote_origin_url is defined and remote_origin_url != project_git_repo

I just wrote that on top of my head, so there may be syntax errors that slipped by.

[fullyint]

@louim you always help me improve. Thank you. Consider this task:

- name: Update git remote URL
  shell: "cd {{ project_source_path }} && git config --get remote.origin.url && git remote set-url origin {{ project_git_repo }} || :"
  register: original_remote
  changed_when: original_remote.stdout not in ['', project_git_repo]

On the surface, the task appears idempotent. It reports "changed" only if the new url differs from the old url and if the clone already exists. However, technically the set-url command always runs if the clone exists. If that is unacceptable, I could add an if-then into the shell command to conditionally run the set-url command. Or more likely, I could just let go of my drive to handle this in a single task and do three tasks like those you suggested.

[louim]

@fullyint I think it's just a matter of preference at this point. I usually prefer smaller, easier to understand tasks and offloading the logic as much as possible to Ansible. I think using the builtin function of Ansible over shell (when possible) improve long term maintainability and readability.

[swalkinshaw]

I agree with @louim in this case about small tasks. It's also better when failures happen since you'll know it's a problem with a single command instead of a part of a complex command.

[fullyint]

Thanks for the additional feedback @louim and @swalkinshaw. I've revised the PR. Now the git remote url is only updated if necessary.

[swalkinshaw]

Is the defined check needed? Since the above task only runs when the git project exists, how would it never have stdout?

[fullyint]

If the git project doesn't yet exist, "Get current git remote URL" skips, and its registered value is

"remote_origin_url": {
  "changed": false,
  "skipped": true
}

In this scenario, remote_origin_url.stdout is not defined, so without the defined check,
when: remote_origin_url.stdout != project_git_repo
would cause the task to fail.

My conditional states "if there is a remote url available to compare," but maybe a more intuitive alternative would be "if a git clone/project exists," like this:
when: git_project.stat.exists and remote_origin_url.stdout != project_git_repo.

[swalkinshaw]

@fullyint yes that's more clear 👍

[fullyint]

Thanks @swalkinshaw. I adjusted the when: statement for the "Update git remote URL" task.

[swalkinshaw]

squash and we're good

[fullyint]

squashed

[swalkinshaw]

Thanks 👍