Contributions to dockerfiles are welcome.
Feel free to use all of the contribution options:
In general, MRs are welcome. We follow the typical "fork-and-pull" Git flow.
-
Fork the repo on GitLab
-
Clone the project to your own machine
-
Commit changes to your own branch using Git flow
-
Push your work back up to your fork
-
Submit a Pull Request so that we can review your changes
NOTE: Be sure to rebase the latest changes from "upstream" before making a pull request!
Your commit messages should serve these 3 important purposes:
- To speed up the reviewing process.
- To provide the least amount of necessary documentation
- To help the future maintainers.
Follow Conventional Commits to make git log
{.interpreted-text role="command"} a little easier to follow. We use commitlint enforcing conventional commits (See more here)
chore: something just needs to happen, e.g. versioning
docs: documentation pages in docs/
or docstrings
feat: new code in ./
fix: code improvement in ./
refactor: code movement in ./
style: aesthetic changes
test: test case modifications in test/
Examples commit messages:
- chore: IN-698 implement model devices
- docs: IN-698 implement configuration settings
- feat: IN-698 create lambda function
- fix: IN-698 retry upload on failure
- refactor: IN-698 extract duplicate code
- style: IN-698 format files python
- test: IN-698 coverage around add permissions
Keep it short and simple!
See Git flow.
Documentation is a part of the dockerfiles code base. You can find the documentation files in the doc/
subdirectory of the main repository. This means that the contribution process is the same for both the source code and documentation.
See Testing.
- See if a Pull Request exists
- Add some comments or review the code to help it along
- Don't be afraid to comment when logic needs clarification
- Create a Fork and open a Pull Request if needed
- Anyone can review code
- Any Pull Request should be closed or merged within a week
Try to keep history as linear as possible using a [rebase] merge strategy.