First of all, thanks for visiting this page 😊 ❤️ ! We are totally ecstatic that you may be considering contributing to this project. You should read this guide if you are considering creating a pull request.
- ➤ Code of Conduct
- ➤ Philosophy
- ➤ Supported Operating Systems
- ➤ Setting Up Development Environment
- ➤ Pull Requests
- ➤ Code Format
- ➤ Code Style
- ➤ Commenting
- ➤ 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.
- 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. The following is required for developing and testing this Ansible project:
- Ansible >=2.10
- Python 3, along with the
python3-netaddrandpython3-piplibraries (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
With all the requirements installed, navigate to the root directory and run the following commands to set up the development environment which includes installing the Python dependencies and installing the Ansible Galaxy dependencies:
npm i
This will install all the dependencies and automatically register a pre-commit hook. More specifically, npm i will:
- 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
With the dependencies installed, you can see a list of the available commands by running npm run info. 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:
❯ npm run info
> ansible-project@1.0.0 info
> npm-scripts-info
commit:
IMPORTANT: Whenever committing code run 'git-cz' or 'npm run commit'
fix:
Automatically fix formatting errors
info:
Displays descriptions of all the npm tasks
lint:
Report linting errors
prepare-release:
Prepares the repository for a release
test:
Runs molecule tests for all the supported operating systems (this is RAM intensive)
test:docker:
Runs molecule tests using Docker
test:local:
Installs the role on your local machine
test:archlinux:
Provisions an Archlinux Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:centos:
Provisions a CentOS Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:debian:
Provisions a Debian Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:fedora:
Provisions a Fedora Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:macosx:
Provisions a Mac OS X VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:ubuntu:
Provisions a Ubuntu Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
test:windows:
Provisions a Windows Desktop VirtualBox VM, installs the role(s), and does not delete the VM after testing
update:
Runs .update.sh to automatically update meta files, documentation, and dependencies
version:
Used by 'npm run prepare-release' to update the CHANGELOGUsing the information provided above by running npm run info, we can see that npm run build will run the build step described above. You can see exactly what each command is doing by checking out the package.json file.
If you are experiencing issues with the Python modules, you can make use of venv by running the following before running the above commands:
python3 -m venv venv
source venv/bin/activate
All pull requests should be associated with issues. You can find the issues board on GitLab. The pull requests should be made to the GitLab repository instead of the GitHub repository. This is because we use GitLab as our primary repository and mirror the changes to GitHub for the community.
Instead of using git commit, we prefer that you use npm run commit. You will understand why when you try it but basically it streamlines the commit process and helps us generate better CHANGELOG.md files.
Even if you decide not to use npm run commit, you will see that git commit behaves differently since the pre-commit hook is installed when you run npm i. This pre-commit hook is there to test your code before committing. If you need to bypass the pre-commit hook, then you will have to add the --no-verify tag at the end of your git commit command (e.g. git commit -m "Commit" --no-verify).
We try to structure our Ansible task and variable files similarly 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 and 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.ymlfile - 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
npm iin the root of a project)
To dive a little deeper, take the following block of code that was retrieved from tasks/main.yml from 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'Now, if you compare the block of code above to other tasks/main.yml files in other roles (which you can find in our GitLab Ansible Roles group or our main playbook), you will see that the files are either identical or nearly identical. However, 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.
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 the main playbook, then 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.
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'
To elaborate again, 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, initialize all the submodules either via npm i 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
...
when:
- install_minikube
- install_hyperv_pluginGOOD
when: install_minikube
...
when:
- install_minikube
- install_hyperv_pluginAnywhere an array/list is used, the list should be ordered alphabetically (if possible).
BAD
autokey_dependencies:
- pkg-config
- make
- gitGOOD
autokey_dependencies:
- git
- make
- pkg-configIn most cases, a role will require that software package dependencies are met before installing the software the role is intended for. These dependencies are usually an array of packages that need to be installed. These dependencies should be separated out into an array.
For example, say the application being installed is Android Studio. The dependency array should be assigned to a variable titled androidstudio_dependencies and placed in vars/main.yml.
BAD
- name: "Ensure {{ app_name }}'s dependencies are installed"
community.general.pacman:
name: "{{ android_studio_deps }}"
state: presentGOOD
- name: "Ensure {{ app_name }}'s dependencies are installed"
community.general.pacman:
name: "{{ androidstudio_dependencies }}"
state: presentIf there are dependencies that are specific to a certain OS, then the dependency variable should be titled {{ androidstudio }}_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:
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 tie into our automated documentation generation system. This project uses 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 seperate the description into new lines so you do not pass the 160 character
# limit
variable_name: default_valueThere are cases where you may want include an example or you can not fit the default_value on one line. In cases like this, use the following format:
# @var variable_name: []
# The description of the variable which should be no longer than 160 characters per line.
# You can seperate 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
# @endEach variable/comment block in defaults/main.yml should be seperated 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 | boolThe 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_installvariable is set to true, then Docker will be installed as a snap package.
Installs Docker Compose
- Installs Docker Compose if the
docker_install_composevariable 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.ymlfile. However, there may be use cases for putting an action comment in another file. For instance, if we did not support adding wildcard TLS certificates on Windows hosts only, then we might add an action comment to theinstall-Windows.ymlfile with the appropriate action section heading with further details. - 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 descriptionThe above code will output something that looks like this:
bug
- bug description
- another bug description
improvement
- improvement description
- 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
You can test all of the operating systems we support by running the following command in the root of the project:
molecule testThe 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 file an issue 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:
molecule converge # Creates the VM (without deleting it)
molecule login # Logs you in via SSHFor 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-desktopThis 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 (i.e. folder name).
The process of running linters is mostly automated. Molecule is configured to lint so you will see linting errors when you run molecule test (if your code has any). There is also a pre-commit hook that lints your code and performs other validations before allowing a git commit, npm run commit, or git-cz command 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.
You can manually run ansible-lint by executing the following command in the project's root:
pip3 install -r requirements.txt # This is unneeded if you have followed the instructions described previously
ansible-lintMost 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. This is because changing file permissions can 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 (with 'args' keyword)
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 removesOnly 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.