Open FoxxMD opened 3 months ago
Instead of On Push, Workflow dispatch should be used to prevent accidental breakage on a stable branch. On a dev branch, On push is fine, but might break peoples image.
That's reasonable but really up to the author. I have good commit discipline in my projects and don't commit to main
unless im cutting a release and have never had an issue with deploying accidentally.
That's reasonable but really up to the author. I have good commit discipline in my projects and don't commit to
main
unless im cutting a release and have never had an issue with deploying accidentally.
And thats how I think it should be somewhat as well. But in my limited experience with docker stuff, (and lower discipline) I usually workflow dispatch to test new changes, and sometimes it breaks something and I have to revert. On push spams the workflow unless you also have the one at a time setting. Editing a Readme doesn't require a build.
Sorry for the tangent, TLDR I agree with you, I just do things a bit different (and loose).
Understandable...if the author would prefer that I can remove (or they can edit) the push -> branches to remove main
or add dev branches. The workflow already has workflow_dispatch
so that's good to go.
Editing a Readme doesn't require a build.
True and also why the workflow includes
paths-ignore:
- '**.md'
- '.github/**'
:smile:
To use the github actions workflow to deploy automatically to dockerhub and github packages
All below builds are cross-platform for x86/ARM.
On Push
Triggers on these actions and publishes accordingly:
main
branch => published to dockerhub/ghcrlatest
tagyourBranchName
tagtag
Ie1.0.1
To enable
DOCKER_USERNAME
- your dockerhub usernameDOCKER_PASSWORD
- your dockerhub passwordDOCKERHUB_IMAGE_NAME
- the full name of the dockerhub image IEneede4swede/portall
GHCR_IMAGE_NAME
- the full name of the GHCR image IEghcr.io/neede4swede/portall
On PR
The same settings apply as above except only for dockerhub for security considerations when using
pull_request_trigger
so that the action does not need repo write permissions.When a PR targeting
main
opened it will be built and published to dockerhubpr[issueNumber]
EXpr152
and a comment with a link to the built image will be made in the PR. However this only happens if the PR has the labelsafe to test
so you have a chance to review PR for malicious changes to github actions workflow or other things.The docker build action is also provided a build arg
APP_BUILD_VERSION
that could be used by your application to display the built version based on tag or branch or pr...modify you Dockerfile withAnd then reference
APP_VERSION
env within your app to get the version like:1.0.1
featureBranch-088d063
pr152-088d063