git - Deploy software (or files) from git checkouts
Synopsis
- Manage git checkouts of repositories to deploy files or software.
Requirements (on host that executes module)
- git>=1.7.1 (the command line tool)
Options
| parameter | required | default | choices | comments |
|---|---|---|---|---|
| accept_hostkey (added in 1.5)
| no | no |
| if yes, ensure that "-o StrictHostKeyChecking=no" is present as an ssh options. |
| archive (added in 2.4)
| no | Specify archive file path with extension. If specified, creates an archive file of the specified format containing the tree structure for the source tree. Allowed archive formats ["zip", "tar.gz", "tar", "tgz"] | ||
| bare (added in 1.4)
| no | no |
| if yes, repository will be created as a bare repo, otherwise it will be a standard repo with a workspace. |
| clone (added in 1.9)
| no | yes |
| If no, do not clone the repository if it does not exist locally |
| depth | no | Create a shallow clone with a history truncated to the specified number or revisions. The minimum possible value is 1, otherwise ignored. Needs git>=1.9.1 to work correctly. | ||
| dest | yes | The path of where the repository should be checked out. This parameter is required, unless clone is set to no. | ||
| executable (added in 1.4)
| no | Path to git executable to use. If not supplied, the normal mechanism for resolving binary paths will be used. | ||
| force | no | no |
| If yes, any modified files in the working repository will be discarded. Prior to 0.7, this was always 'yes' and could not be disabled. Prior to 1.9, the default was `yes` |
| key_file (added in 1.5)
| no | None | Specify an optional private key file to use for the checkout. | |
| recursive (added in 1.6)
| no | yes |
| if no, repository will be cloned without the --recursive option, skipping sub-modules. |
| reference (added in 1.4)
| no | Reference repository (see "git clone --reference ...") | ||
| refspec (added in 1.9)
| no | Add an additional refspec to be fetched. If version is set to a SHA-1 not reachable from any branch or tag, this option may be necessary to specify the ref containing the SHA-1. Uses the same syntax as the 'git fetch' command. An example value could be "refs/meta/config". | ||
| remote | no | origin | Name of the remote. | |
| repo | yes | git, SSH, or HTTP(S) protocol address of the git repository. aliases: name | ||
| ssh_opts (added in 1.5)
| no | None | Creates a wrapper script and exports the path as GIT_SSH which git then automatically uses to override ssh arguments. An example value could be "-o StrictHostKeyChecking=no" | |
| track_submodules (added in 1.8)
| no | no |
| if yes, submodules will track the latest commit on their master branch (or other branch specified in .gitmodules). If no, submodules will be kept at the revision specified by the main project. This is equivalent to specifying the --remote flag to git submodule update. |
| umask (added in 2.2)
| no | The umask to set before doing any checkouts, or any other repository maintenance. | ||
| update | no | yes |
| If no, do not retrieve new revisions from the origin repositoryOperations like archive will work on the existing (old) repository and might not respond to changes to the options version or remote. |
| verify_commit (added in 2.0)
| no | no |
| if yes, when cloning or checking out a version verify the signature of a GPG signed commit. This requires git version>=2.1.0 to be installed. The commit MUST be signed and the public key MUST be present in the GPG keyring. |
| version | no | HEAD | What version of the repository to check out. This can be the the literal string HEAD, a branch name, a tag name. It can also be a SHA-1 hash, in which case refspec needs to be specified if the given revision is not already available. |
Examples
# Example git checkout from Ansible Playbooks
- git:
repo: 'https://foosball.example.org/path/to/repo.git'
dest: /srv/checkout
version: release-0.22
# Example read-write git checkout from github
- git:
repo: ssh://[email protected]/mylogin/hello.git
dest: /home/mylogin/hello
# Example just ensuring the repo checkout exists
- git:
repo: 'https://foosball.example.org/path/to/repo.git'
dest: /srv/checkout
update: no
# Example just get information about the repository whether or not it has
# already been cloned locally.
- git:
repo: 'https://foosball.example.org/path/to/repo.git'
dest: /srv/checkout
clone: no
update: no
# Example checkout a github repo and use refspec to fetch all pull requests
- git:
repo: https://github.com/ansible/ansible-examples.git
dest: /src/ansible-examples
refspec: '+refs/pull/*:refs/heads/*'
# Example Create git archive from repo
- git:
repo: https://github.com/ansible/ansible-examples.git
dest: /src/ansible-examples
archive: /tmp/ansible-examples.zip
Return Values
Common return values are documented here Return Values, the following are the fields unique to this module:
| name | description | returned | type | sample |
|---|---|---|---|---|
| after | last commit revision of the repository retrieved during the update | success | string | 4c020102a9cd6fe908c9a4a326a38f972f63a903 |
| before | commit revision before the repository was updated, "null" for new repository | success | string | 67c04ebe40a003bda0efb34eacfb93b0cafdf628 |
| remote_url_changed | Contains True or False whether or not the remote URL was changed. | success | boolean | True |
| warnings | List of warnings if requested features were not available due to a too old git version. | error | string | Your git version is too old to fully support the depth argument. Falling back to full checkouts. |
Notes
Note
- If the task seems to be hanging, first verify remote host is in
known_hosts. SSH will prompt user to authorize the first contact with a remote host. To avoid this prompt, one solution is to use the option accept_hostkey. Another solution is to add the remote host public key in/etc/ssh/ssh_known_hostsbefore calling the git module, with the following command: ssh-keyscan -H remote_host.com >> /etc/ssh/ssh_known_hosts.
Status
This module is flagged as preview which means that it is not guaranteed to have a backwards compatible interface.
Maintenance Info
For more information about Red Hat’s this support of this module, please refer to this knowledge base article<https://access.redhat.com/articles/rhel-top-support-policies>
For help in developing on modules, should you be so inclined, please read Community Information & Contributing, Testing Ansible and Developing Modules.
© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.4/git_module.html