Style Guide for EGI Ansible

see egi-federation.github.io/ansible-style-guide

Usage

This repository contains style guide for EGI’s use of Ansible. It will

• Generate styling 🏄🏾 Ansible roles, all dressed up and ready to roll 👗 using
  a sweet skeleton
• Pass an expert eye over your code, applying the
  Ansible Fashion Police compliance profile,
  to help you stick with the style guide as you code.

See the
quickstart if
you’re just super keen 😍.

See EGI’s roles on Galaxy. You can
find guides on:

• Documenting roles
• Ansible syntax in roles
• Testing role scenarios, testing tools
• Role release and publication
• Collaborating with code

Motivation

EGI is responsible for several
internal services either directly, or
through collaboration with partners. Ansible roles are a simple, powerful way to
express the desired state and composition of these services. As with many
languages and tools, a certain amount of leeway is possible when it comes to the
style of implementation. When working on roles, it’s a good idea to have common
nomenclature, follow common styles and adopt common practice regarding
documentation, community engagement, maintenance, support, etc. With this
repository, we express the consensus view of the
EGI Operations team
about how Ansible roles should be developed. It’s raisons d’etre are:

• Improve peer review: discuss issues of style out-of-band so that when it
  comes to peer review of pull requests, there is an unambiguous reference. This
  will help speed up peer review, and make it more attractive for
  repository maintainers to actually conduct such peer review. Further it will
  encourage contributors, providing better transparency in the process, and
  allowing discussion around the style guide itself.

• Improve reliability, test coverage: Ansible roles can and should be
  tested according to common profiles. Infrastructure tests can be expressed
  in plain language, easy to read, and easy to audit. Test coverage and profiles
  can be harmonised across roles so that they can be applied modularly with
  confidence.

• Promote re-use: Roles can only be re-used if they are reliable and deliver
  what they claim to. If, through the points above, we can improve the re-use of
  these roles, we can avoid dispersion of effort and even better, start to give
  proper recognition to the authors and peer reviewers of roles.

All in all, we have a more robust infrastructure, less toil and better
collaboration.

Contributing

As a community of practice, we welcome contributions which work smoother and
help us be more inclusive. If you see something you think needs to change, or is
missing, please open a pull request. If you could read the
Contributor’s Guide first, that might help.

If you have feedback or would like to engage on issues related to this, start a
discussion on the EGI Community Forum

Code of Conduct

EGI believes in a healthy community and welcomes diverse points of view.
Contributors to and users of this repository are asked to refer to the
Code of Conduct regarding any conflicts or events
of abuse which may arise. The maintainers undertake to abide by the Code of
Conduct in their dealings with each other and the community.