Thank you for your interest in contributing to AWS Auto Cleanup. To start contributing first fork our repository into your own Github account, and create a local clone of it. The latter will be used to get new features implemented or bugs fixed. Once done and you have the code locally on the disk, you can get started. We advice to not work directly on the master branch, but to create a separate branch for each issue you are working on. That way you can easily switch between different work, and you can update each one for latest changes on upstream master individually.
Please ensure you create a single cleanup function with the same name as the resource with the service class.
Each function should contain a Python docstring matching the formatting found inside the repository.
Example:
def s3_bucket_ssl_requests_only(self, resource_id):
"""Adds Bucket Policy to force SSL only connections
Arguments:
resource_id {string} -- S3 Bucket name
Returns:
boolean -- True if remediation was successful
"""AWS Auto Cleanup utilises the Moto Python library for automated testing via pytest. For each new function written to cleanup a resource, please ensure a new test class is created within the test folder. This class should incorporate functions for both positive and negative tests. See Moto's Implementation Coverage page for all supported mock API calls.
If the API calls within your new cleanup function are not covered by Moto, please ensure the COVERAGE.md is updated with No Moto support for your particular cleanup.
AWS Auto Cleanup is using the Python Black code formatter for Python and Prettier code formatter for all YAML and JSON formatting. Please ensure your code is correctly formatted before submitting a pull request. If you're unclear about how to correctly format your code just look at existing code base for inspiration.
When you think your code is ready for review create a pull request within GitHub. Maintainers of the repository will watch out for new PR‘s and review them in regular intervals.
By default, for each change in the PR will automatically trigger pytests, Serverless AWS deployment via Travis CI as well as a code quality review via Codacy. If either Travis CI or Codacy fails make sure to address the failures immediately.
If comments have been given in a review, they have to get integrated. For those changes a separate commit should be created and pushed to your remote development branch. Don’t forget to add a comment in the PR afterward, so everyone gets notified by GitHub. Keep in mind that reviews can span multiple cycles until the maintainers are happy with the code.