Added a github workflow to automatically build and publish the latest from the main branch to docker hub.

[nothingmn]

Sample github workflow to automatically publish to dockerhub. I suspect you may need to change it to the docker host and repository of choice vs docker hub.

I tested this locally and it works fine.

Here is the output in my repo:
https://github.com/nothingmn/ebook2audiobook/actions/runs/12644758022

Give it a try, via:

docker run -it --rm -p 7860:7860 robchartier/ebook2audiobook

Under the repository settings, secrets and variables, actions, two new repository secrets will need to be created:
DOCKER_USERNAME
DOCKER_PASSWORD

Both with the value from the remote docker repository on your account.

Cheers.

[DrewThomasson]

Hm

[DrewThomasson]

So im a bit new to this stuff

will this remotly automatically rebuild the docker image every time the repo is updated?

or is this just simplifying the build and push command when rebuilding the docker to the latest on my computer locally?

[DrewThomasson]

Cause the Dockerfile build is a bit.... resource and time intensive as it includes a test run to make the base model and such baked into it

U know for simplicity when people pull it, makes everything just work, faster

[DrewThomasson]

I feel like if it does it automatically all the time then ill run out of the free github build resources?

Or I'm not reading the fine-print correctly on this? 😅

@nothingmn

[nothingmn]

It is a sample github workflow (see here for more info: https://www.geeksforgeeks.org/github-workflows/)

This workflow:

https://github.com/DrewThomasson/ebook2audiobook/blob/df25f971cb884dc3af3d36508d9bd314bb0c9dcc/.github/workflows/docker_build_workflow.yml

GitHub workflows are a way to automate tasks for your project directly on GitHub. Think of them as a set of instructions that tell GitHub what to do whenever certain things happen, like when you push code or make a pull request. These workflows are part of GitHub Actions, a tool that helps you automate processes like building, testing, or deploying your project.

For your open-source project that builds Docker images, workflows can save you a ton of time and effort. Instead of manually building and uploading your Docker images, you can set up a workflow to automatically do that every time you update your code. This ensures your Docker image is always up-to-date and consistent, making it easier for others to use and contribute to your project.

Here’s what your workflow is doing:

1. Triggering Events:

   • The workflow starts automatically when you push changes to the main branch or create a pull request targeting the main branch.

2. Environment Setup:

   • A job named build runs on an ubuntu-latest virtual machine, which provides a fresh Linux environment for the tasks.

3. Checkout Code:

   • The first step checks out your repository's code so that the virtual machine has access to all the files and code in your project.

4. Docker Login:

   • The workflow logs into Docker Hub (or a container registry) using credentials stored securely in GitHub secrets. This is necessary to build and push Docker images to the registry.

5. Build the Docker Image:

   • The workflow builds your Docker image. It uses the docker build command and adds two tags to the image:
     • latest: Indicates the most recent version.
     • A tag with the Git commit hash (e.g., abcd123), which uniquely identifies the specific version of your code.

6. Push the Docker Image:

   • Finally, the workflow pushes the two tags (latest and commit hash) of your Docker image to the container registry. This makes the image available for others to pull and use.

By automating these steps, your project always has the latest Docker image available, and contributors or users don’t have to build it themselves. This saves time and avoids errors, making your project more efficient and professional.

[DrewThomasson]

.... did you just respond with chatgpt to my hand typed messages to you...

[dawilk]

To answer your questions...
Workflows like this run on GitHub servers unless you host your own runners. You generally wouldn't need to worry about runner minutes unless you have private projects using significant runner time each month. Sounds like you probably aren't using any. This public project can use GitHub Actions for free (because public), as long as you use the default runners (e.g. ubuntu-latest). So this workflow is fine for all that.

However, I wouldn't use this workflow as-is. You likely only want to publish on merges to main, and this is building and publishing on both main and PRs. The latter is a security and reliability risk. If you drop the on.pull_request, that risk goes away. It's also not caching image layers (you might want it to since you said the build takes a long time).

It also looks like it was written by an LLM that wasn't aware there are newer action versions.

[ROBERT-MCDOWELL]

what's your interest to advertise this kind of tools?

[dawilk]

what's your interest to advertise this kind of tools?

I use GitHub Actions every day for work. Building and publishing a container image for community use like this is a very common use-case. I would just put some additional functionality on it. Caching. Automatic semver using conventional commits. And maybe split the workflow or use additional image tagging logic to support multiple channels (e.g. latest, stable). There are other actions that help with determining next version, manage metadata and tags, and multi-arch images.

I'm a proponent of fully automatic versions and releases with tests/validations on PRs.

[ROBERT-MCDOWELL]

this is not an answer to my question. I ask again,
what's your interest to advertise your tools to OUR repo?

[dawilk]

I'm not sure I follow, but I'm not interested in advertising anything here.

I just happened to be looking at issues and PRs here for an unrelated reason (Apple Silicon problems). Since I use GitHub Actions heavily for personal and work projects, I commented on this PR.

[ROBERT-MCDOWELL]

and if I tell you we prefer to not automate everything?

[DrewThomasson]

It's built into GitHub for free I don't think its advertising 😓

[DrewThomasson]

@dawilk Sorry about that,

The team has just been scarred by a bunch of other people doing advertising in our PR's 😅

Is there a way to make the automated workflow only do a new docker build when we make a new version release?

And give it the Version as the docker image tag?

If so then I would be VERY interested in an automated docker build. I'm just afraid of making the latest release automated ( Cause sometimes we might make an update that breaks something and I want the dockerImage:latest to be imume to those kind of things 😅 )

[DrewThomasson]

@dawilk

Just read your message more in depth :)

So how would I modify the existing workflow example here to make it do auto-tagging for each and only for the version releases?
(now I realize you did say it was possible with "tagging logic" and such in it) 😅

like I want the automated docker images created with eh version tag for each version we release, But also still be able to have manual control over the latest tag as that would be the "stable" image? 🤔 :)

[dawilk]

To make it only release on tags and manual builds, you could set triggers to something like this:

on:
  push:
    tags:
      - "[0-9]+.[0-9]+" # change this to list your tag pattern(s)
  workflow_dispatch: # this one is for doing manual builds

and then the build command that applies tags should account for whether its a manual run or a tag run, and set image tags accordingly.

However, you can shortcut manual tag logic in the workflow by using docker/metadata-action. In fact, I would just take a look at the usage section on the metadata action and you may be able to copy-paste their Basic example to meets your needs exactly. Just trim the triggers to the ones mentioned above.

I use the docker metadata and build-push actions all the time with more complex tagging strategies as well as pushing to multiple registries (GHCR, ECR, Docker Hub). You can do a lot with them.

If you want to be able to change latest tag to a prior version for stability reasons, then I'd just do a separate workflow (something like "set-latest-to-tag.yaml") with an input for tag, and then just have it pull an existing tag, add latest to the tags, and push it (no rebuild).

I probably could have just suggested changes on the PR instead of typing all this. 🤔

[ROBERT-MCDOWELL]

ok guys, open a disccussion to continue this topic. it has nothing to do in the PR section. thanks

[DrewThomasson]

sorry my bad

We can continue this conversation at this GitHub discussion here
#237