This section discusses how the Ansible development and triage process works.
The Ansible Core team provides a road map for each upcoming release. These road maps can be found here.
Ansible accepts code via pull requests (“PRs” for short). GitHub provides a great overview of how the pull request process works in general.
Because Ansible receives many pull requests, we use an automated process to help us through the process of reviewing and merging pull requests. That process is managed by Ansibullbot.
After the pull request submitted to Ansible for the
devel branch is
accepted and merged, 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.7is 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.7/[PR_NUMBER_FROM_DEVEL] upstream/stable-2.7
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.7/[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.7/[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.
Ansibullbot serves many functions:
Each module has at least one assigned maintainer, listed in a maintainer’s file:
Some modules have no community maintainers assigned. In this case, the maintainer is listed as
$team_ansible. Ultimately, it’s our goal to have at least one community maintainer for every module.
The maintainer’s job is to review PRs and decide whether that PR should be merged (
shipit) or revised (
The ultimate goal of any pull request is to reach shipit status, where the Core team then decides whether the PR is ready to be merged. Not every PR that reaches 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.
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.