This article assumes you are already familiar with flake8. Probably you faced at least one of the challenges below related to: adoption requires a lot of code reformatting some rules contradict each other, like W503/W504 different rules on different projects newer versions requiring rework … why I am wasting my time with linting Years ago, OpenStack team release a package named hacking which aimed to address some of the problems listed above.
Writing easy to maintain Ansible roles and playbooks is more of secret art that will take years to master. Product documentation is useful but is far from complete and lacks lots of hints.
List the tests pytest --collect-only Run only specific tests If you want to run only tests that have ‘foo’ in their name or path, it is as easy as: pytest -k foo Limit which tests run by using markes Test markers are like ansible tags, just some labels which can be assigned to tasks and you can decide which one you want to run or skip. They can be hardcoded in test definition or added dynamically.
Using when conditions in Ansible for adding support for multiple platforms and their versions does not scale well. As soon you need to support more than two versions it will hit you hard and make your code hard to maintain. The trick is to load tailored presets for each platform and version when your role starts and use these values of these variables when performing tasks. Most of the time this saves you from adding conditions to tasks.
What it does? GRI lists reviews in a compressed format which also allows you to click either review number of topic to open them in your browser, if your terminal supports hyperlink extension. Since I created that tool the number of open reviews I had went down considerably and I suspect that its ability to focus on reviews that are likely to merge or to be abandoned helps cleaning up the queus.
I got a special use case: where I has a group of hosts I wanted to test with molecule but I knew that at least one of them will fail with current code. I did not want to fail the execution due to the expected failure, so I ended up doing this complex logic below. The first part detects only reacable hosts and avoid failing the playbook if they are reacable (something that can happen if for example molecule fails to even create them).
If you ever used ignore_errors before you probably observed one of its side effects: Ansible console output becomes much harder to inspect because your it will contain lots of red (failed) task around, so scrolling to the right line would be much harder. It will trigger Ansible debugger if you configured ANSIBLE_STRATEGY=debug, even if you are likely not to want this making the use of debugger kinda useless if you have lots of such ignore_errors.