ansible / galaxy-lint-rules Goto Github PK

Ansible Lint rules used by Galaxy and Mazer to evaluate Ansible content

License: Apache License 2.0

Python 100.00%

galaxy-lint-rules's Introduction

Ansible

Ansible is a radically simple IT automation system. It handles configuration management, application deployment, cloud provisioning, ad-hoc task execution, network automation, and multi-node orchestration. Ansible makes complex changes like zero-downtime rolling updates with load balancers easy. More information on the Ansible website.

Design Principles

Have an extremely simple setup process with a minimal learning curve.
Manage machines quickly and in parallel.
Avoid custom-agents and additional open ports, be agentless by leveraging the existing SSH daemon.
Describe infrastructure in a language that is both machine and human friendly.
Focus on security and easy auditability/review/rewriting of content.
Manage new remote machines instantly, without bootstrapping any software.
Allow module development in any dynamic language, not just Python.
Be usable as non-root.
Be the easiest IT automation system to use, ever.

Use Ansible

You can install a released version of Ansible with pip or a package manager. See our installation guide for details on installing Ansible on a variety of platforms.

Power users and developers can run the devel branch, which has the latest features and fixes, directly. Although it is reasonably stable, you are more likely to encounter breaking changes when running the devel branch. We recommend getting involved in the Ansible community if you want to run the devel branch.

Get Involved

Read Community Information for all kinds of ways to contribute to and interact with the project, including mailing list information and how to submit bug reports and code to Ansible.
Join a Working Group, an organized community devoted to a specific technology domain or platform.
Submit a proposed code update through a pull request to the devel branch.
Talk to us before making larger changes to avoid duplicate efforts. This not only helps everyone know what is going on, but it also helps save time and effort if we decide some changes are needed.
For a list of email lists, IRC channels and Working Groups, see the Communication page

Coding Guidelines

We document our Coding Guidelines in the Developer Guide. We particularly suggest you review:

Branch Info

The devel branch corresponds to the release actively under development.
The stable-2.X branches correspond to stable releases.
Create a branch based on devel and set up a dev environment if you want to open a PR.
See the Ansible release and maintenance page for information about active branches.

Roadmap

Based on team and community feedback, an initial roadmap will be published for a major or minor version (ex: 2.7, 2.8). The Ansible Roadmap page details what is planned and how to influence the roadmap.

Authors

Ansible was created by Michael DeHaan and has contributions from over 5000 users (and growing). Thanks everyone!

Ansible is sponsored by Red Hat, Inc.

License

GNU General Public License v3.0 or later

See COPYING to see the full text.

galaxy-lint-rules's People

Contributors

Stargazers

Watchers

Forkers

rvben elnappo mustafaeissa

galaxy-lint-rules's Issues

[105GAL] Deprecated with_X for loops - not in Ansible 2.7?

I'm wondering if the following lint rule:

[105GAL] Deprecated with_X for loops

Is meant to be live yet? I know with_ was slated for deprecation in 2.7 (see ansible/ansible#43795), but that PR was closed with the following message prior to 2.7.0's release:

Closing for now.

We are not planning to continue with deprecation of with_ yet.

This is probably 90% of all the warnings I'm seeing in my own playbooks and roles when testing with this set of rules; and since with_ is not deprecated yet in Ansible, it would be best if we don't say as much using the Galaxy lint rules (at least IMHO).

405GAL doesn't seem to take into account variables for template src

For my GitLab role, I have the following task:

- name: Copy GitLab configuration file.
  template:
    src: "{{ gitlab_config_template }}"
    dest: /etc/gitlab/gitlab.rb
    owner: root
    group: root
    mode: 0600
  notify: restart gitlab

And gitlab_config_template is defined as:

gitlab_config_template: "gitlab.rb.j2"

When I run Ansible Lint on it with these rules I get:

[405GAL] Template files should have the extension '.j2' 
/Users/jeff.geerling/Dropbox/VMs/roles/geerlingguy.gitlab/tasks/main.yml:69
Task/Handler: Copy GitLab configuration file.

It looks like 405GAL is not taking into account variable expansion for template names—not sure if this is possible to do, but there are a number of roles where I use a variable for the template to allow role users to override the template location.

(Also, aside: it seems like the output for this rule has an extra space on the end [405GAL] Template files should have the extension '.j2' (hard to convey without an empty whitespace highlighter, but it's there when I copy and paste into my IDE, whereas it's not there for any other rules)).

205GAL and 208GAL - Duplicates?

For the following line in one of my roles:

    repo: 'deb https://oss-binaries.phusionpassenger.com/apt/passenger {{ansible_distribution_release}} main'

I got both of the following warnings:

[205GAL] Variables should be enclosed by spaces "{{ foo }}"
/Users/jeff.geerling/Dropbox/VMs/roles/geerlingguy.passenger/tasks/main.yml:23
    repo: 'deb https://oss-binaries.phusionpassenger.com/apt/passenger {{ansible_distribution_release}} main'

[208GAL] Variables should have spaces after {{ and before }}
/Users/jeff.geerling/Dropbox/VMs/roles/geerlingguy.passenger/tasks/main.yml:23
    repo: 'deb https://oss-binaries.phusionpassenger.com/apt/passenger {{ansible_distribution_release}} main'

It seems like these two rules are redundant.

Add instructions for usage in README

I hadn't tried using a custom ruleset with ansible-lint before, and to save myself and others the trouble of figuring out how it's done, maybe this repository could have a little instruction set in the README for how to test them / use them quickly?

I may file a quick PR with a suggestion.

community process?

Is this ruleset community driven? Once the three well-know rulesets are in place I’d appreciate an open discussion of the best practices to be implemented in (strict) rules, and the lienience on others.

LineTooLongRule - how to deal with it?

I have a number of cases where an entire repo has lines under 80 chars or 120 chars (the most common line length limits I live by), but every now and then there's a line (e.g. in a vars file) that requires a large number more characters, lest the variable end up being really hard to work with. For example, this var in the defaults/main.yml file from my geerlingguy.docker role:

docker_apt_repository: "deb [arch={{ docker_apt_arch }}] https://download.docker.com/linux/{{ ansible_distribution|lower }} {{ ansible_distribution_release }} {{ docker_apt_release_channel }}"

(193 characters)

Is there any better option of fixing a lint issue like this, or should those of us who try to make flexible variables just suffer the loss of perceived code quality due to the use of variables here? :-/