infra: Docker images with version tags not being published because of failing builds #1104

New Issue

2025-11-11T14:37:34-06:00

GiteaMirror commented

2025-11-11 14:37:34 -06:00

Originally created by @DavidZidar on GitHub (Jun 2, 2024).

Bug Report

Description

Bug Summary:
I tried pulling ghcr.io/open-webui/open-webui:0.2.0 but it doesn't exist and neither does v0.2.1 because these builds are failing with the error ERROR: registry cache exporter requires ref when docker buildx build is being run.

Logs and Screenshots

v0.2.0
https://github.com/open-webui/open-webui/actions/runs/9335788157

v0.2.1 (same error)
https://github.com/open-webui/open-webui/actions/runs/9341217307

Installation Method

Docker

Additional Information

The command line in the logs does indeed seem to be missing the ref value because two of the command line args look like this.
--cache-from type=registry,ref= --cache-to type=registry,ref=,mode=max

Originally created by @DavidZidar on GitHub (Jun 2, 2024). # Bug Report ## Description **Bug Summary:** I tried pulling `ghcr.io/open-webui/open-webui:0.2.0` but it doesn't exist and neither does v0.2.1 because these builds are failing with the error `ERROR: registry cache exporter requires ref` when `docker buildx build` is being run. ## Logs and Screenshots v0.2.0 https://github.com/open-webui/open-webui/actions/runs/9335788157 v0.2.1 (same error) https://github.com/open-webui/open-webui/actions/runs/9341217307 ## Installation Method Docker ## Additional Information The command line in the logs does indeed seem to be missing the ref value because two of the command line args look like this. `--cache-from type=registry,ref= --cache-to type=registry,ref=,mode=max`

GiteaMirror added the help wanted label 2025-11-11 14:37:34 -06:00

GiteaMirror closed this issue

2025-11-11 14:37:34 -06:00

GiteaMirror commented

2025-11-11 14:37:35 -06:00

@DavidZidar commented on GitHub (Jun 2, 2024):

Immediately after submitting this issue I noticed PR #2737 which may be fixing this issue, the images still need to be published though.

@DavidZidar commented on GitHub (Jun 2, 2024): Immediately after submitting this issue I noticed PR #2737 which may be fixing this issue, the images still need to be published though.

GiteaMirror commented

2025-11-11 14:37:35 -06:00

@tjbck commented on GitHub (Jun 2, 2024):

One way to find out 😂

@tjbck commented on GitHub (Jun 2, 2024): One way to find out 😂

GiteaMirror commented

2025-11-11 14:37:35 -06:00

@DavidZidar commented on GitHub (Jun 2, 2024):

I spent the last 30 minutes trying to make sense of these build steps, but I have never used these docker actions before and find the documentation lacking so take this info with a grain of salt.

But looking at the logs it seems that one of the build steps failed because latest was used for caching, The PR #2737 solves this by setting latest to false in the flavor input which seems correct.

However, it seems to me like type=ref,event=tag should still be used, and I can't figure out what ${{ github.ref_type == 'tag' && 'type=raw,value=main' || '' }} is supposed to be doing. That said, you might be able to omit the tags part entirely because it uses these values by default:

tags: |
  type=schedule
  type=ref,event=branch
  type=ref,event=tag
  type=ref,event=pr

Or maybe you could use semver type=semver,pattern={{version}}.

So maybe like this since you run that workflow for both branches main and dev as well as for semver tags, but at this point I'm guessing:

tags: |
  type=ref,event=branch
  type=semver,pattern={{version}}

@DavidZidar commented on GitHub (Jun 2, 2024): I spent the last 30 minutes trying to make sense of these build steps, but I have never used these docker actions before and find the documentation lacking so take this info with a grain of salt. But looking at the logs it seems that one of the [build steps](https://github.com/open-webui/open-webui/actions/runs/9341217307/job/25707735163#step:9:157) failed because `latest` was used for caching, The PR #2737 solves this by setting latest to false in the [flavor](https://github.com/docker/metadata-action?tab=readme-ov-file#flavor-input) input which seems correct. However, it seems to me like `type=ref,event=tag` should still be used, and I can't figure out what `${{ github.ref_type == 'tag' && 'type=raw,value=main' || '' }}` is supposed to be doing. That said, you might be able to omit the `tags` part entirely because it uses these values by default: ```yaml tags: | type=schedule type=ref,event=branch type=ref,event=tag type=ref,event=pr ``` Or maybe you could use [semver](https://github.com/docker/metadata-action?tab=readme-ov-file#typesemver) `type=semver,pattern={{version}}`. So maybe like this since you run that workflow for both branches `main` and `dev` as well as for semver tags, but at this point I'm guessing: ```yaml tags: | type=ref,event=branch type=semver,pattern={{version}} ```

GiteaMirror commented

2025-11-11 14:37:35 -06:00

@not-a-ethan commented on GitHub (Jun 3, 2024):

@justinh-rahb can I ask why you closed this issue? This still appears to be an issue with the latest commit to both the main and dev branches failing tests and when I try and install it goes back to 0.1.124

@not-a-ethan commented on GitHub (Jun 3, 2024): @justinh-rahb can I ask why you closed this issue? This still appears to be an issue with the latest commit to both the main and dev branches failing tests and when I try and install it goes back to 0.1.124

GiteaMirror commented

2025-11-11 14:37:35 -06:00

@justinh-rahb commented on GitHub (Jun 3, 2024):

can I ask why you closed this issue? This still appears to be an issue with the latest commit to both the main and dev branches failing tests and when I try and install it goes back to 0.1.124

Alright @not-a-ethan, re-opened. Got anything to add? We have a v0.2.2 tag now, so I took that to mean the issue was resolved.

@justinh-rahb commented on GitHub (Jun 3, 2024): > can I ask why you closed this issue? This still appears to be an issue with the latest commit to both the main and dev branches failing tests and when I try and install it goes back to 0.1.124 Alright @not-a-ethan, re-opened. Got anything to add? We have a `v0.2.2` tag now, so I took that to mean the issue was resolved.

GiteaMirror commented

2025-11-11 14:37:36 -06:00

@DavidZidar commented on GitHub (Jun 3, 2024):

I just pulled the image with version tag 0.2.2 and it seems to be working fine here.

@DavidZidar commented on GitHub (Jun 3, 2024): I just pulled the image with version tag 0.2.2 and it seems to be working fine here.

GiteaMirror commented

2025-11-11 14:37:36 -06:00

@not-a-ethan commented on GitHub (Jun 3, 2024):

@justinh-rahb @DavidZidar That could be the issue. I am pulling from :main instead of :0.2.2. Currently pulling, dont have great wifi right now so going to take a little bit.

@not-a-ethan commented on GitHub (Jun 3, 2024): @justinh-rahb @DavidZidar That could be the issue. I am pulling from `:main` instead of `:0.2.2`. Currently pulling, dont have great wifi right now so going to take a little bit.

GiteaMirror commented

2025-11-11 14:37:36 -06:00

@not-a-ethan commented on GitHub (Jun 3, 2024):

@justinh-rahb @DavidZidar Didnt work, still 0.1.124. I ran sudo docker ps -a and sudo docker images -a and nothing shows up for either. Then I run these and nothing is updated

sudo docker pull ghcr.io/open-webui/open-webui:0.2.2
sudo docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:0.2.2

@not-a-ethan commented on GitHub (Jun 3, 2024): @justinh-rahb @DavidZidar Didnt work, still 0.1.124. I ran `sudo docker ps -a` and `sudo docker images -a` and nothing shows up for either. Then I run these and nothing is updated ```bash sudo docker pull ghcr.io/open-webui/open-webui:0.2.2 sudo docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:0.2.2 ```

GiteaMirror commented

2025-11-11 14:37:37 -06:00

@justinh-rahb commented on GitHub (Jun 3, 2024):

You must have some very aggressive caching going on then... try ensuring you've cleared any possible cached copies.

@justinh-rahb commented on GitHub (Jun 3, 2024): You must have some very aggressive caching going on then... try ensuring you've cleared any possible cached copies. ![Screenshot 2024-06-03 at 2 20 31 PM](https://github.com/open-webui/open-webui/assets/52832301/3d4d22a3-c892-45bb-9005-77b833c0da74) ![Screenshot 2024-06-03 at 2 25 00 PM](https://github.com/open-webui/open-webui/assets/52832301/2e847634-9821-43f6-8b2b-5f5f3161d2c2)

GiteaMirror commented

2025-11-11 14:37:37 -06:00

@not-a-ethan commented on GitHub (Jun 3, 2024):

@justinh-rahb That weird, I forgot about the site and cleared all cached items in my browser (FF dev edition) and its still 0.1.124. I run sudo docker ps -a and sudo docker images -a and they both show it being 0.2.2.

@not-a-ethan commented on GitHub (Jun 3, 2024): @justinh-rahb That weird, I forgot about the site and cleared all cached items in my browser (FF dev edition) and its still 0.1.124. I run `sudo docker ps -a` and `sudo docker images -a` and they both show it being `0.2.2`. ![image](https://github.com/open-webui/open-webui/assets/92686703/8609dcc0-7254-40de-a19f-7610929fa88d)

GiteaMirror commented

2025-11-11 14:37:37 -06:00

@not-a-ethan commented on GitHub (Jun 3, 2024):

With some more experimentation I relised its a different issue (I think). I removed all of the open web ui stuff and closed my WSL terminal (and quit everything in task manager), forgot locatlhost:8080 and cleared cache. Then I refreshed the page and I got Unable to Connect (expected). Opened my WSL terminal and I could access localhost:8080 again without running any commands.
I ran ps aux and I dont see anything that has open-webui or anything along the name of that. I do have some other docker stuff though (see below)

USER        PID  %CPU %MEM    VSZ        RSS             TTY  STAT   START   TIME COMMAND
root         277  0.1       0.5          2801196 93012         ?       Ssl  15:46   0:00       /usr/bin/dockerd -H fd:// --containerd=/run/containerd/conta
root        1344  0.0      0.0          1156276 5252           ?       Sl   15:46   0:00       /snap/docker/2915/bin/docker-proxy -proto tcp -host-ip 0.0.0
root        1351  0.0      0.0          1230008 7132           ?       Sl   15:46   0:00       /snap/docker/2915/bin/docker-proxy -proto tcp -host-ip :: -h
root        1366  0.0      0.0          719564  9788           ?        Sl   15:46   0:00      /snap/docker/2915/bin/containerd-shim-runc-v2 -namespace mob

@not-a-ethan commented on GitHub (Jun 3, 2024): With some more experimentation I relised its a different issue (I think). I removed all of the open web ui stuff and closed my WSL terminal (and quit everything in task manager), forgot `locatlhost:8080` and cleared cache. Then I refreshed the page and I got `Unable to Connect` (expected). Opened my WSL terminal and I could access `localhost:8080` again without running any commands. I ran `ps aux` and I dont see anything that has `open-webui` or anything along the name of that. I do have some other docker stuff though (see below) ```bash USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 277 0.1 0.5 2801196 93012 ? Ssl 15:46 0:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/conta root 1344 0.0 0.0 1156276 5252 ? Sl 15:46 0:00 /snap/docker/2915/bin/docker-proxy -proto tcp -host-ip 0.0.0 root 1351 0.0 0.0 1230008 7132 ? Sl 15:46 0:00 /snap/docker/2915/bin/docker-proxy -proto tcp -host-ip :: -h root 1366 0.0 0.0 719564 9788 ? Sl 15:46 0:00 /snap/docker/2915/bin/containerd-shim-runc-v2 -namespace mob ```

GiteaMirror commented

2025-11-11 14:37:38 -06:00

@justinh-rahb commented on GitHub (Jun 3, 2024):

Alright it seems clear now your issue is unrelated to this thread, and the original poster seems to have had their issue resolved to their satisfaction. I'm closing this again, but please open a thread in the Discussions area or jump into our Discord #troubleshooting channel if you would like more assistance.

@justinh-rahb commented on GitHub (Jun 3, 2024): Alright it seems clear now your issue is unrelated to this thread, and the original poster seems to have had their issue resolved to their satisfaction. I'm closing this again, but please open a thread in the Discussions area or jump into our Discord #troubleshooting channel if you would like more assistance.

GiteaMirror commented

2025-11-11 14:37:38 -06:00