Project: Pinniped (Provisioning / Key Management)
File: CONTRIBUTING.md

Pinniped is better because of our contributors and . It is because of you that we can bring great software to the community. Contributions to Pinniped are welcome. Here are some things to help you get started. Please see the . See for some guidelines about what we consider in and out of scope for Pinniped. The near-term and mid-term roadmap for the work planned for the project is documented in . Got a question, comment, or idea? Please don't hesitate to reach out via GitHub , GitHub , or in the Kubernetes Slack Workspace within the . Join our to receive updates and meeting invitations. Need an idea for a project to get started contributing? Take a look at the open . Also check to see if any open issues are labeled with or . To file a bug report, please first open an . The project team will work with you on your bug report. Once the bug has been validated, a can be opened to fix the bug. For specifics on what to include in your bug report, please follow the guidelines in the issue and pull request templates. To suggest a feature, please first open an and tag it with `proposal`, or create a new . The project will work with you on your feature request. Once the feature request has been validated, a can be opened to implement the feature. For specifics on what to include in your feature request, please follow the guidelines in the issue and pull request templates. Please follow the procedure described in . We welcome contributions from everyone, but we can only accept them if you sign our Contributor License Agreement (CLA). If you would like to contribute and you have not signed it, our CLA-bot will walk you through the process when you open a Pull Request. For questions about the CLA process, see the or submit a question through the GitHub issue tracker. New to Pinniped? Start here to learn how to install and use Pinniped: Start here to learn how to navigate the source code: Other more detailed documentation can be found at: The at the root of the repo can be used to build and package the server-side code. After making a change to the code, rebuild the docker image with the following command. ```bash docker build . ``` The Pinniped CLI client can be built for local use with the following command. ```bash go build -o pinniped ./cmd/pinniped ``` ```bash ./hack/module.sh lint ``` ```bash

units ``` Install dependencies: - `htpasswd` (installed by default on MacOS, usually found in `apache2-utils` package for linux) - - - (installed by default on MacOS) On macOS, these tools can be installed with (assuming you have Chrome installed already): ```bash brew install kind vmware-tanzu/carvel/ytt vmware-tanzu/carvel/kapp kubectl nmap && brew cask install docker ``` Create a kind cluster, compile, create container images, and install Pinniped and supporting test dependencies using: ```bash ./hack/prepare-for-integration-tests.sh ``` Run the Pinniped integration tests: ```bash ulimit -n 512 && source /tmp/integration-test-env && go test -v -count 1 -timeout 0 ./test/integration ``` To run specific integration tests, add the `-run` flag to the above command to specify a regexp for the test names. Use a leading `/` on the regexp because the Pinniped integration tests are automatically nested under several parent tests (see ). For example, to run an integration test called `TestE2E`, add `-run /TestE2E` to the command shown above. After making production code changes, recompile, redeploy, and run tests again by repeating the same commands described above. If there are only test code changes, then simply run the tests again. To destroy the local Kubernetes cluster, run `./hack/kind-down.sh`. It can sometimes be convenient to use GoLand to run an integration test. For example, this allows using the GoLand debugger to debug the test itself (not the server, since that it running in-cluster). Note that the output of `hack/prepare-for-integration-tests.sh` says: ```bash ``` After using `hack/prepare-for-integration-tests.sh`, run `hack/integration-test-env-goland.sh | pbcopy` as instructed. Then: Select and run an integration test within GoLand. It will fail complaining about missing env vars. Pull down the menu that shows the name of the test which you just ran in the previous step, and choose "Edit Configurations...". In the "Environment" text box for the run configuration of the integration test that you just ran, paste the results of `hack/integration-test-env-goland.sh | pbcopy`. Apply, and then run the integration test again. This time the test will use the environment variables provided. Note that if you run `hack/prepare-for-integration-tests.sh` again, then you may need to repeat these steps. Each run of `hack/prepare-for-integration-tests.sh` can result in different values for some of the env vars. will not be triggered on a pull request until the pull request is reviewed and approved for CI by a project . Once CI is triggered, the progress and results will appear on the Github page for that as checks. Links will appear to view the details of each check. Any pull request which adds a new feature or changes the behavior of any feature which was previously documented should include updates to the documentation. All documentation lives in this repository. This project aspires to follow the Kubernetes . This project uses to agree on some conventions about whitespace/file encoding. ```bash $ brew install pre-commit [...] $ pre-commit install pre-commit installed at .git/hooks/pre-commit ``` Regular contributors who are active in the Pinniped community and who have contributed at least several significant pull requests may be considered for promotion to become a maintainer upon request. Please contact an existing if you would like to be considered.