How to file good bug reports

Hi all,

I wanted to share a quick reminder about what we look for in filing tickets in GitHub.

Bugs should be reported on github - http://github.com/ansible/ansible, not the mailing list. The mailing list is not a bug forum, but a place to share what people are doing with ansible as well as to ask questions. There are cases where help threads to the mailing list result in a request to post something to github – but if you know you have a bug, just go straight to github.

Name tickets descriptively: Always name bug tickets well enough so someone reading the ticket can understand what the bug is about without reading the ticket. “Foo module traceback when bar=xyz” is great. “Foo module is broken” is bad because it doesn’t say how it is broken. “traceback when bar=xyz” is bad too, as we don’t know what part of the code it is about. “Foo doesn’t work” is generally bad all over, as we don’t even know what “working” would mean most of the time.

State what you expect: state what you would expect to happen and what actually happens

Show your versions: Always include the entire output of “ansible --version”. Don’t just say “devel” if you are running devel, include the output every time. About 9/10 of tickets do not include the Ansible version they are being tested against.

Be succinct: Where possible communicate the problem as succintly as possible. Avoid asking a lot of intermediate questions where we have to determine what is the key question in the ticket. you are sharing a way to reproduce something, boil it down to a minimal example. If you can show something that uses one variable and the template module, that’s better than an example that requires a HA setup of a whole database on Solaris and 40 different YAML files

Share Input and Output: Where possible include a playbook or snippet to reproduce the problem in the ticket text – or if spanning many different files, you may host a repo, or put something up on gist.github.com so we can easily paste it and reproduce something. Avoid posting content pastebins and linking to them on the ticket system, because content can expire – and the content posted is not readable when searching through the bug tracker.

​This works great when running ansible directly from the git checkout, and
using the ​hacking/env-setup script.
It won't help though if you build a package from the devel tree (and I
suppose also when make installing it from there.)

The former will show the git hash commit in ansible --version:

  ansible 1.4 (devel 60944b81f0) last updated 2013/10/20 16:46:57 (GMT +200)

the latter wil just show the current devel version

  ansible 1.4

Not sure if it is easily feasible to extend that version string when making
a package.

Serge

Not too many people build packages off devel, but if they do, I’d just request they include the SHA however they want.

I build packages off devel, and having the hash in version output would be helpful. Pasted the full hash of the git commit into the issue and github did a nice job of turning it into a link.

I’ve opened a ticket – and hope the semantics of it our “right”. The issue is: https://github.com/ansible/ansible/issues/4638

If the semantics of this are wrong please provide a model issue you’d like us to use.

~ Brice