Managing Git Repositories with Ansible

Ansible is a powerful automation tool that allows you to manage and configure systems, including version control systems like Git. In this tutorial, we will explore the basics of managing Git repositories using Ansible. We’ll cover the essentials of the Ansible inventory file, introduce the concept of playbooks, and provide an example playbook for cloning a Git repository and running a WildFly Bootable JAR application.


Make sure you have Ansible installed on your control machine. You can follow the installation instructions on the Ansible official website.

Ansible Inventory File

The Ansible inventory file is a simple text file that contains a list of hosts that Ansible will manage. It is often located at /etc/ansible/hosts by default. The inventory file can also be specified using the -i option when running Ansible commands. Below is an example inventory file:

server1 ansible_host= ansible_user=myuser
server2 ansible_host= ansible_user=myuser
  • [git_servers] is a group name.
  • server1 and server2 are hostnames or IP addresses.
  • ansible_host specifies the target host’s IP address or hostname.
  • ansible_user specifies the user Ansible should use to connect to the target hosts.

For testing purposes, however, we will be using localhost as entry for your Inventory File. This way, all tasks will run on your machine:

localhost ansible_connection=local

Ansible Playbooks

Ansible playbooks are YAML files that define a set of tasks to be executed on remote hosts. Each playbook consists of one or more plays, and each play contains a list of tasks. A task is a single unit of work, such as installing a package or copying a file.

Example Playbook: Cloning a Git Repository

Let’s create a simple Ansible playbook that clones WildFly Bootable Jar Git repository and run one of the examples in the repository. If you are new to WildFly Bootable Jar the following article discuss it more in detail: Turn your WildFly application in a Bootable JAR Create a file named playbook.yml with the following content:

- name: WildFly JAX-RS Example Deployment
  hosts: localhost
  gather_facts: true

    destination_dir: "{{ lookup('env','HOME') }}/output"
    git_tag: "10.0.0.Final"
    - name: Check if WildFly JAR Maven Plugin directory exists
        path: "{{ destination_dir }}/wildfly-jar-maven-plugin"
      register: plugin_directory_exists

    - name: Clone WildFly JAR Maven Plugin Git Repository
        repo: [email protected]:wildfly-extras/wildfly-jar-maven-plugin.git
        dest: "{{ destination_dir }}/wildfly-jar-maven-plugin"
        version: "{{ git_tag }}"
      when: not plugin_directory_exists.stat.exists

    - name: Move to examples/jaxrs directory
      command: cd "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"
        chdir: "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"

    - name: Run Maven Install and WildFly JAR Plugin
      command: mvn install wildfly-jar:run
        chdir: "{{ destination_dir }}/wildfly-jar-maven-plugin/examples/jaxrs"

The Playbook contains both a configuration section and a Task section. Let’s see them both:

The Playbook Configuration

Firstly, here, the hosts: localhost line indicates that the playbook is intended to run on the local machine (localhost). The inventory file is not explicitly consulted to determine the target hosts in this case, as the target host is implicitly set to the local machine.

Then vars defines variables of the playbook:

  • destination_dir: Variable storing the destination directory for cloning the Git repository. Defaults to the user’s home directory ($HOME/output).
  • git_tag: Variable storing the Git tag or branch name to be checked out. Defaults to “10.0.0.Final”.

The Task Configuration

stat task: Uses the stat module to check if the specified directory ({{ destination_dir }}/wildfly-jar-maven-plugin) exists. The result is registered in the variable plugin_directory_exists.

git task: Clones the WildFly JAR Maven Plugin Git repository into the specified destination directory. It uses the built-in Git module setting the attributes repo, dest and version. The task is conditional (when) and only runs if the directory doesn’t exist (not plugin_directory_exists.stat.exists).

Finally, we execute two command line tasks: at first we move the specified directory using the cd command. The args section ensures the change of the working directory (chdir) to the specified path. Then, we execute the Maven command to install dependencies and run the WildFly JAR plugin. The working directory is set to the specified path.

You can run the playbook as follows:

ansible-playbook -i inventory playbook.yml

Verify that all Tasks are ok:

PLAY [WildFly JAX-RS Example Deployment] *******************************************************

TASK [Gathering Facts] *************************************************************************
ok: [localhost]

TASK [Check if WildFly JAR Maven Plugin directory exists] **************************************
ok: [localhost]

TASK [Clone WildFly JAR Maven Plugin Git Repository] *******************************************
changed: [localhost]

TASK [Move to examples/jaxrs directory] ********************************************************
changed: [localhost]

TASK [Run Maven Install and WildFly JAR Plugin] ************************************************

Finally, reach out the example Bootable Jar application which returns an Hello World message from the “hello” Endpoint:

ansible git tutorial


This tutorial introduced the basics of managing Git repositories with Ansible. We covered the Ansible inventory file, playbook structure, and provided an example playbook for cloning a Git repository. Ansible’s flexibility and simplicity make it a valuable tool for automating Git-related tasks across multiple servers. Explore Ansible’s extensive documentation for more advanced use cases and features.

Source code for this tutorial: