{"__v":2,"_id":"58b70a1a8ba5251900804a18","category":{"project":"55c6bec1b9aa4e0d0016c2c3","version":"55c6bec1b9aa4e0d0016c2c6","_id":"5734fafd146eb82000597261","__v":0,"sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-05-12T21:51:57.060Z","from_sync":false,"order":6,"slug":"development","title":"Development"},"project":"55c6bec1b9aa4e0d0016c2c3","user":"56e097457e2c420e008da356","version":{"__v":8,"_id":"55c6bec1b9aa4e0d0016c2c6","project":"55c6bec1b9aa4e0d0016c2c3","createdAt":"2015-08-09T02:45:21.683Z","releaseDate":"2015-08-09T02:45:21.683Z","categories":["55c6bec2b9aa4e0d0016c2c7","56c14bc5826df10d00e82230","56cceed8723ad71d00cae46c","56ccf29a431ada1f00e85aae","56ccf3c28fa8b01b00b82018","56ce1e6ee538330b0021ac5d","56f97e9a4c612020008f2eaf","5734fafd146eb82000597261"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1.0"},"updates":["58b70d33eeacc63b0049371c","58f71eafb87fcc0f0041f4c6"],"next":{"pages":[],"description":""},"createdAt":"2017-03-01T17:51:22.671Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"## Before You Begin\nWe prefer small, well tested pull requests.\n\nPlease refer to [Contributing to Spinnaker](http://spinnaker.io/online_docs/community/contributing_guidelines.html) and [On Collaborative Development](http://spinnaker.io/documentation/collab_dev.html).\n\nPlease follow the following conventions in your git commit messages.\n\n## Commit Message Conventions\n\nOnce you've implemented a bug fix or feature, it's time to submit a patch to Spinnaker. In order to track and summarize the changes happening in Spinnaker, we use a changelog automation tool called [clog](https://github.com/clog-tool/clog-cli) which scrapes information from commit messages. We follow the ['conventional'](https://github.com/conventional-changelog/conventional-changelog/blob/a5505865ff3dd710cf757f50530e73ef0ca641da/conventions/angular.md) commit message format.\n\nAs a summary, messages should be formatted like:\n\n```\n<type>(<scope>): <subject>\n<empty line>\n<body>\n<empty line>\n<footer>\n```\n\n#### Type\n\nType | Purpose\n--------|------------\nfeat | A new feature. Please also link to the issue (in the body) if applicable. Causes a minor version bump.\nfix | A bug fix. Please also link to the issue (in the body) if applicable.\ndocs | A documentation change.\nstyle | A code change that does not affect the meaning of the code, (e.g. indentation).\nrefactor | A code change that neither fixes a bug or add a feature.\nperf | A code change that improves performance.\ntest | Adding missing tests.\nchore | Changes to build process or auxiliary tools or libraries such as documentation generation.\nconfig | Changes to configurations that have tangible effects on users, (e.g. renaming properties, changing defaults, etc).\n\nThe type of keyword affects the next semantic version bump. The `feat` keyword causes a minor version bump, while the rest of the keywords cause a patch version bump. Major version bumps are triggered by the presence of the words `BREAKING CHANGE` in the _commit message body_. This is covered more in [Body](#section-body).\n\nIf you _don't_ use one of the previous types (or don't follow the convention), your commit will not be included in the generated changelog. Your change will still affect the next semantic version bump, but it will be considered a patch change, not a major or minor change (even if the change is a breaking change or a feature).\n\nIf you submit a pull request with multiple commits and choose to *Squash and Merge* the pull request, the individual commit messages **are not** added to the changelog, **only the pull request message is**. To include each commit in your pull request in the changelog and next version calculation, *merge the changes without squashing*.\n\n#### Scope\n\nThe `scope` of the commit message indicates the area or feature of Spinnaker the commit applies to. For instance, if you were to submit a patch to the Google provider in Clouddriver, your commit message might look something like:\n\n```\nfeat(provider/google): Updated forwarding rule schema.\n```\n\nor if you submit a fix pertaining to authentication in Gate:\n\n```\nfix(authN): Fixed session authentication coherence.\n```\n\nThe `scope` is purposefully left open-ended, but try to group similar changes using the same value. Changes that have the same `scope` will be grouped together during changelog generation:\n\n**Features**\n* Some_scope\n  - First feature goes here.\n  - Second feature goes here.\n\n#### Subject\n\nThe `subject` should be a short summary of the patch.\n\n#### Body\n\nThe `body` should include any detailed information about the patch; however, these can also go in the pull request body.\n\n#### Footer\n\nAny information about breaking changes should be present in the footer. To signify a breaking change, add one line at the end of the commit message with 'BREAKING CHANGE' in the line:\n\n```\nfeat(provider/google): Added a very important and breaking feature.\n\nBREAKING CHANGE: More detail here if necessary.\n```\n\nNote that at minimum, 'BREAKING CHANGE' must be specified on the last line. The extra detail is not mandatory.\n\n## When you initiate a Pull Request from Github\n\n* Provide a descriptive title for your changes.\n* Add inline code comments to changes that might not be obvious.\n* Squash your commits as you keep adding changes.\n* Add a comment to :::at:::spinnaker/reviewers for review if your issue has been outstanding for more than 3 days. \n\nNote that we are unlikely to accept pull requests that add features without prior discussion. The best way to propose a feature is to open an issue first and discuss your ideas there before implementing them.","excerpt":"","slug":"how-to-submit-a-patch","type":"basic","title":"How to submit a patch"}

How to submit a patch


## Before You Begin We prefer small, well tested pull requests. Please refer to [Contributing to Spinnaker](http://spinnaker.io/online_docs/community/contributing_guidelines.html) and [On Collaborative Development](http://spinnaker.io/documentation/collab_dev.html). Please follow the following conventions in your git commit messages. ## Commit Message Conventions Once you've implemented a bug fix or feature, it's time to submit a patch to Spinnaker. In order to track and summarize the changes happening in Spinnaker, we use a changelog automation tool called [clog](https://github.com/clog-tool/clog-cli) which scrapes information from commit messages. We follow the ['conventional'](https://github.com/conventional-changelog/conventional-changelog/blob/a5505865ff3dd710cf757f50530e73ef0ca641da/conventions/angular.md) commit message format. As a summary, messages should be formatted like: ``` <type>(<scope>): <subject> <empty line> <body> <empty line> <footer> ``` #### Type Type | Purpose --------|------------ feat | A new feature. Please also link to the issue (in the body) if applicable. Causes a minor version bump. fix | A bug fix. Please also link to the issue (in the body) if applicable. docs | A documentation change. style | A code change that does not affect the meaning of the code, (e.g. indentation). refactor | A code change that neither fixes a bug or add a feature. perf | A code change that improves performance. test | Adding missing tests. chore | Changes to build process or auxiliary tools or libraries such as documentation generation. config | Changes to configurations that have tangible effects on users, (e.g. renaming properties, changing defaults, etc). The type of keyword affects the next semantic version bump. The `feat` keyword causes a minor version bump, while the rest of the keywords cause a patch version bump. Major version bumps are triggered by the presence of the words `BREAKING CHANGE` in the _commit message body_. This is covered more in [Body](#section-body). If you _don't_ use one of the previous types (or don't follow the convention), your commit will not be included in the generated changelog. Your change will still affect the next semantic version bump, but it will be considered a patch change, not a major or minor change (even if the change is a breaking change or a feature). If you submit a pull request with multiple commits and choose to *Squash and Merge* the pull request, the individual commit messages **are not** added to the changelog, **only the pull request message is**. To include each commit in your pull request in the changelog and next version calculation, *merge the changes without squashing*. #### Scope The `scope` of the commit message indicates the area or feature of Spinnaker the commit applies to. For instance, if you were to submit a patch to the Google provider in Clouddriver, your commit message might look something like: ``` feat(provider/google): Updated forwarding rule schema. ``` or if you submit a fix pertaining to authentication in Gate: ``` fix(authN): Fixed session authentication coherence. ``` The `scope` is purposefully left open-ended, but try to group similar changes using the same value. Changes that have the same `scope` will be grouped together during changelog generation: **Features** * Some_scope - First feature goes here. - Second feature goes here. #### Subject The `subject` should be a short summary of the patch. #### Body The `body` should include any detailed information about the patch; however, these can also go in the pull request body. #### Footer Any information about breaking changes should be present in the footer. To signify a breaking change, add one line at the end of the commit message with 'BREAKING CHANGE' in the line: ``` feat(provider/google): Added a very important and breaking feature. BREAKING CHANGE: More detail here if necessary. ``` Note that at minimum, 'BREAKING CHANGE' must be specified on the last line. The extra detail is not mandatory. ## When you initiate a Pull Request from Github * Provide a descriptive title for your changes. * Add inline code comments to changes that might not be obvious. * Squash your commits as you keep adding changes. * Add a comment to @spinnaker/reviewers for review if your issue has been outstanding for more than 3 days. Note that we are unlikely to accept pull requests that add features without prior discussion. The best way to propose a feature is to open an issue first and discuss your ideas there before implementing them.