[Bug]: Docker images not yet updating

[saschafoerster]

What happened?

I was trying to upgrade to 3.0.8 via docker hub:

version: '3.3'
services:
    tallyarbiter:
        ports:
            - '4455:4455'
        volumes:
            - /home/tallyarbiter/volume:/app/config
        environment:
            - APPDATA=/app/config
        restart: unless-stopped
        image: josephdadams/tallyarbiter:latest

Latest working version is
image: josephdadams/tallyarbiter:v3.0.1

Latest update on docker hub:
https://hub.docker.com/r/josephdadams/tallyarbiter
2 years ago.

Would be lovely if this could be fixed. :)

Version

3.0.8

Distribution

Docker

OS

Linux

What browsers are you seeing the problem on?

No response

If applicable, What Listener Clients are You Using?

No response

TallyArbiter configuration

No response

Relevant log output

tallyarbiter-1  | node:internal/modules/cjs/loader:936
tallyarbiter-1  |   throw err;
tallyarbiter-1  |   ^
tallyarbiter-1  | 
tallyarbiter-1  | Error: Cannot find module '/app/node_modules/bcrypt/lib/binding/napi-v3/bcrypt_lib.node'
tallyarbiter-1  | Require stack:
tallyarbiter-1  | - /app/node_modules/bcrypt/bcrypt.js
tallyarbiter-1  | - /app/_helpers/auth.js
tallyarbiter-1  | - /app/_helpers/config.js
tallyarbiter-1  | - /app/index.js
tallyarbiter-1  |     at Function.Module._resolveFilename (node:internal/modules/cjs/loader:933:15)
tallyarbiter-1  |     at Function.Module._load (node:internal/modules/cjs/loader:778:27)
tallyarbiter-1  |     at Module.require (node:internal/modules/cjs/loader:1005:19)
tallyarbiter-1  |     at require (node:internal/modules/cjs/helpers:102:18)
tallyarbiter-1  |     at Object.<anonymous> (/app/node_modules/bcrypt/bcrypt.js:6:16)
tallyarbiter-1  |     at Module._compile (node:internal/modules/cjs/loader:1103:14)
tallyarbiter-1  |     at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
tallyarbiter-1  |     at Module.load (node:internal/modules/cjs/loader:981:32)
tallyarbiter-1  |     at Function.Module._load (node:internal/modules/cjs/loader:822:12)
tallyarbiter-1  |     at Module.require (node:internal/modules/cjs/loader:1005:19) {
tallyarbiter-1  |   code: 'MODULE_NOT_FOUND',
tallyarbiter-1  |   requireStack: [
tallyarbiter-1  |     '/app/node_modules/bcrypt/bcrypt.js',
tallyarbiter-1  |     '/app/_helpers/auth.js',
tallyarbiter-1  |     '/app/_helpers/config.js',
tallyarbiter-1  |     '/app/index.js'
tallyarbiter-1  |   ]
tallyarbiter-1  | }
tallyarbiter-1 exited with code 0

Error stacktrace (if applicable)

No response

[josephdadams]

Idk why the docker builds are failing. Feel free to look into it…

[saschafoerster]

@josephdadams I have no real clue, but I think, what ChatGPT is saying sounds quite reasonable:

The error seems to be related to the conditional expressions in the 'tags' and 'push' fields of your workflows. Your setup assumes that every push will be tied to a Git tag, but that isn't always the case. For instance, when you push a new commit to a branch, it doesn't usually come with a tag. Hence the Docker image has no version or tag to apply to the build.

In your case, the image gets tagged or pushed only if the github.ref starts with 'refs/tags/v'. However, this doesn't happen when you push to a branch, only when pushing a tag, causing the "No Docker tag has been generated" warning.

A potential solution would be:

Allow every branch and commit to create a Docker image with a defaulted tag. Providing a fallback tag for non-tagged commits is often considered good practice. Using the commit SHA could serve as a unique fallback tag. So instead of the ''latest'' tag, which is commonly used and could lead to problems, you can use the commit SHA as a unique tag.
Reserve a specified tag name like 'latest' to a successful push to the main branch.
Both steps would look like this:

# ...
  - name: Get Docker meta
    id: meta
    uses: docker/metadata-action@v5
    with:
      images: josephdadams/tallyarbiter
      tags: |
        type=ref,event=tag  # Keeping your current tag type when a tag is pushed
        type=sha,prefix=commit-,format=long  # The fallback unique tag using commit SHA
        type=ref,event=branch  # A new tag type only when the branch is 'main'
      flavor: |
        latest=false
# ...

This guarantees that every push will have a fallback tag.

However, in this modification, every push to every branch will now create and push a Docker image, which can consume your CI resources quickly. Therefore, you might want to regulate this by limiting which branch or event should trigger the workflow. The 'on:' field can be tuned to achieve this.

Finally, note the 'id: meta' line – it means you can refer to the Docker action metadata in subsequent steps (e.g., labelling) via 'steps.meta.outputs.'. Make sure it's used correctly.

[hrueger]

Actually, that's probably not the problem. The workflow should only run on tags, so only for released versions and not for every commit to main.
I think we instead need to fix this: https://github.com/josephdadams/TallyArbiter/actions/runs/7966242233/job/21747159093

[josephdadams]

Yeah @hrueger is correct. The actual workflow doesn't finish for some reason. I am in the process of adjusting when the workflows should run (on release) but that won't solve why it doesn't finish...

[Jocke4f]

Is this related to linux/arm/v6 or is it only a coincidence since it is the last platform in the list?

[josephdadams]

I’m really not sure. Let’s try running it again and see what happens. I’ll do that now.

[saschafoerster]

@josephdadams As far as I can see it run successfully, but it couldn't be pushed to docker hub, as there is some tag problem again.

[josephdadams]

It's the multiarch build that fails and that one seems to only run on tags. Idk very much about this obviously.

[josephdadams]

I found out it was related to docker and QEMU, the emulation layer for the various architectures, causing npm to hang up, hence the jobs never finish. Rolled back node from v20 to v18 and it worked...

docker/build-push-action#1071

[josephdadams]

Oh I also had to drop s390x support to get it to build. Idk why.

[Jocke4f]

Good that it worked in the manual run with node-version: 18. It is odd that we state minimum 18.13 to install TallyArbiter but build it with 20.

One thing that has been nagging me is that in docker.yml @master is used instead of specific releases on, e.g., docker/setup-qemu-action@master.

[josephdadams]

Specifying specific releases would be better. I support fixing this.