Fixes #10673. Signed-off-by: Rick Wieman <git@rickw.nl>
3.4 KiB
page_title: Coding style checklist page_description: List of guidelines for coding Docker contributions page_keywords: change, commit, squash, request, pull request, test, unit test, integration tests, Go, gofmt, LGTM
Coding style checklist
This checklist summarizes the material you experienced working through make a code contribution and advanced contributing. The checklist applies to both program code and documentation code.
Change and commit code
-
Fork the
docker/docker
repository. -
Make changes on your fork in a feature branch. Name your branch
XXXX-something
whereXXXX
is the issue number you are working on. -
Run
gofmt -s -w file.go
on each changed file before committing your changes. Most editors have plug-ins that do this automatically. -
Update the documentation when creating or modifying features.
-
Commits that fix or close an issue should reference them in the commit message
Closes #XXXX
orFixes #XXXX
. Mentions help by automatically closing the issue on a merge. -
After every commit, run the test suite and ensure it is passing.
-
Sync and rebase frequently as you code to keep up with
docker
master. -
Set your
git
signature and make sure you sign each commit. -
Do not add yourself to the
AUTHORS
file. This file is autogenerated from the Git history.
Tests and testing
-
Submit unit tests for your changes.
-
Make use of the builtin Go test framework built.
-
Use existing Docker test files (
name_test.go
) for inspiration. -
Run the full test suite on your branch before submitting a pull request.
-
Run
make docs
to build the documentation and then check it locally. -
Use an online grammar checker or similar to test you documentation changes for clarity, concision, and correctness.
Pull requests
-
Sync and cleanly rebase on top of Docker's
master
without multiple branches mixed into the PR. -
Before the pull request, squash your commits into logical units of work using
git rebase -i
andgit push -f
. -
Include documentation changes in the same commit so that a revert would remove all traces of the feature or fix.
-
Reference each issue in your pull request description (
#XXXX
)
Respond to pull requests reviews
-
Docker maintainers use LGTM (looks-good-to-me) in PR comments to indicate acceptance.
-
Code review comments may be added to your pull request. Discuss, then make the suggested modifications and push additional commits to your feature branch.
-
Incorporate changes on your feature branch and push to your fork. This automatically updates your open pull request.
-
Post a comment after pushing to alert reviewers to PR changes; pushing a change does not send notifications.
-
A change requires LGTMs from an absolute majority maintainers of an affected component. For example, if you change
docs/
andregistry/
code, an absolute majority of thedocs/
and theregistry/
maintainers must approve your PR.
Merges after pull requests
-
After a merge, a master build is available almost immediately.
-
If you made a documentation change, you can see it at docs.master.dockerproject.com.