Thank you for your interest in contributing to Lula! We welcome all contributions and are grateful for your help. This guide outlines how to get started with contributing to this project.
Please follow our Code of Conduct to maintain a respectful and collaborative environment.
- Repository: https://github.com/defenseunicorns/lula/
- Go Binaries: https://github.com/defenseunicorns/lula/releases
- Required Go version:
>=1.22.0
- Fork the repository.
- Clone your fork locally:
git clone https://github.com/your-username/lula.git
. - Create a new branch for your feature or fix:
git checkout -b my-feature-branch
.
- Create an Issue: For significant changes, please create an issue first, describing the problem or feature proposal. Trivial fixes do not require an issue.
- Commit Your Changes: Make your changes and commit them. All commits must be signed. For help follow this guide.
- Run Tests: Ensure that your changes pass all tests by running
go test
for each required test. - Push Your Branch: Push your branch to your fork on GitHub.
- Create a Pull Request: Open a pull request against the
main
branch of the lula repository. Please make sure that your PR passes all CI checks.
- PRs must be against the
main
branch. - PRs must pass CI checks.
- All commits must be signed.
- PRs should have a related issue, except for trivial fixes.
- Include tests that fail without your code, and pass with it.
- Update the code comments, documentation, and examples: whatever is affected by your contribution.
Automated tests will begin based on the paths you have edited in your Pull Request.
The exception to the automated tests are fuzzing tests, which run nightly.
- Run E2E tests:
make test
- Run
make build
and wait for completion. - Change to the lula directory:
cd bin/lula
. - You can now run any of the
lula
commands.
The decision for processes and docs on how-to can be found in adr/
or in docs/
.
We've chosen to use ADRs to document architecturally significant decisions. We primarily use the guidance found in this article by Michael Nygard with a couple of tweaks:
- The criteria for when an ADR is needed is undefined. The team will decide when the team needs an ADR.
- We will use the tool adr-tools to make it easier on us to create and maintain ADRs.
- We will keep ADRs in the repository under
adr/NNNN-name-of-adr.md
.adr-tools
is configured with a dotfile to automatically use this directory and format.
# Create a new ADR titled "Use Bisquick for all waffle making"
adr new Use Bisquick for all waffle making
# Create a new ADR that supersedes a previous one. Let's say, for example, that the previous ADR about Bisquick was ADR number 9.
adr new -s 9 Use scratch ingredients for all waffle making
# Create a new ADR that amends a previous one. Let's say the previous one was ADR number 15
adr new -l "15:Amends:Amended by" Use store-bought butter for all waffle making
# Get full help docs. There are all sorts of other helpful commands that help manage the decision log.
adr help
For any questions or concerns, please open an issue on GitHub or contact the maintainers.