This document provides guidelines for contributing to the CloudBees CD/RO add-on for Amazon EKS blueprints.
Validate your changes inside the blueprint agent, as described in Dockerfile. For example, it can be used to run make dBuildAndRun
.
CloudBees welcomes you to use the GitHub issue tracker to report bugs or suggest features.
When filing an issue:
- Check existing open and recently closed issues to ensure the issue has not already been reported.
- Review the upstream repositories:
- Try to include as much information as you can. Details like the following are incredibly useful:
- A reproducible test case or series of steps
- The version of code being used
- Any modifications you have made relevant to the bug
- Anything unusual about your environment or deployment
Contributions via pull requests are appreciated. Before submitting a pull request, please ensure that you:
- Are working against the latest source on the
main
branch. - Check existing open, and recently merged, pull requests to make sure someone else has not already addressed the problem.
- Open an issue to discuss any significant work; we do not want your time to be wasted.
To submit a pull request:
- Fork the repository.
- Create a feature branch based on the
main
branch. - Modify the source and focus on the specific change you are contributing. For example, if you reformat all the code, it is hard for reviewers to focus on your specific change.
- Ensure that local tests pass. Local tests can be orchestrated via the companion Makefile.
- Make commits to your fork using clear commit messages.
- Submit a pull request against the
main
branch and answer any default questions in the pull request interface. - Pay attention to any automated failures reported in the pull request, and stay involved in the conversation.
Important
If you make updates to the embedded repository, you must push the changes to the public upstream (repository/branch) before running terraform apply
locally. The endpoint and/or branch can be updated via the companion Makefile.
Many of the files in the repository can be linted or formatted to maintain a standard of quality. Additionally, secret leaks are watched via gitleaks and git-secrets.
- When working with the repository for the first time, you must install
pre-commit
. For more information, refer to pre-commit installation. - Run
pre-commit run --all-files
. Run this command again if the automated checks fail when you create a pull request.
This repository uses Release Drafter. Therefore, it is recommended that you use Semantic Commit Messages to label your pull requests accordingly.