Git checkout: UnboundLocalError: local variable 'remote_head' referenced before assignment

[hsanjuan]

ISSUE TYPE

• Bug Report

COMPONENT NAME

git

ANSIBLE VERSION

ansible 2.2.0.0
  config file = 
  configured module search path = Default w/o overrides

CONFIGURATION

pipeline = True + related ControlPath etc

OS / ENVIRONMENT

Linux

SUMMARY

Git checkout fails randomly. Seems like a race condition.

STEPS TO REPRODUCE

Have a step:

- name: checkout
  become: yes
  git:
    repo: https://github.com/hsanjuan/gallomatic.git
    dest: /opt/gallomatic
    force: yes
    version: HEAD

EXPECTED RESULTS

OK

ACTUAL RESULTS

Randomly get (about 50% of the time):

An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
  File "/tmp/ansible_T5rJsX/ansible_module_git.py", line 1040, in <module>
    main()
  File "/tmp/ansible_T5rJsX/ansible_module_git.py", line 994, in main
    result.update(changed=True, after=remote_head, msg='Local modifications exist')
UnboundLocalError: local variable 'remote_head' referenced before assignment

fatal: [myhost]: FAILED! => {
    "changed": false, 
    "failed": true, 
    "invocation": {
        "module_name": "git"
    }, 
    "module_stderr": "Traceback (most recent call last):\n  File \"/tmp/ansible_T5rJsX/ansible_module_git.py\", line 1040, in <module>\n    main()\n  File \"/tmp/ansible_T5rJsX/ansible_module_git.py\", line 994, in main\n    result.update(changed=True, after=remote_head, msg='Local modifications exist')\nUnboundLocalError: local variable 'remote_head' referenced before assignment\n", 
    "module_stdout": "", 
    "msg": "MODULE FAILURE"
}

[ansibot]

@ansible ping, this issue is waiting for your response.
click here for bot help

[pankajrlal]

I am also facing this

[fubarhouse]

+1, everything has suddenly stopped working...
Seems to be when forced is true/yes.

[zero-code-hero]

Also having this issue.

Code:

    - name: Clone/Update Repo
      git: repo=git@[removed].git dest="{{ approot }}" force=yes accept_hostkey=true

Error:

fatal: [<server>]: FAILED! => {"changed": false, "failed": true, "module_stderr": "Shared connection to [<server> closed.\r\n", "module_stdout": "Traceback (most recent call last):\r\n File \"/tmp/ansible_4cXbqC/ansible_module_git.py\", line 1040, in \r\n main()\r\n File \"/tmp/ansible_4cXbqC/ansible_module_git.py\", line 994, in main\r\n result.update(changed=True, after=remote_head, msg='Local modifications exist')\r\nUnboundLocalError: local variable 'remote_head' referenced before assignment\r\n", "msg": "MODULE FAILURE"}

This has a 100% failure rate.

[noirmist]

Also having this issue

[fubarhouse]

This issue also affects 2.2.0 and 2.3.0, but does not affect 2.1.2.0.

[rtrvrtg]

Can reproduce this 100% of the time when force=yes is set and the destination directory already exists.

[dbourcet]

Also having this issue.

[solomongifford]

For those that need a quick fix, you can find the git.py in the ansible source and remove the "after=remote_head".

An exception occurred during task execution. The full traceback is:
Traceback (most recent call last):
  File "/tmp/ansible_T5rJsX/ansible_module_git.py", line 1040, in <module>
    main()
  File "/tmp/ansible_T5rJsX/ansible_module_git.py", line 994, in main
    result.update(changed=True, after=remote_head, msg='Local modifications exist')
UnboundLocalError: local variable 'remote_head' referenced before assignment

[fubarhouse]

@solomongifford Thanks for the quick fix! Here's hoping for a patch in-release soon!

[svenfinke]

@solomongifford Thanks for the quick-fix, but I honestly can't find the file... Where should it normally be located?
A patch for this bug would be quite nice, I also hope it will be released soon.

[wasimkham]

@svenfinke The file (for me) is located here I think - /Library/Python/2.7/site-packages/ansible/modules/core/source_control/git.py

@solomongifford There are many instances in the file of "after=remote_head" - you suggest to remove them all?

[BenEinwechter]

@svenfinke and @wasimkham If you run ansible-playbook with three verbose flags, Ansible 2.2 will print out the path of the Ansible module being invoked:

$ ansible-playbook playbook.yml -vvv
=>

TASK [boss_app : checkout git repo] ********************************************
task path: /vagrant/roles/boss_app/tasks/main.yml:28
Using module file /usr/lib/python2.7/dist-packages/ansible/modules/core/source_control/git.py

I edited line 994 in /usr/lib/python2.7/dist-packages/ansible/modules/core/source_control/git.py

# from
result.update(changed=True, after=remote_head, msg='Local modifications exist')

# to
result.update(changed=True, msg='Local modifications exist')

This change gets me around the problem. Not sure if it's correct, but it seems pretty benign, and I think it's what @solomongifford is referring to.

[solomongifford]

@wasimkham: @BenEinwechter is correct - its just the one in the snippet that I pasted in the comment above. Thats the only one that needs to be removed.

@svenfinke: @wasimkham is correct - /path/to/your/python/site-packages/ansible/modules/core/source_control/git.py

[sunshine69]

I got affected by this as well with force=yes

[soichih]

Is there a workaround for this? Maybe like - downgrading the ansible git module?

[BenEinwechter]

@soichih See my comment above for a temporary workaround: #5504 (comment)

[acidjunk]

+1 for a fix

[hsanjuan]

FYI, there is a PR for this: #5505

[hvisage]

+1

In our case: first run (two current django deploys) it fails, then the 2nd run works fine.

[arlaneenalra]

Just got bit by this. Looks like local modifications to the git repo on the server are the triggering factor for us.

[senderista]

+1 just hit this after upgrading to 2.2

[arohr]

+1
same as @hvisage first run fails, second works fine

[ansibot]

@ansible, ping. This issue is still waiting on your response.
click here for bot help

[bmalynovytch]

Fix provided by #5505 works 👍

[joeczucha]

Thanks for the workaround @BenEinwechter, that will keep me moving whilst we wait for an official fix.

FWIW, installed with homebrew on OSX, I had to modify:

/usr/local/Cellar/ansible/2.2.0.0_1/libexec/lib/python2.7/site-packages/ansible/modules/core/source_control/git.py

[fubarhouse]

For me this is a pretty critical fix, me and all of my team literally cannot update and have to always make sure we're using 2.1.x.x until the fix is in release.

Any chance we could get an ETA on this?

[feanorknd]

such a critical bug like this, affecting git replication platforms, may be fixed as soon as possible.
Also affected...

[sldenazis]

Same issue here, applied the @BenEinwechter 's workaround for now.

[sysarcher]

I'm also facing this issue. Worked with ansible 2.1 but failed on 2.2

[andreasschroth]

We're also affected and thus our whole development team has problems when provisioning their VMs. Please provide a fix as soon as possible, thank you! :)

[ghost]

Also seeing this, #5504 (comment) seemed to fix it.

[oucil]

+1 on Ansible 2.3

[ansibot]

This repository has been locked. All new issues and pull requests should be filed in https://github.com/ansible/ansible

Please read through the repomerge page in the dev guide. The guide contains links to tools which automatically move your issue or pull request to the ansible/ansible repo.

[iJebus]

An alternative workaround that I have found is simply to retry the task, and it succeeds on the second pass.

e.g.

- name: force pull git on repo with changes
  git:
    repo: git@bitbucket.org:your-user/your-repo.git
    dest: "{{ commit_dir }}"
    version: "{{ commit }}"
    force: true
  register: git_deploy
  until: git_deploy|succeeded

[likid0]

Also seeing this, #5504 (comment) seemed to fix it.

[ghost]

There are many features I can't use because of this ugly bug.. I hope this will be fixed in the next version.

[abadger]

This should be fixed by: ansible/ansible#19057

If someone would care to test this against a checkout of either devel or the stable-2.2 branch to confirm it has been taken care of that would be great! Otherwise, I'll close this as fixed in a few days.

needs_info

[jornjambers]

Possible workaround when "force: true" is required:

- name: cleanup clone dir cassandra
  become: yes
  file: 
    path: /tmp/php-driver/cassandra
    state: absent

 name: Cloning php-cassandra repo
  become: yes
  git:
    repo: https://github.com/datastax/php-driver.git
    dest: /tmp/php-driver/cassandra
    version: "v{{ php_pecl_cassandra_version }}"
    track_submodules: yes
    #force: yes