Topics
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.
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 (needs_revision
).
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_ansible
or 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.
core_review
.new_plugin: this is for new modules or plugins that are not yet in Ansible.
Note: new_plugin kicks off a completely separate process, and frankly it doesn’t work very well at present. We’re working our best to improve this process.