Greetings.
An item that came out of our meetings last week was to try and standardize style and checks on our ansible repo. This has a number of goals, including making things more readable for newcomers as well as reducing the number of errors we commit and have to correct.
Toward that end, we decided to start using 'ansible-review' on our playbooks/roles/commits. ansible-review is packaged in fedora and comes with a set of default rules which is easy to expand or reduce. We decided to start with the standard rules and asjudt from there.
I setup: https://pagure.io/cpe/ansible-review-templates (which currently doesn't have anything in it) as a central place to hold any rules when/if we change from the default.
We don't yet have ansible-review as a hook, but we hope to add it soon. It would only reject on errors, not warnings (of which we have a lot). Once we get ansible setup to handle PR's we can add it in there as a CI step. In the mean time you can run it over any changes you are about to make easily enough (just cat whatever things into 'ansible-review').
Additionally, we came up with a few other items:
* Use 'yml' instead of 'yaml'
* do add '.j2' to the end of templates
* in general let readablity trump grepability, ie:
DONT: - name: This is some play module: name=thing arg=thing2 anotherlongerarg=thing arg4=anodheranth
DO: - name: This is some play module: - name: thing - arg: thing2 ..etc
I have added a "STYLEGUIDE" text file to the root on the ansible repo with this infrmation also.
If you can think of other things we should standardize on, please do follow up on this thread or file a ticket and we can discuss.
Thoughts?
Thanks,
kevin
Kevin,
I think this ideas are perfect! This is are in line with best practices. Have we thought about using molecule to help with some of this process? How about using collections in the future?
Sent from ProtonMail Mobile
On Fri, Jun 21, 2019 at 4:53 PM, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
An item that came out of our meetings last week was to try and standardize style and checks on our ansible repo. This has a number of goals, including making things more readable for newcomers as well as reducing the number of errors we commit and have to correct.
Toward that end, we decided to start using 'ansible-review' on our playbooks/roles/commits. ansible-review is packaged in fedora and comes with a set of default rules which is easy to expand or reduce. We decided to start with the standard rules and asjudt from there.
I setup: https://pagure.io/cpe/ansible-review-templates (which currently doesn't have anything in it) as a central place to hold any rules when/if we change from the default.
We don't yet have ansible-review as a hook, but we hope to add it soon. It would only reject on errors, not warnings (of which we have a lot). Once we get ansible setup to handle PR's we can add it in there as a CI step. In the mean time you can run it over any changes you are about to make easily enough (just cat whatever things into 'ansible-review').
Additionally, we came up with a few other items:
Use 'yml' instead of 'yaml'
do add '.j2' to the end of templates
in general let readablity trump grepability, ie:
DONT:
- name: This is some play
module: name=thing arg=thing2 anotherlongerarg=thing arg4=anodheranth
DO:
- name: This is some play
module:
- name: thing
- arg: thing2
..etc
I have added a "STYLEGUIDE" text file to the root on the ansible repo with this infrmation also.
If you can think of other things we should standardize on, please do follow up on this thread or file a ticket and we can discuss.
Thoughts?
Thanks,
kevin
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
On 6/21/19 4:23 PM, Jlozada2426 wrote:
Kevin,
I think this ideas are perfect! This is are in line with best practices. Have we thought about using molecule to help with some of this process? How about using collections in the future?
We could look again at molecule, but in the past I haven't seen it as a good fit for our setup. It could have changed.
We also definitely want to look at collections, but they are so new we just haven't decided where/what they will best help us do. :)
Thanks for the feedback!
kevin --
Sent from ProtonMail Mobile
On Fri, Jun 21, 2019 at 4:53 PM, Kevin Fenzi kevin@scrye.com wrote:
Greetings.
An item that came out of our meetings last week was to try and standardize style and checks on our ansible repo. This has a number of goals, including making things more readable for newcomers as well as reducing the number of errors we commit and have to correct.
Toward that end, we decided to start using 'ansible-review' on our playbooks/roles/commits. ansible-review is packaged in fedora and comes with a set of default rules which is easy to expand or reduce. We decided to start with the standard rules and asjudt from there.
I setup: https://pagure.io/cpe/ansible-review-templates (which currently doesn't have anything in it) as a central place to hold any rules when/if we change from the default.
We don't yet have ansible-review as a hook, but we hope to add it soon. It would only reject on errors, not warnings (of which we have a lot). Once we get ansible setup to handle PR's we can add it in there as a CI step. In the mean time you can run it over any changes you are about to make easily enough (just cat whatever things into 'ansible-review').
Additionally, we came up with a few other items:
Use 'yml' instead of 'yaml'
do add '.j2' to the end of templates
in general let readablity trump grepability, ie:
DONT:
- name: This is some play
module: name=thing arg=thing2 anotherlongerarg=thing arg4=anodheranth
DO:
- name: This is some play
module:
- name: thing
- arg: thing2
..etc
I have added a "STYLEGUIDE" text file to the root on the ansible repo with this infrmation also.
If you can think of other things we should standardize on, please do follow up on this thread or file a ticket and we can discuss.
Thoughts?
Thanks,
kevin
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedorapro...
infrastructure@lists.fedoraproject.org