If you encounter any problems with
tripleo-quickstart or if you have
feature suggestions, please feel free to open a bug report in our issue
tracker. Please add the tag
“quickstart” to the bug.
Before submitting code to Gerrit you should do at least some minimal local
testing, like running
tox -e linters. This could be automated if you
activate pre-commit hooks:
pip install --user pre-commit # to enable automatic run on commit: pre-commit install --install-hooks # to uninstall hooks pre-commit uninstall
Please note that the pre-commit feature is available only on repositories that do have .pre-commit-config.yaml file.
tox -e linters is recommended as it may include additional linting
commands than just pre-commit. So, if you run tox you don’t need to run
Implementation of pre-commit is very fast and saves a lot of disk space because internally it does cache any linter-version and reuses it between repositories, as opposed to tox which uses environments unique to each repository (usually more than one). Also by design pre-commit always pins linters, making less like to break code because linter released new version.
Another reason why pre-commit is very fast is because it runs only on modified files. You can force it to run on the entire repository via pre-commit run -a command.
Upgrading linters is done via
pre-commit autoupdate but this should be
done only as a separate change request.
If you fix a problem or implement a new feature, you may submit your
changes via Gerrit. The
tripleo-quickstart project uses the
You can anonymously clone the repository via
git clone https://opendev.org/openstack/tripleo-quickstart.git
If you wish to contribute, you’ll want to get setup by following the documentation available at How To Contribute.
Developers are encouraged to install pre-commit in order to auto-perform a minimal set of checks on commit.
Once you’ve cloned the repository using your account, install the
tool, then from the
tripleo-quickstart repository run:
git review -s
After you have made your changes locally, commit them to a feature branch, and then submit them for review by running:
Your changes will be tested by our automated CI infrastructure, and will
also be reviewed by other developers. If you need to make changes (and
you probably will; it’s not uncommon for patches to go through several
iterations before being accepted), make the changes on your feature
branch, and instead of creating a new commit, amend the existing
commit, making sure to retain the
Change-Id line that was placed
git ci --amend
After committing your changes, resubmit the review: