Making progress in resolving issues for modules depends upon your interaction! Please be sure to respond to requests or additional information as needed.

If at any time you think this bot is misbehaving (not for test failures), please leave a comment containing the keyword bot_broken and an Ansible staff member will intervene.

• Overview
• For issue submitters
• For pull request submitters
  • When will your pull request be merged?
    • New Modules
    • Existing Modules
      • core
      • certified
      • community
      • network
    • Non-module changes
• For community maintainers
• For anyone else
• Commands
• Labels
  • When to use label commands
  • How to use label commands

The Ansibull Triage Bot serves many functions:

• Responds quickly to issue and pull request submitters to thank them;
• Identifies the maintainers responsible for reviewing pull requests for any files affected;
• Tracks the current status of pull requests;
• Pings responsible parties to remind them of any actions that they may be responsible for;
• Provides maintainers with the ability to move pull requests through our workflow;
• Identifies issues and pull requests abandoned by their authors so that we can close them;
• Identifies modules abandoned by their maintainers so that we can find new maintainers;
• Automatically labels issues and pull requests based on keywords or affected files.

Please note that if you have a question about how to use this feature or module with Ansible, that's probably something you should ask on the ansible-project mailing list, rather than submitting a bug report. For more details, please see I’ve Got A Question.

If the feature/module maintainer or ansibullbot needs further information, please respond to the request, so that you can help the devs to help you!

The bot requires a minimal subset of information from the issue template:

• issue type
• component name
• ansible version
• summary

If any of those items are missing or empty, ansibullbot will keep the issue in a needs_info state until the data is provided in the issue's description. The bot is expecting an issue description styled after the default issue template, so please use that whenever possible.

Expect the bot to do a few things:

1. Add common labels such as needs_triage, bug_report, feature_idea, etc.

   These labels are determined by templated data in the description. Please fill out the templates as accurately as possible so that the appropriate labels are used.

2. Notify and assign the maintainer(s) of the relevant file(s) or module(s).

   Notifications will happen via a comment with the @NAME syntax. If you know of other interested parties, feel free to ping them in a comment or in your issue description.

If you are not sure who the issue is waiting on, please use the bot_status command.

Expect the bot to do a few things:

1. All of the items described in the for issue submitters section.

2. Add labels indicating the status of the pull request.

Please prefix your pull request's title with WIP if you are not yet finished making changes. This will tell the bot to ignore the needs_rebase and shipit workflows until you remove it from the title.

If you are finished committing to your pull request or have made changes due to a request, please use the ready_for_review command.

If you are not sure who the pull request is waiting on, please use the bot_status command.

ℹ️ Approve pull request status is ignored, shipit command is used by maintainer to approve a pull request. The bot automatically adds a shipit label to the pull request when the required number of shipit commands has been reached.

The bot will label a pull request with shipit when at least two [shipit] commands are issued, the following rules describe how shipit commands are count:

• shipit issued by a module maintainer or a maintainer of a module in the same namespace or a core team member are always taken in account
• when the submitter is a module maintainer or a maintainer of a module in the same namespace or a core team member, their shipit is automatically counted
• shipit issued by anyone else is taken in account when both conditions are met:
  • at least one module maintainer or a maintainer of a module in the same namespace or a core team member has approved the pull request with a shipit command
  • at least three people which aren't maintainer nor core team member have approved the pull request using the shipit

Once the pull request labeled with shipit, the module will be merged once a member of the Ansible organization has reviewed it and decided to include it.

ℹ️ If you are a maintainer of a module in the same namespace, only one shipit is required.

Module's have metadata with a supported_by field per the metadata proposal.

ℹ️ If you have changes to other files in the pull request, the supported_by property is ignored because the Ansible core team must approve those changes. When other changes are line deletions in ansible/test/*/*.txt files, the supported_by property isn't ignored.

ℹ️ if the pull request has more than one committer, then number of commits must be equal to number of authors and lower than 11.

The possible values of supported_by are:

Members of the Ansible Core Team typically do all the maintenance on this module, so only they can approve changes. Expect reviews to take longer than most other modules because of the volume the core team has on a daily basis.

These modules are developed and maintained by the community, but the Ansible core team needs to approve changes. Once the pull request is labeled with shipit, the core team will be alerted to review.

These modules are also developed, maintained and supported by the community. If you are a module maintainer, a maintainer of a module in the same namespace, or a core team member use the shipit command to approve the pull request. The bot will wait for the pull request being labeled with shipit, then automerge.

ℹ️ If you are maintainer of the module or maintainer of a module in the same namespace, only one shipit is required.

Members of the Ansible Network Team typically do all the maintenance on this module, so only they can approve changes.

The ansible core team approves these pull requests and it may take some time for them to get to your request.

ℹ️ Approve pull request status is ignored, shipit command must be used in order to approve a pull request.

Thanks in advance for taking a look at issues and pull requests and for your ongoing maintenance. If you are unable to troubleshoot or review this issue/pull request with the information provided, please ping the submitter of the issue in a comment to let them know.

Reactions help us determine how many people are interested in a pull request or have run across a similar bug. Please leave a 1 reaction (: 1:) if that applies to you. Any additional details you can provide, such as your usecase, environment, steps to reproduce, or workarounds you have found, can help out with resolving issues or getting pull requests merged.

To streamline the maintenance process, we've added some commands to Ansibullbot that you can use to help direct the work flow. Using the automation is simply a matter of adding one of the following commands in your comments:

The bot adds many labels on issues and pull requests.

Some labels are used to categorize issues and pull requests:

• Pull requests related to test:

  • test

• Namespace labels:

  • aci
  • avi
  • aws
  • azure
  • cloud
  • cloudstack
  • digital_ocean
  • docker
  • f5
  • gce
  • infoblox
  • jboss
  • meraki
  • netapp
  • networking
  • nxos
  • openstack
  • ovirt
  • ucs
  • vmware
  • windows

• Module labels:

  • m:unarchive
  • m:xml

The label and -label commands are restricted to a subset of available labels and are not meant to replace the other bot commands:

• affects_X.Y -- indicates that the issue is relevant to a particular ansible major.minor version.
• c:... -- these labels categorize issues or pull requests by their relevant source code files.
• easyfix -- indicates that the issue an easy entrance point for people who are looking to start contributing.
• m:... -- these labels categorize issues or pull requests by their module name.
• module -- classifies the issue as a module related issue.
• needs_triage -- a human being still needs to validate the issue is properly labeled and has all the information required.
• test and namespace labels

To use the commands, please type the command and label on one line each in a comment. Example:

-label needs_triage
 label cloud
 label gce