The Ansible development cycle happens on two levels. At a macro level, the team plans releases and tracks progress with roadmaps and projects. At a micro level, each PR has its own lifecycle.
If you want to follow the conversation about what features will be added to Ansible for upcoming releases and what bugs are being fixed, you can watch these resources:
Ansible accepts code via pull requests (“PRs” for short). GitHub provides a great overview of how the pull request process works in general. The ultimate goal of any pull request is to get merged and become part of Ansible Core. Here’s an overview of the PR lifecycle:
Because Ansible receives many pull requests, and because we love automating things, we’ve automated several steps of the process of reviewing and merging pull requests with a tool called Ansibullbot, or Ansibot for short.
Ansibullbot serves many functions:
Ansibullbot runs continuously. You can generally expect to see changes to your issue or pull request within thirty minutes. Ansibullbot examines every open pull request in the repositories, and enforces state roughly according to the following workflow:
$team_ansible, the pull request then goes into the community_review state.
$team_ansible, the pull request then goes into the core_review state (and probably sits for a while).
shipit, the pull request is labeled shipit, whereupon the Core team assesses it for final merge.
needs_info, the pull request is labeled needs_info and the submitter is asked for more info.
ready_for_review, the pull request is put back into community_review or core_review and the maintainer is notified that the pull request is ready to be reviewed again.
$team_ansibleor labeled core_review, or often the submitter of the pull request is asked to step up as a maintainer.
There are corner cases and frequent refinements, but this is the workflow in general.
There are two types of PR Labels generally: workflow labels and information labels.
After Ansibot reviews the PR and applies labels, the PR is ready for human review. The most likely reviewers for any PR are the maintainers for the module that PR modifies.
The maintainer’s job is to review PRs that affect that module and decide whether they should be merged (
shipit) or revised (
needs_revision). We’d like to have at least one community maintainer for every module. If a module has no community maintainers assigned, the maintainer is listed as
Once a human applies the
shipit label, the committers decide whether the PR is ready to be merged. Not every PR that gets the
shipit label is actually ready to be merged, but the better our reviewers are, and the better our guidelines are, the more likely it will be that a PR that reaches shipit will be mergeable.
We don’t merge every PR. Here are some tips for making your PR useful, attractive, and merge-worthy.
Changelogs help users and developers keep up with changes to Ansible. Ansible builds a changelog for each release from fragments. You must add a changelog fragment to any PR that changes functionality or fixes a bug. You don’t have to add a changelog fragment for PRs that add new modules and plugins, because our tooling does that for you automatically.
We build short summary changelogs for minor releases as well as for major releases. If you backport a bugfix, include a changelog fragment with the backport PR.
A basic changelog fragment is a
.yaml file placed in the
changelogs/fragments/ directory. Each file contains a yaml dict with
major_changes followed by a list of
changelog entries of bugfixes or features. Each changelog entry is
rst embedded inside of the yaml file which means that certain
constructs would need to be escaped so they can be interpreted by rst
and not by yaml (or escaped for both yaml and rst if that’s your
desire). Each PR must use a new fragment file rather than adding to
an existing one, so we can trace the change back to the PR that introduced it.
To create a changelog entry, create a new file with a unique name in the
changelogs/fragments/ directory. The file name should include the PR number and a description of the change. It must end with the file extension
.yaml. For example:
A single changelog fragment may contain multiple sections but most will only contain one section. The toplevel keys (bugfixes, major_changes, etc) are defined in the config file for our release note tool. Here are the valid sections and a description of each:
Most changelog entries will be
minor_changes. When writing a changelog entry that pertains to a particular module, start the entry with
- [module name] - and include a link to the related issue if one exists.
Here are some examples:
bugfixes: - win_updates - fixed issue where running win_updates on async fails without any error
minor_changes: - lineinfile - add warning when using an empty regexp (https://github.com/ansible/ansible/issues/29443)
bugfixes: - copy module - The copy module was attempting to change the mode of files for remote_src=True even if mode was not set as a parameter. This failed on filesystems which do not have permission bits.
You can find more example changelog fragments in the changelog directory for the 2.6 release. You can also find documentation of the format, including hints on embedding rst in the yaml, in the reno documentation.
Once you’ve written the changelog fragment for your PR, commit the file and include it with the pull request.
All Ansible PRs must be merged to the
devel branch first.
After a pull request has been accepted and merged to the
devel branch, the following instructions will help you create a
pull request to backport the change to a previous stable branch.
We do not backport features.
These instructions assume that:
stable-2.8is the targeted release branch for the backport
https://github.com/ansible/ansible.gitis configured as a
upstream. If you do not use a
upstream, adjust the instructions accordingly.
https://github.com/<yourgithubaccount>/ansible.gitis configured as a
origin. If you do not use a
origin, adjust the instructions accordingly.
Prepare your devel, stable, and feature branches:
git fetch upstream git checkout -b backport/2.8/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.8
Cherry pick the relevant commit SHA from the devel branch into your feature branch, handling merge conflicts as necessary:
git cherry-pick -x [SHA_FROM_DEVEL]
Add a changelog fragment for the change, and commit it.
Push your feature branch to your fork on GitHub:
git push origin backport/2.8/[PR_NUMBER_FROM_DEVEL]
Submit the pull request for
The Release Manager will decide whether to merge the backport PR before the next minor release. There isn’t any need to follow up. Just ensure that the automated tests (CI) are green.
The choice to use
backport/2.8/[PR_NUMBER_FROM_DEVEL] as the
name for the feature branch is somewhat arbitrary, but conveys meaning
about the purpose of that branch. It is not required to use this format,
but it can be helpful, especially when making multiple backport PRs for
multiple stable branches.
If you prefer, you can use CPython’s cherry-picker tool to backport commits from devel to stable branches in Ansible. Take a look at the cherry-picker documentation for details on installing, configuring, and using it.