Code on Spinnaker

Releasing A Patch

Mon, 01 Jan 0001 00:00:00 +0000

Say you’ve written a patch, and it’s been merged into Spinnaker. First off, thanks for helping the project! Odds are, you want to deploy this patch to the Spinnaker you manage. You have a few options available:

Wait for the non-patch release

Any time we release a new minor version of Spinnaker (e.g. 1.16.0 or 1.17.0), we include all commits merged into main for each service. We do this on a quarterly basis by default.

Code Languages, Libraries, and Conventions

Mon, 01 Jan 0001 00:00:00 +0000

Spinnaker is a collection of microservices built from a common foundation which has evolved over time. You do not need to know all of the technologies listed to contribute. Please consider these standards and conventions when submitting pull requests to Spinnaker.

Languages

Spinnaker is comprised of JVM backend-services and a frontend application (Deck). See an overview of the architecture in our reference documentation.

Use the following languages to fix and extend Spinnaker services:

Managing Deprecations

Mon, 01 Jan 0001 00:00:00 +0000

Deprecating old functionality is key to making Spinnaker easier to maintain, but it needs to be done in a way that is as non-disruptive as possible.

Pull Requests and Changes

Mon, 01 Jan 0001 00:00:00 +0000

Change Process

Once you’ve implemented a bug fix or feature, it’s time to submit a pull request to Spinnaker. We recommend small, well-tested pull requests as a starting point for new technical contributors. For information on the correct fork-and-PR GitHub workflows to follow when contributing, reference the local clone guide.

To work on bigger technical changes, follow the feature proposal or RFC processes.

Pull Request Tips

Check that your title describes your changes and adheres to our message conventions .
Add inline code comments to changes that might not be obvious.
Squash your commits into logically reviewable chunks when you first submit your PR. Address feedback in follow-up (unsquashed) commits. It’s much easier to review incremental changes to feedback when the commits are kept separate.
All pull requests should get reviewed by at least one other member of the Spinnaker organization before merging. (While some members of the organization have access to merge without a review, this should only be done in an emergency or when merging a large series of dependency bumps across repositories.)
Squash your commits when merging to the branch.

Commit and PR message conventions

Please follow conventions below in your git commit messages. Since GitHub auto-fills Pull Request titles from the first commit message of the PR, following these conventions should help to title your PRs according to our community standards.