Contributor’s Guide

All kinds of contributions are more than welcomed. You can help make tower CLI better by reporting bugs, come up with feature ideas or, even further, help maintainers out by making pull requests. Make sure you follow the rules below when contributing and you are ready to roll ;)

Bug Reports

Reporting bugs is highly valuable to us. For flexibility, we do not provide issue templates, but describe the issue as specific as possible to make it easier and faster for us to hunt down the issue.

• First check existing issues to see if it has already been created, if it has, giving issue description a “thumbs up”.
• Mark the issue with ‘bug’ label.
• Be sure to mention Tower backend version, Tower CLI version and python interpreter version when the bug occurs.
• Copy-paste the detailed usage (code snippet when using as python library and command when using as CLI) and error message if possible.

Feature Requests

We welcome all sorts of feature ideas, but note, it may be scheduled for a future release rather than the next one, please be patient while we process your request. We will ping you on github once the feature is implemented.

• Mark the issue with ‘enhancement’ label.

Architecture Overview

All available Tower CLI resources descend from the abstract class tower_cli.models.base.BaseResource, which provides two fundamental methods, read and write. The read method wraps around a GET method to the specified resource, while write wraps around a POST or PATCH on condition. Most public resource APIs, like create or list, are essentially using a combination of read and write to communicate with Tower REST APIs.

class tower_cli.models.base.BaseResource

Abstract class representing resources within the Ansible Tower system, on which actions can be taken. Includes standard create, modify, list, get, and delete methods.

Some of these methods are not created as commands, but will be implemented as commands inside of non-abstract child classes. Particularly, create is not a command in this class, but will be for some (but not all) child classes.

read(pk=None, fail_on_no_results=False, fail_on_multiple_results=False, **kwargs)

Retrieve and return objects from the Ansible Tower API.

Parameters:

• pk (int) – Primary key of the resource to be read. Tower CLI will only attempt to read that object if pk is provided (not None).
• fail_on_no_results (bool) – Flag that if set, zero results is considered a failure case and raises an exception; otherwise, empty list is returned. (Note: This is always True if a primary key is included.)
• fail_on_multiple_results (bool) – Flag that if set, at most one result is expected, and more results constitutes a failure case. (Note: This is meaningless if a primary key is included, as there can never be multiple results.)
• query (list) – Contains 2-tuples used as query parameters to filter resulting resource objects.
• **kwargs – Keyword arguments which, all together, will be used as query parameters to filter resulting resource objects.

Returns:

loaded JSON from Tower backend response body.

Return type:

dict

Raises:

• tower_cli.exceptions.BadRequest – When 2-tuples in query overlaps key-value pairs in **kwargs.
• tower_cli.exceptions.NotFound – When no objects are found and fail_on_no_results flag is on.
• tower_cli.exceptions.MultipleResults – When multiple objects are found and fail_on_multiple_results flag is on.

write(pk=None, create_on_missing=False, fail_on_found=False, force_on_exists=True, **kwargs)

Modify the given object using the Ansible Tower API.

Parameters:

• pk (int) – Primary key of the resource to be read. Tower CLI will only attempt to read that object if pk is provided (not None).
• create_on_missing (bool) – Flag that if set, a new object is created if pk is not set and objects matching the appropriate unique criteria is not found.
• fail_on_found (bool) – Flag that if set, the operation fails if an object matching the unique criteria already exists.
• force_on_exists (bool) – Flag that if set, then if an object is modified based on matching via unique fields (as opposed to the primary key), other fields are updated based on data sent; If unset, then the non-unique values are only written in a creation case.
• **kwargs – Keyword arguments which, all together, will be used as POST/PATCH body to create/modify the resource object. if pk is not set, key-value pairs of **kwargs which are also in resource’s identity will be used to lookup existing reosource.

Returns:

A dictionary combining the JSON output of the resource, as well as two extra fields: “changed”, a flag indicating if the resource is created or successfully updated; “id”, an integer which is the primary key of the specified object.

Return type:

dict

Raises:

tower_cli.exceptions.BadRequest – When required fields are missing in **kwargs when creating a new resource object.

Here is the detailed class hierarchy from tower_cli.models.base.BaseResource to all specific Tower resources:

Details of each Tower CLI resource module are available under tower_cli/resources/.

Some root-level modules under tower_cli/ folder are of great importance. Specifically, api.py contains details of the API client Tower CLI used to make HTTP(S) requests using requests, and conf.py is used to define and initialize singleton setting object tower_cli.conf.settings.

On the other hand, tower_cli/cli/ folder contains code that extends tower_cli from a python library into a full- fledged command-line interface. We use click as the CLI engine.

Code Contributions

Setting up development environment and playing around with Tower CLI is quite straight-forward, here is the usual development procedure:

1. Branch out a local issue branch from the correct base branch.
2. Create an empty virtual environment.
3. Code.
4. Run make install to install development Tower CLI and all its dependency to virtual environment.
5. Manually test on your bug fix/feature and modify until manual tests pass.
6. Run sudo pip install tox. Then at the root directory of Tower CLI repository, run sudo tox . to run flake8 verify and unit test against all supported python versions. Run and modify until all flake8 checks and unit tests pass.
7. Commit, push to local fork and make pull request targeting the correct base branch.
8. Wait for a maintainer to either approve and merge the pull request, or update pull request according to feedback comment.

Some points to keep in mind when developing:

• Target the correct branch. Currently we use branch ‘v1’ to track 3.1.x versions and ‘master’ to track 3.2.0 and beyond.
• Consider all API versions. Currently 3.1.x versions are exclusively used for API v1 and 3.2.0 and beyond are exclusively used for API v2, that means if you fixed a bug for 3.1.8, switch to 3.2.0 and see if the same or similar bug exists and needs similar fix.
• Consider python 2/3 compatibility, make good use of six and tower_cli.compat.
• Consider docs update. Whenever a new resource, new resource public method or new resource field is added, inspect the docs folder and make all necessary updates before committing. Whenever HISTORY.rst at base directory changes replace docs/source/HISTORY.rst with the latest version.
• Adhere to the flake8 specifications when developing, the only exception we allow is the maximum line length, which is 120 characters rather than 79.
• Be pythonic by using meaningful names and clear structures. Make code self-explanatory rather than adding excessive comments.
• Be test-driven. Although not mandatory, please try keeping test coverage at least the same as before, we appreciate it if you can increase our test coverage in your pull requests.