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.md
For 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 into dev branch, a new docker image is built and published with dev tag into GitHub Container Registry
master branch becomes a "version history" branch, where push a PR from the dev branch, when ready to make a new release. Thus, the master branch essentially always has the "stable" and working version of the app. When ready to publish a "stable" version after the PR into master 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 the latest docker image tag.
if you accept this PR, then I can rebase the #30 later, as they are likely to cause merge conflicts.
This is better than my approach. I also now know how to use Home Assistant ingress properly with relative URLs so I can update the Home Assistant Addon and get this working properly too.
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