ci: Add docker image automated deploy and PR building

[FoxxMD]

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:

• On commit to main branch => published to dockerhub/ghcr latest tag
• On commit to any other branch (must explicitly be listed in workflow yaml) => publish to published to dockerhub/ghcr yourBranchName tag
• On release => published to dockerhub/ghcr using release tag Ie 1.0.1

To enable

• Go to repository settings -> secrets and variables -> actions
  • Add repository secrets
    • DOCKER_USERNAME - your dockerhub username
    • DOCKER_PASSWORD - your dockerhub password
  • Add repository variables
    • DOCKERHUB_IMAGE_NAME - the full name of the dockerhub image IE neede4swede/portall
    • GHCR_IMAGE_NAME - the full name of the GHCR image IE ghcr.io/neede4swede/portall
    • If neither of the above variables are included then the job will not run
• Go to repository settings -> Actions -> General
  • Action permissions -> Allow all actions...
  • Workflow permissions -> Read and write permissions
  • Save

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 dockerhub pr[issueNumber] EX pr152 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 label safe 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 with

ARG APP_BUILD_VERSION
ENV APP_VERSION=$APP_BUILD_VERSION

And then reference APP_VERSION env within your app to get the version like:

• On tag release => 1.0.1
• On branch build featureBranch-088d063
• On PR pr152-088d063

[lilkidsuave]

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.

[FoxxMD]

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.

[lilkidsuave]

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).

[FoxxMD]

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/**'

😄