First of all, thanks for visiting this page 😊 ❤️ ! We are stoked that you may be considering contributing to this project. You should read this guide if you are considering creating a pull request or plan to modify the code for your own purposes.
- Code of Conduct
- Philosophy
- Supported Operating Systems
- Setting Up Development Environment
- Pull Requests
- Code Format
- Code Style
- Commenting
- Updating Meta Files and Documentation
- Testing
- Linting
This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to help@megabyte.space.
When you are working with one of our Ansible projects, try asking yourself, "How can this be improved?" For example, in the case of the Android Studio role, the role installs Android Studio but there may be additional tasks that should be automated. Consider the following examples:
- The software is installed but is asking for a license key. - In this case, we should provide an option for automatically installing the license key using a CLI command.
- The software supports plugins - We should provide an option for specifying the plugins that are automatically installed.
- In the case of Android Studio, many users have to install SDKs before using the software. - We should offer the capability to automatically install user-specified SDKs.
- The software has configuration files with commonly tweaked settings. - We should provide the ability to change these settings via variables stored in
defaults/main.yml
. - The software has the capability to integrate with another piece of software in the main playbook. - This integration should be automated.
Ideally, you should use the software installed by the main playbook. This is really the only way of testing whether or not the software was installed properly and has all the common settings automated. The software installed by the main playbook is all widely-acclaimed, cross-platform software that many people find useful.
All of our roles should run without error on the following operating systems:
- Archlinux (Latest)
- CentOS 7 and 8
- Debian 9 and 10
- Fedora (Latest)
- Ubuntu (16.04, 18.04, 20.04, and Latest)
- Mac OS X (Latest)
- Windows 10 (Latest)
Although we do not have a timeline set up, we are considering adding support for the following operating systems:
- Qubes
- Elementary OS
- Zorin
- OpenSUSE
- Manjaro
- FreeBSD
- Mint
If you have a role that only installs software made for Windows 10 then ensure that the tasks are only run when the system is a Windows system by using when:
in the tasks/main.yml
file. Take the following main.yml
as an example:
---
- name: Include variables based on the operating system
include_vars: 'ansible_os_family.yml'
when: ansible_os_family == 'Windows'
- name: Include tasks based on the operating system
become: true
block:
- include_tasks: 'install-ansible_os_family.yml'
when: ansible_os_family == 'Windows'
We currently support installing applications with both Homebrew casks and mas. Since mas does not allow automated logins to the App Store (and requires that the application was already installed by the account signed into the App Store GUI), we prefer the use of homebrew casks for installing applications.
Before contributing to this project, you will have to make sure you have the tools that are utilized. We have made it incredibly easy to get started - just run bash .start.sh
in the root of the repository. Most of the requirements (listed below) will automatically install (rootlessly) if they are missing from your system when you initialize the project by running bash .start.sh
.
- Task
- Python 3, along with the
python3-netaddr
andpython3-pip
libraries (i.e.sudo apt-get install python3 python3-netaddr python3-pip
) - Docker
- Node.js >=12 which is used for the development environment which includes a pre-commit hook
- VirtualBox which is used for running Molecule tests
Docker and VirtualBox must be installed with root priviledges. If they are missing from your system, running bash .start.sh
will prompt you for your password and automatically install them. Otherwise, you can follow the official directions for installing Docker and directions for installing VirtualBox.
With all the requirements installed, navigate to the root directory and run the following command to set up the development environment which includes installing the Python dependencies and installing the Ansible Galaxy dependencies:
bash .start.sh
This will install all the dependencies and automatically register a pre-commit hook. More specifically, bash .start.sh
will:
- Install Task which provides an easy-to-use interface for performing common tasks while leveraging parallel execution
- Install missing development tools like Node.js and Python
- Install the Node.js development environment dependencies
- Install a pre-commit hook using husky
- Ensure that meta files and documentation are up-to-date
- Install the Python 3 requirements
- Install the Ansible Galaxy requirements
- Re-generate documentation using the latest sources
- Perform other miscellaneous tasks depending on the project type
With the dependencies installed, you can see a list of the available commands by running task --list
. This will log a help menu to the console informing you about the available commands and what they do. After running the command, you will see something that looks like this:
❯ task --list
task_list_output
Using the information provided above by running task --list
, we can see that the task lint:all
command will lint the project with all the available linters. You can see exactly what each command is doing by checking out the Taskfile.yml
file (and following the imports). You can also get a detailed summary of any task reported by task --list
by running task group:task-name --summary
.
All pull requests should be associated with issues. Although not strictly required, the pull requests should be made to the GitLab repository issues board instead of the GitHub mirror repository. This is because we use GitLab as our primary repository and mirror the changes to GitHub for the community.
We try to structure our Ansible task and variable files consistently across all our Ansible projects. This allows us to do things like use RegEx to make ecosystem wide changes. A good way of making sure that your code follows the format we are using is to:
- Clone the main playbook repository (a.k.a. Install Doctor)
- Use Visual Studio Code to search for code examples of how we are performing similar tasks
For example:
- All of our roles use a similar pattern for the
tasks/main.yml
file - The file names and variable names are consistent across our roles
- Contributors automatically format some parts of their code by leveraging our pre-commit hook (which is installed when you run
bash .start.sh
in the root of a project)
To dive a little deeper, take the following block of code that was retrieved from the tasks/main.yml
file in the Android Studio role as an example:
---
- name: Include variables based on the operating system
include_vars: '{{ ansible_os_family }}.yml'
- name: Include tasks based on the operating system
become: true
block:
- include_tasks: 'install-{{ ansible_os_family }}.yml'
If you compare the block of code above to other tasks/main.yml
files in other roles (which you can find in our Ansible Roles group or our main playbook) (a.k.a. Install Doctor), you will see that the files are either identical or nearly identical. There is an exception. Some roles will exclude the first task titled "Include variables based on the operating system" when variables are not required for the role. Our goal is to be consistent but not to the point where we are degrading the functionality of our code or including code that is unnecessary.
In general, it is up to the developer to browse through our projects to get a feel for the code format we use. A good idea is to clone Install Doctor, search for how Ansible modules are used, and then mimic the format. For instance, if you are adding a task that installs a snap package, then you would search for community.general.snap:
in the main playbook to see the format we are using so you can mimic the style.
If you have a role that only installs software made for Windows 10 then ensure that the tasks are only run when the system is a Windows system by using when:
in the tasks/main.yml
file. Take the following main.yml
as an example:
---
- name: Include variables based on the operating system
include_vars: 'ansible_os_family.yml'
when: ansible_os_family == 'Windows'
- name: Include tasks based on the operating system
become: true
block:
- include_tasks: 'install-ansible_os_family.yml'
when: ansible_os_family == 'Windows'
We try to follow the same code style across all our Ansible repositories. If something is done one way somewhere, then it should be done the same way elsewhere. It is up to you to browse through our roles to get a feel for how everything should be styled. You should clone the main playbooks repository (a.k.a. Install Doctor), initialize all the submodules either via bash .start.sh
or git submodule update --init --recursive
, and search through the code base to see how we are styling different task types. Below are some examples:
When there is only one parameter, then you should inline it.
❌ BAD
when:
- install_minikube
✅ GOOD
when: install_minikube
✅ ALSO GOOD
when:
- install_minikube
- install_hyperv_plugin
Anywhere an array/list is used, the list should be ordered alphabetically (if possible).
❌ BAD
autokey_dependencies:
- pkg-config
- make
- git
✅ GOOD
autokey_dependencies:
- git
- make
- pkg-config
In many cases, a role will require that specific software package dependencies are met before running. These dependencies are usually an array of packages that need to be installed.
Say the application being installed is Android Studio. The dependency array should be assigned to a variable titled androidstudio_dependencies
(where "androidstudio" is retrieved from the .galaxy_info.role_name
field in the meta/main.yml
file) and placed in vars/main.yml
.
✅ GOOD example of defining the variable in the vars/main.yml
file
---
androidstudio_dependencies:
- ffmpeg
- coolpackage
- anotherpackage
❌ BAD example of integrating the variable into a task file:
- name: "Ensure {{ app_name }}'s dependencies are installed"
community.general.pacman:
name: '{{ android_studio_deps }}'
state: present
✅ GOOD example of integrating the variable into a task file:
- name: "Ensure {{ app_name }}'s dependencies are installed"
community.general.pacman:
name: '{{ androidstudio_dependencies }}'
state: present
If there are dependencies that are specific to a certain OS, then the dependency variable should be titled {{ .galaxy_info.role_name }}_dependencies_{{ os_family }}
. For Android Studio, a Fedora-specific dependency list should be named androidstudio_dependencies_fedora
. In practice, this would look like:
- name: "Ensure {{ app_name }}'s dependencies are installed (Fedora)"
dnf:
name: '{{ androidstudio_dependencies_fedora }}'
state: present
when: ansible_distribution == 'Fedora'
DRY stands for "Don't Repeat Yourself." Whenever there is code that is duplicated across multiple task files, you should separate it into a different file and then include it like in the following example:
✅ GOOD
- name: Run generic Linux tasks
include_tasks: install-Linux.yml
We strive to make our roles easy to understand. Commenting is a major part of making our roles easier to grasp. Several types of comments are supported in such a way that they are extracted and injected into our documentation. This project uses mod-ansible-autodoc (a pet project of ours and a fork of ansible-autodoc) to scan through specially marked up comments and generate documentation out of them. The module also allows the use of markdown in comments so feel free to bold, italicize, and code_block
as necessary. Although it is perfectly acceptable to use regular comments, in most cases you should use one of the following types of special comments:
It is usually not necessary to add full-fledged comments to anything in the vars/
folder but the defaults/main.yml
file is a different story. The defaults/main.yml
file must be fully commented since it is where we store all the variables that our users can customize. defaults/main.yml
is the only place where comments using the following format should be present.
Each variable in defaults/main.yml
should be added and documented using the following format:
# @var variable_name: default_value
# The description of the variable which should be no longer than 160 characters per line.
# You can separate the description into new lines so you do not pass the 160 character
# limit
variable_name: default_value
There may be cases where an example is helpful. In these cases, use the following format:
# @var variable_name: []
# The description of the variable which should be no longer than 160 characters per line.
# You can separate the description into new lines so you do not pass the 160 character
# limit
variable_name: []
# @example #
# variable_name:
# - name: jimmy
# param: henry
# - name: albert
# @end
Each variable-comment block in defaults/main.yml
should be separated by a line return. You can see an example of a defaults/main.yml
file using this special variable syntax in the Docker role.
Action comments allow us to describe what the role does. Each action comment should include an action group as well as a description of the feature or "action". Most of the action comments should probably be added to the tasks/main.yml
file although there could be cases where an action comment is added in a specific task file (like install-Darwin.yml
, for instance). Action comments allow us to group similar tasks into lists under the action comment's group.
The following is an example of the implementation of action comments. You can find the source here as well as an example of why and how you would include an action comment outside of the tasks/main.yml
file here.
# @action Ensures Docker is installed
# Installs Docker on the target machine.
# @action Ensures Docker is installed
# Ensures Docker is started on boot.
- name: Include tasks based on the operating system
block:
- include_tasks: 'install-{{ ansible_os_family }}.yml'
when: not docker_snap_install
# @action Ensures Docker is installed
# If the target Docker host is a Linux machine and the `docker_snap_install` variable
# is set to true, then Docker will be installed as a snap package.
- name: Install Docker via snap
community.general.snap:
name: docker
when:
- ansible_os_family not in ('Windows', 'Darwin')
- docker_snap_install
# @action Installs Docker Compose
# Installs Docker Compose if the `docker_install_compose` variable is set to true.
- name: Install Docker Compose (based on OS)
block:
- include_tasks: 'compose-{{ ansible_os_family }}.yml'
when: docker_install_compose | bool
The block of code above will generate markdown that would look similar to this:
Ensures Docker is installed
- Installs Docker on the target machine.
- Ensures Docker is started on boot.
- If the target Docker host is a Linux machine and the
docker_snap_install
variable is set to true, then Docker will be installed as a snap package.
Installs Docker Compose
- Installs Docker Compose if the
docker_install_compose
variable is set to true.
- The wording of each action should be in active tense, describing a capability of the role. So instead of calling an action "Generate TLS certificates," we would call it, "Generates TLS certificates."
- The bulk of the action comments should be placed in the
tasks/main.yml
file. However, there may be use cases for putting an action comment in another file. For instance, if the business logic is different for Windows hosts, then we might add action comments to theinstall-Windows.yml
file explaining the different logic. - The goal of action comments are to present our users with some easy to understand bullet points about exactly what the role does and also elaborate on some of the higher-level technical details.
TODO comments are similar to action comments in the sense that through automation similar comments will be grouped together. You should use them anytime you find a bug, think of an improvement, spot something that needs testing, or realize there is a desirable feature missing. Take the following as an example:
# @todo Bug: bug description
# @todo improvement: improvement description
# @todo Bug: another bug description
The above code will output something that looks like this:
Bug
- bug description
- another bug description
improvement
- improvement description
Notice how the title for improvement is not capitalized. It should be capitalized so make sure you pay attention to that detail.
- A TODO comment can be placed anywhere as long as no lines pass the limit of 160 characters.
- Try using similar TODO comment groups. Nothing is set in stone yet but try to use the following categories unless you really believe we need a new category:
- Bug
- Feature
- Improvement
- Test
- Ensure you capitalize the category
Since we have hundreds of Ansible roles to maintain, the majority of the files inside each role are shared across all our Ansible projects. We synchronize these common files across all our repositories with various build tools. When you clone a new repository, the first command you should run is bash .start.sh
. This will install missing software requirements, run the full update sequence, and ensure everything is up-to-date. To synchronize the project at a later point in time, you can run task common:update
which runs most of the logic executed by running bash .start.sh
.
In the root of all of our Ansible repositories, we include a file named package.json
. In the key named "blueprint"
, there are variables that are used in our build tools. Most of the variables stored in "blueprint"
are used for generating documentation. All of our documentation is generated using variables and document partials that we feed into a project called [@appnest/readme](https://github.com/andreasbm/readme)
(which is in charge of generating the final README/CONTRIBUTING guides). When @appnest/readme
is run, it includes the variables stored in "blueprint"
in the context that it uses to inject variables in the documentation. You can view the documentation partials by checking out the ./.common
folder which is a submodule that is shared across all of our Ansible projects.
For every role that is included in our eco-system, we require certain fields to be filled out in the "blueprint"
section of the package.json
file. Lucky for you, most of the fields in the file are auto-generated. The fields that need to be filled out as well as descriptions of what they should contain are listed in the chart below:
Variable Name | Variable Description |
---|---|
description |
Short description of the role, worded in such a way that it makes sense by itself and with 'An Ansible role that ' prepended to it |
group |
This should always be set to 'ansible' for Ansible roles |
name |
This should be the official name for the product that the role installs/configures. It is used in the title of the repository and throughout the documentation to refer to the product. |
overview |
This variable should be a description of what the role installs. You can usually find a good description by Googling, "What is Android Studio," for example if you were populating this variable for the [Android Studio role]({{ repository.group.ansible_roles }}/androidstudio). This text is shown at the top of the README, right below the header section and before the table of contents. Whenever possible, key products/terms should be linked to using markdown. You can see an example of us hyperlinking in this variable by checking out the [Android Studio role]({{ repository.group.ansible_roles }}/androidstudio). The idea is to make it as easy as possible for our users to figure out exactly what the role does. |
repository.github |
The HTTPS URL of the GitHub mirror |
repository.gitlab |
The HTTPS URL of the GitLab repository |
slug |
This should generally be the ending slug of the GitHub mirror. It is used for things like filling in the package.json name. |
subgroup |
This should always be set to 'role' for Ansible roles |
title |
The title of the README.md |
The most important piece of text in each of our Ansible projects is the Ansible Galaxy description located in meta/main.yml
. This text is used in search results on Ansible Galaxy and GitHub. It is also spun to generate multiple variants so it has to be worded in a way that makes sense with our different variants. Take the following as an example:
The meta/main.yml
description example:
- Installs Android Studio and sets up Android SDKs on nearly any OS
Gets spun and used by our automated documentation framework in the following formats:
- Installs Android Studio and sets up Android SDKs on nearly any OS
- An Ansible role that installs Android Studio and sets up Android SDKs on nearly any OS
- This repository is the home of an Ansible role that installs Ansible Studio and sets up Android SDKs on nearly any OS.
It is important that all three variants of the meta/main.yml
description make sense and be proper English. The meta/main.yml
description should succinctly describe what the role does and possibly even describe what the product does if it is not well-known like Android Studio. An example of a description that includes an overview of the product would be something like, "Installs HTTPie (a user-friendly, command-line HTTP client) on nearly any platform," for the HTTPie role or "Installs Packer (an automation tool for building machine images) on nearly any platform" for the Packer role.
We include a logo.png
file in all of our Ansible projects. This image is automatically integrated with GitLab so that a thumbnail appears next to the project. It is also shown in the README to give the user a better idea of what the role does. All roles should include the logo.png
file. When adding a logo.png
file please strictly adhere to the steps below:
- Use Google image search to find a logo that best represents the product. Ensure the image is a
.png
file and that it has a transparent background, if possible. Ideally, the image should be the official logo for software that the Ansible role/project installs. The image should be at least 200x200 pixels. - After downloading the image, ensure you have the sharp-cli installed by running
npm install -g sharp-cli
. - Resize the image to 200x200 pixels by running
sharp -i file_location.png -o logo.png resize 200 200
. - Compress the resized image by dragging and dropping the resized image into the TinyPNG web application.
- Download the compressed image and add it to the root of the Ansible project. Make sure it is named
logo.png
.
Alternatively, you can use our pre-commit hook to automatically take care of steps 2-5 when the logo.png
file is staged with git.
You can test all of the operating systems we support by running the following command in the root of the project:
molecule test
The command molecule test
will spin up VirtualBox VMs for all the OSes we support and run the role(s). Do this before committing code. If you are committing code for only one OS and can not create the fix or feature for the other operating systems then please, at the very minimum, [file an issue](https://gitlab.com/megabyte-labs/ansible-roles/ruby* github: /issues
- gitlab: /-/issues) so someone else can pick it up.
It is important to note that molecule test
tests for idempotence. To pass the idempotence test means that if you run the role twice in a row then Ansible should not report any changes the second time around.
If you would like to shell into a container for debugging, you can do that by running:
task common:shell
For more information about Ansible Molecule, check out the docs.
Some of our roles include applications like Android Studio. You can not fully test Android Studio from a Docker command line. In cases like this, you should use our desktop scenarios to provision a desktop GUI-enabled VM to test things like:
- Making sure the Android Studio shortcut is in the applications menu
- Opening Android Studio to make sure it is behaving as expected
- Seeing if there is anything we can automate (e.g. if there is a "Terms of Usage" you have to click OK at then we should automate that process if possible)
You can specify which scenario you want to test by passing the -s
flag with the name of the scenario you want to run. For instance, if you wanted to test on Ubuntu Desktop, you would run the following command:
molecule test -s ubuntu-desktop
This would run the Molecule test on Ubuntu Desktop.
By default, the molecule test
command will destroy the VM after the test is complete. To run the Ubuntu Desktop test and then open the desktop GUI you would have to:
- Run
molecule converge -s ubuntu-desktop
- Open the VM through the VirtualBox UI (the username and password are both vagrant)
You can obtain a list of all possible scenarios by looking in the molecule/
folder. The molecule/default/
folder is run when you do not pass a scenario. All the other scenarios can be run by manually specifying the scenario (e.g. molecule test -s ubuntu-desktop
will run the test using the scenario in molecule/ubuntu-desktop/
).
The chart below provides a list of the scenarios we include in all of our Ansible projects along with a brief description of what they are included for.
Scenario | Description |
---|---|
default |
Uses VirtualBox to run tests for all platforms in parallel. |
docker |
Uses Docker to run tests for all Linux platforms and versions in parallel. |
docker-snap |
The same as the docker scenario except it excludes platforms that have trouble installing snap packages on Docker. |
archlinux-desktop |
Runs the test on the latest version of Archlinux desktop using VirtualBox. |
centos-desktop |
Runs the test on the latest version of CentOS desktop using VirtualBox. |
debian-desktop |
Runs the test on the latest version of Debian desktop using VirtualBox. |
fedora-desktop |
Runs the test on the latest version of Fedora desktop using VirtualBox. |
macos-desktop |
Runs the test on the latest version of macOS desktop using VirtualBox. |
ubuntu-desktop |
Runs the test on the latest version of Ubuntu desktop using VirtualBox. |
windows-desktop |
Runs the test on the latest version of Windows desktop using VirtualBox. |
ci-docker-archlinux |
Uses Docker to test Archlinux. |
ci-docker-centos |
Uses Docker to test multiple versions of CentOS. |
ci-docker-debian |
Uses Docker to test multiple versions of Debian. |
ci-docker-debian-snap |
Uses Docker to test Debian just like ci-docker-debian except it excludes versions that cannot install snap packages. |
ci-docker-fedora |
Uses Docker to test multiple versions of Fedora. |
ci-docker-ubuntu |
Uses Docker to test multiple versions of Ubuntu. |
You might have noticed that there are no CI tests in the chart above for macOS and Windows. Due to the limitations of Docker, we use other methods to test macOS and Windows automatically with CI. After a project has passed various linting tests on GitLab CI, the following methods are used to test the Ansible play:
- Linux platforms are tested using Molecule and Docker on GitLab CI in parallel. (Link to GitLab CI configuration)
- Windows is tested using GitLab CI without Molecule. (Link to GitLab CI configuration)
- macOS is tested using GitHub Actions after the code is automatically synchronized between GitLab and GitHub. (Link to the macOS GitHub Action configuration)
The process of running linters is mostly automated. Molecule is configured to lint so you will see linting errors when you run molecule test
(note that not all Molecule scenarios include automatic linting). There is also a pre-commit hook that lints your code and performs other validations before allowing a git commit
to go through. If you followed the Setting Up Development Environment section, you should be all set to have your code automatically linted before pushing changes to the repository.
Please note that before creating a pull request, all lint errors should be resolved. If you would like to view all the steps we take to ensure great code then check out .husky/pre-commit
and the other files in the .husky/
folder.
You can manually run Ansible Lint by executing the following command in the project's root:
task lint:ansible
Most errors will be self-explanatory and simple to fix. Other errors might require testing and research. Below are some tips on fixing the trickier errors.
If you get this error, do research to figure out the minimum permissions necessary for the file. After you change the permission, test the role (since changing permissions can easily break things).
This error can be solved by telling Ansible what files the command creates or deletes. When you specify what file a command:
or shell:
creates and/or deletes, Ansible will check for the presence or absence of the file to determine if the system is already in the desired state. If it is in the desired state, then Ansible skips the task. Refer to the documentation for ansible.builtin.command for further details.
Here is an example of code that will remove the error:
- name: Run command if /path/to/database does not exist
command: /usr/bin/make_database.sh db_user db_name
args:
creates: /path/to/database # If the command deletes something, then you can swap out creates with removes
Only use the Ansible shell:
task when absolutely necessary. If you get this error then test if replacing shell:
with command:
resolves the error. If that does not work and you can not figure out how to properly configure the environment for command:
to work, then you can add # noqa 305
at the end of the line that includes the name:
property. The same is true for other linting errors - # noqa
followed by the reported lint error code will instruct ansible-lint
to ignore the error.
{{ load:.config/docs/common/contributing/troubleshooting.md }}