GitHub Actions to automatically run black/isort/autoflake and build docker image #31
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a GitHub action to automatically run black, isort & autoflake (leveraging
pre-commit
) and than builds a docker image pushed to Github Container Registry.This expands on #23 but instead uses https://pre-commit.com/index.html The advantages, when you have pre-commit installed and then do
pre-commit install
in your local repository, then all these checks are run automatically for each commit locally, thus you always submit the code which would pass GH action "lint" And you can easily add any additional hooks if needed, e.g. markdown lint for Readme.mdFor the Docker image publishing, I suggest slightly adjusting the process, where:
dev
branch becomes the default branch, where all the PRs are getting merged and all the development is done. Whenever a PR is merged intodev
branch, a new docker image is built and published withdev
tag into GitHub Container Registrymaster
branch becomes a "version history" branch, where push a PR from the dev branch, when ready to make a new release. Thus, themaster
branch essentially always has the "stable" and working version of the app. When ready to publish a "stable" version after the PR intomaster
in merged, then you "publish" and tag a release in GitHub. This would cause the docker image with the same tag to be published into registry, which also becomes thelatest
docker image tag.if you accept this PR, then I can rebase the #30 later, as they are likely to cause merge conflicts.
++ @bertybuttface for visibility