Difference between revisions of "StarlingX/CodeSubmissionGuidelines"
Ghada.khalil (talk | contribs) m |
Ghada.khalil (talk | contribs) |
||
| Line 2: | Line 2: | ||
* Use Gerrit for StarlingX code reviews | * Use Gerrit for StarlingX code reviews | ||
| + | * Follow the Openstack Git Commit Good Practice [[GitCommitMessages|here]] | ||
* Add the core reviewers for the affected sub-project to the review | * Add the core reviewers for the affected sub-project to the review | ||
** The core reviewers are listed on each sub-project wiki pages. The list of sub-projects is available [[StarlingX#StarlingX_Projects|here]] | ** The core reviewers are listed on each sub-project wiki pages. The list of sub-projects is available [[StarlingX#StarlingX_Projects|here]] | ||
| Line 9: | Line 10: | ||
** For traceability, always link your code change to a story or bug. Gerrit will update the status of the story/bug automatically once the code is merged. | ** For traceability, always link your code change to a story or bug. Gerrit will update the status of the story/bug automatically once the code is merged. | ||
** Linking to StoryBoard Stories: Specify the story and task ID in the commit message as follows: | ** Linking to StoryBoard Stories: Specify the story and task ID in the commit message as follows: | ||
| − | + | *** Story: $story_id | |
| − | + | *** Task: $task_id | |
| − | Example: https://review.openstack.org/#/c/590083/ | + | *** Example: https://review.openstack.org/#/c/590083/ |
** Linking to Launchpad Bugs: Specify the Bug ID in the commit message as follows: | ** Linking to Launchpad Bugs: Specify the Bug ID in the commit message as follows: | ||
| − | + | *** Closes-Bug: $bug_id -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced. | |
| − | Example: https://review.openstack.org/596305 | + | *** Partial-Bug: $bug_id -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed. |
| + | *** Related-Bug: $bug_id -- use 'Related-Bug' if the commit is merely related to the referenced bug. | ||
| + | *** If a fix requires multiple commits, use "Partial-Bug" with only the final commit using "Closes-Bug" | ||
| + | *** Example: https://review.openstack.org/596305 | ||
* Pre-Submission / Pre-Gerrit Testing | * Pre-Submission / Pre-Gerrit Testing | ||
** At a minimum, make sure the code builds and runs | ** At a minimum, make sure the code builds and runs | ||
Revision as of 22:14, 28 September 2018
StarlingX Code Submission Guidelines
- Use Gerrit for StarlingX code reviews
- Follow the Openstack Git Commit Good Practice here
- Add the core reviewers for the affected sub-project to the review
- The core reviewers are listed on each sub-project wiki pages. The list of sub-projects is available here
- All code changes must be pushed to master first and then cherry-picked to the appropriate release branch as needed
- Exception: Feature branches used during development
- Link your code change to a StoryBoard Story or Launchpad Bug
- For traceability, always link your code change to a story or bug. Gerrit will update the status of the story/bug automatically once the code is merged.
- Linking to StoryBoard Stories: Specify the story and task ID in the commit message as follows:
- Story: $story_id
- Task: $task_id
- Example: https://review.openstack.org/#/c/590083/
- Linking to Launchpad Bugs: Specify the Bug ID in the commit message as follows:
- Closes-Bug: $bug_id -- use 'Closes-Bug' if the commit is intended to fully fix and close the bug being referenced.
- Partial-Bug: $bug_id -- use 'Partial-Bug' if the commit is only a partial fix and more work is needed.
- Related-Bug: $bug_id -- use 'Related-Bug' if the commit is merely related to the referenced bug.
- If a fix requires multiple commits, use "Partial-Bug" with only the final commit using "Closes-Bug"
- Example: https://review.openstack.org/596305
- Pre-Submission / Pre-Gerrit Testing
- At a minimum, make sure the code builds and runs
- Verify basic functional testing on a builtISO (ensure the new code get executed)
- Include automated unit tests when applicable. As we build out the Zuul infrastructure, those tests will run per merge
- If needed, consult with the component core reviewers for any required/recommended testing.
- Code reviewers should ask about testing details as part of the gerrit code inspection.
