Skip to main content
pikopod is pre-v1 and every provider is a new edge case. The most valuable contribution right now is a bug report from a real integration: a provider whose spec is imported badly, a drift that is missed, or a drift that is invented.

Getting help

Please read and follow the code of conduct.

Ways to contribute

  • Report a bug or request a feature.
  • Improve docs, tests, examples, packaging, or platform support.
  • Add support for a spec format or a provider shape pikopod handles poorly.

Submitting a pull request

1

Fork and branch

Create a focused branch. Keep the change scoped to one bug fix, feature, or documentation improvement.
2

Add a failing test first

Add a test that fails before your change and passes after. If you are fixing a bug, the bug should be reproduced first.
3

Leave goldens alone

Do not hand-edit files under testdata/parity/. They are maintainer-regenerated. If your change legitimately moves a golden, say so in the pull request and expect the parity job to be red until a maintainer regenerates it. See Development.
4

Run the suite as CI runs it

5

Commit and sign off

Use conventional commits and sign off with git commit -s. pikopod uses the DCO, not a CLA, so you keep your copyright.
6

Open the pull request

Include a clear summary and a test plan. If you are unsure which checks apply, say so.

Filing an issue

The most useful report includes the provider, the spec you imported, what pikopod said, and what you expected instead. Redact freely: pikopod inspect shows you what is safe to share. For security issues, do not open an issue. See the security policy.