Contributing to the SPIFFE Project
The change management process for the SPIFFE Project is designed to be transparent, fair, and efficient. Anyone may contribute to a project in the SPIFFE repositories that they have read access to, provided they:
- Abide by the CNCF code of conduct
- Can certify the clauses in the Developer Certificate of Origin (DCO)
To get started:
- First, README to become familiar with how the SPIFFE Project is managed
- Make sure you're familiar with our Coding Conventions when appropriate
If you're new to the SPIFFE Project, we recommend that you join us on the mailing lists and Slack to discuss any potential changes you'd like to see made.
If your proposal comes under the purview of a SIG, reach out to the SIG lead and seek their feedback first (bugfixes and changes with minor impact don't need this). The SIG lead may refer you to the broader group.
Sending a pull request
- Fork the repo
- Commit changes to your fork
- Update the docs, if necessary
- Ensure your branch is based on the latest commit in
- Ensure all tests pass (see project docs for more information)
- Make sure your commit messages contain a
Signed-off-by: <your-email-address>line (see
git-commit --signoff) to certify the DCO
- Open a pull request
against the upstream
All changes to SPIFFE projects must be code reviewed in a pull request (this goes for everyone, even those who have merge rights).
After your pull request is submitted
Pull requests are approved according to the process described in our governance policies. At least one maintainer must approve the pull request, and for large changes, another independent reviewer must approve it too.
Once your pull request is submitted, it's your responsibility to:
- Respond to reviewer's feedback
- Keep it merge-ready at all times until it has been approved and actually merged
Following approval, the pull request will be merged by the last maintainer to approve the request.
Generally, these are the coding conventions SPIFFE projects should follow. Maintainers will consider these conventions when reviewing pull requests.
- Command-line flags should use dashes, not underscores
- Plugin and API protobuf comments are expected to be accompanied with markdowns generated with protoc-gen-doc
- All documentation and code must conform to the Inclusive Naming Initiative guidelines
- All filenames should be lowercase
- Source filenames and directories should use underscores, no dashes (snake case)
- Document filenames and directories should use dashes rather than underscores (kebab case)
- Most significant functionality must come with unit tests
- Significant features should have integration and/or end-to-end tests
- Unit tests should be fully hermetic. Only access resources in the test binary
- Concurrent unit test runs must pass
When third-party code must be included, all licenses must be preserved. This includes modified third-party code and excerpts, as well.
Repositories and Licenses
All repositories under this project should include:
- A detailed
README.mdwhich includes a link back to this file
LICENSEfile with the Apache 2.0 license
- A CODEOWNERS file listing the maintainers