Aomi: Opinionlessly Express Opinions on Vault

If you are new to aomi, please checkout our documentation. You may be particularly interested in the quickstart guide.

Contributing

All manner of contributions are welcome. The aomi tool is still relatively young, and emphasis has been placed on the data model concept more than staying current with the Vault API. We are looking for contributors of source code, documentation, and community support.

Code

The aomi project is entirely Python, with some shell scripts binding the tests together. It is compatible wtih both Python 2.7.x and 3.6 (and above). The structure is pretty standard for Python projects. Everything lives in one module namespace and is loosely grouped into modules by context. Minimal PyDoc is required (and enforced by pylint) on each function. The cryptographic functions used for cold storage are implemented in the cryptorito Python module.

When adding new builtin templates, a accompanying help file must be provided. Help is represented as a YAML file with a name and help element and it is used to generate command line help for templates.

Test

This project features the following tests (all are invoked with make test).

Validation against the pep8 spec
pylint with default options
Some unit tests powered by nose2
Static security analysis with bandit
Some integration tests powered by bats.
Checking for unused code paths with vulture

Documentation

The README is focused on contribution guidelines. Operational docs are available on a static GitHub page. These docs are maintained as markdown formatted documents within the docs directory. The static site is updated automatically on every commit into the mainline branch based on the contents of this directory.

Deployment

New docker containers are generated on merge to the master branch. New Python packages are pushed on every tagged commit, which happens during a semantic version bump. I tend to use the avakas to handle version changes.

Guidelines

This project operates under a Code of Conduct.
Changes are welcome via pull request!
Please use informative commit messages and pull request descriptions.
Please remember to update the documentation if needed.
Please keep style consistent. This means PEP8 and pylint compliance at a minimum.
Please add both unit and integration tests. Unit tests should run in complete isolation with all disk/network calls mocked out.

If you have any questions, please feel free to contact jonathan.freedman@autodesk.com.