Contributing

By participating in the Cinc Project community, you agree to abide by our Code of Conduct. For security issues, see our Security Policy before opening a public issue.

Where to contribute

Where a contribution belongs depends on whether the Cinc project in question is a branding-only rebuild or a maintained fork.

Branding-only rebuilds (Cinc Client, Cinc Auditor, Cinc Server until 16.0.0)

These projects sync directly with their upstream Chef repositories — only branding constants and trademark-sensitive strings change. Because the source tracks upstream:

  • Code changes should be sent upstream to the relevant repository under the Chef GitHub organization. Once merged upstream, they automatically flow into the next Cinc rebuild.
  • Build, packaging, and pipeline changes are Cinc-specific and belong in the corresponding build repo under cinc-project/distribution (e.g. distribution/client, distribution/auditor).

We have design documents on many upstream Chef repos describing how trademark constants are factored out via dist.rb — anyone can read and open pull requests upstream to extend that pattern.

Maintained forks (Cinc Workstation, Cinc Server 16.0.0+, supporting libraries)

These are true forks where the Cinc Project maintains the source ourselves — typically because the upstream build infrastructure has been retired. Contributions of all kinds are welcome directly on the Cinc fork: bug fixes, dependency upgrades, security patches, platform support, even features. Open an MR on the relevant repo under cinc-project/distribution or one of the library forks under cinc-project/upstream.

If you’re unsure which category a project falls into, check its default branch on GitLab — forks use main, branding-only rebuilds use stable/cinc on top of the upstream main/master.

Build pipelines

Our build and release processes should be 100% automated — that means pipelines. If you can improve them, open an MR against the relevant build repo under cinc-project/distribution.

⚠️
Heads up: our CI pipelines are currently wired to runners that are specific to our own repositories, so CI doesn’t work well on merge requests opened from personal forks. We hope to fix this eventually — please bear with us if your pipeline doesn’t run. A maintainer can usually rerun the pipeline from the Cinc-side after a quick review.

Where our code lives

The Cinc Project’s source of truth is GitLab. All issues, merge requests, CI, and active development happen there.

We also maintain a read-only mirror on GitHub for discoverability — people searching GitHub for “Cinc” should still find us. Please don’t open issues or PRs on GitHub — they won’t be seen by maintainers. File everything on GitLab instead.

Group layout on GitLab

The GitLab group is organised into two subgroups, each with a specific role:

  • cinc-project/distribution — repositories specific to the Cinc Project itself. These hold our forks and the build scripts for the branding-only rebuilds (Cinc Client, Cinc Auditor, Cinc Server, Cinc Workstation, etc.). If you want to fix something in a Cinc binary or pipeline, this is where to look.
  • cinc-project/upstream — mirrors of upstream code that we rebase Cinc patches on top of. This lets us pin to a known-good upstream state and apply our trademark / branding fixes without relying on the upstream repository remaining available. We don’t develop new features here.

Feedback

Staying compliant with the Chef trademark policy requires vigilance from all users. If you see something user-facing that could violate the policy please open an issue in the relevant Cinc repository, or alternatively submit a fix directly upstream.

Similarly, we appreciate feedback on our packaging and distribution methods. If you find those inadequate let us know how we could improve them on Gitlab.