[Bug] container build error: no rule to make target

[sudomateo]

Describe the Bug

The container build on tag v0.2.9 fails with the following output.

> RUNTIME="podman" util/docker_build.sh framework/ansi:default:build
QMK Firmware v0.2.9

Please run `/usr/bin/python3 -m pip install -r /qmk_firmware/requirements.txt` to install required python dependencies.
make: *** No rule to make target 'framework/ansi:default:build'. Stop.
|
| QMK's make format is:
|     make keyboard_folder:keymap_folder[:target]
|
| Where `keyboard_folder` is the path to the keyboard relative to
| `qmk_firmware/keyboards/`, and `keymap_folder` is the name of the
| keymap folder under that board's `keymaps/` directory.
|
| Examples:
|     keyboards/dz60, keyboards/dz60/keymaps/default
|       -> make dz60:default
|       -> qmk compile -kb dz60 -km default
|     keyboards/planck/rev6, keyboards/planck/keymaps/default
|       -> make planck/rev6:default:flash
|       -> qmk flash -kb planck/rev6 -km default
|
ERROR: Cannot run "qmk hello"!

 Please run qmk setup to install all the dependencies QMK requires.

make: *** [Makefile:379: framework/ansi:default:build] Error 1

Here's the commit I used to build.

> git status
HEAD detached at v0.2.9
nothing to commit, working tree clean

> git log -n 1
commit 9388622ff04bd3bd9c5f7ab849c54dd9c7896911 (HEAD, tag: v0.2.9, origin/fl16-v0.2.8-prep)
Author: Daniel Schaefer <dhs@frame.work>
Date:   Thu Dec 14 17:05:11 2023 +0800

    fl16: Bump to v0.2.9

    Signed-off-by: Daniel Schaefer <dhs@frame.work>

Workaround

I successfully built this firmware in the past on another machine so I checked that machine and noticed it was using container image ghcr.io/qmk/qmk_cli@sha256:d8ebfab96c46d3ab948dd4e87be8a976095bd31268700021a74716cbd6e5b4c1. Checking https://github.com/qmk/qmk_cli/pkgs/container/qmk_cli/versions?filters%5Bversion_type%5D=untagged shows that there's been more images published since I last built the firmware. I suspect the changes in recent container images are incompatible with this fork. I updated the code to use the ghcr.io/qmk/qmk_cli@sha256:d8ebfab96c46d3ab948dd4e87be8a976095bd31268700021a74716cbd6e5b4c1 image and everything works.

> RUNTIME="podman" util/docker_build.sh framework/ansi:default:build
QMK Firmware v0.2.9
Making framework/ansi with keymap default and target build

arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiling: keyboards/framework/matrix.c                                                             [OK]
Compiling: platforms/chibios/drivers/analog.c                                                       [OK]
Compiling: keyboards/framework/dyn_serial.c                                                         [OK]
...
Linking: .build/framework_ansi_default.elf                                                          [OK]
Creating UF2 file for deployment: .build/framework_ansi_default.uf2                                 [OK]
Copying framework_ansi_default.uf2 to qmk_firmware folder                                           [OK]

> ls *.uf2
framework_ansi_default.uf2

Here's the diff I used.

diff --git a/util/docker_build.sh b/util/docker_build.sh
index 828b5751af..b158fd8048 100755
--- a/util/docker_build.sh
+++ b/util/docker_build.sh
@@ -81,5 +81,5 @@ fi
        -e ALT_GET_KEYBOARDS=true \
        -e SKIP_GIT="$SKIP_GIT" \
        -e MAKEFLAGS="$MAKEFLAGS" \
-       ghcr.io/qmk/qmk_cli \
+       ghcr.io/qmk/qmk_cli@sha256:d8ebfab96c46d3ab948dd4e87be8a976095bd31268700021a74716cbd6e5b4c1 \
        make "$keyboard${keymap:+:$keymap}${target:+:$target}"
diff --git a/util/docker_cmd.sh b/util/docker_cmd.sh
index 4a82890603..12927c72af 100755
--- a/util/docker_cmd.sh
+++ b/util/docker_cmd.sh
@@ -55,5 +55,5 @@ fi
        $uid_arg \
        -w /qmk_firmware \
        -v "$dir":/qmk_firmware \
-       ghcr.io/qmk/qmk_cli \
+       ghcr.io/qmk/qmk_cli@sha256:d8ebfab96c46d3ab948dd4e87be8a976095bd31268700021a74716cbd6e5b4c1 \
        "$@"

Keyboard Used

framework/ansi

Link to product page (if applicable)

No response

Operating System

Fedora 41

qmk doctor Output

> RUNTIME="podman" util/docker_cmd.sh qmk doctor
Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.1.6
Ψ QMK home: /qmk_firmware
Ψ Detected Linux (Debian GNU/Linux 11 (bullseye)).
⚠ Missing or outdated udev rules for 'atmel-dfu' bo
⚠ Missing or outdated udev rules for 'kiibohd' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'stm32-dfu' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'apm32-dfu' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'gd32v-dfu' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'wb32-dfu' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'bootloadhid' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbasploader' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbtinyisp' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'md-boot' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'caterina' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'hid-bootloader' boards. Run 'sudo cp /qmk_firmware/util/udev/50-qmk.rules /etc/udev/rules.d/'.
Ψ Git branch: HEAD
Ψ Repo version: v0.2.9
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.3.1
Ψ Found avr-gcc version 8.3.0
Ψ Found avrdude version 6.3-20171130
Ψ Found dfu-programmer version 0.6.1
Ψ Found dfu-util version 0.9
Ψ Submodules are up to date.
Ψ Submodule status:
Ψ - lib/chibios: 2023-04-15 13:48:04 +0000 --  (11edb16)
Ψ - lib/chibios-contrib: 2023-07-17 11:39:05 +0200 --  (da78eb3)
Ψ - lib/googletest: 2021-06-11 06:37:43 -0700 --  (
Ψ - lib/lufa: 2022-08-26 12:09:55 +1000 --  (549b973)
Ψ - lib/vusb: 2022-06-13 09:18:17 +1000 --  (819dbc1)
Ψ - lib/printf: 2022-06-29 23:59:58 +0300 --  (c2e3b4e)
Ψ - lib/pico-sdk: 2023-02-12 20:19:37 +0100 --  (a3398d8)
Ψ - lib/lvgl: 2022-04-11 04:44:53 -0600 --  (e19410f)
Ψ QMK is ready to go, but minor problems were found

Other keyboard-related software installed

No response

Additional Context

No response

[TribalNightOwl]

Ran into the same problem trying to build keyball61.

$ util/docker_build.sh keyball/keyball61:TribalNightOwl
QMK Firmware holykeebs-master-latest

Please run `/usr/bin/python3 -m pip install -r /qmk_firmware/requirements.txt` to install required python dependencies.
make: *** No rule to make target 'keyball/keyball61:TribalNightOwl'. Stop.
|
| QMK's make format is:
|     make keyboard_folder:keymap_folder[:target]
|
| Where `keyboard_folder` is the path to the keyboard relative to
| `qmk_firmware/keyboards/`, and `keymap_folder` is the name of the
| keymap folder under that board's `keymaps/` directory.
|
| Examples:
|     keyboards/dz60, keyboards/dz60/keymaps/default
|       -> make dz60:default
|       -> qmk compile -kb dz60 -km default
|     keyboards/planck/rev6, keyboards/planck/keymaps/default
|       -> make planck/rev6:default:flash
|       -> qmk flash -kb planck/rev6 -km default
|
ERROR: Cannot run "qmk hello"!

 Please run qmk setup to install all the dependencies QMK requires.

make: *** [Makefile:402: keyball/keyball61:TribalNightOwl] Error 1

Used the same image as @sudomateo (thanks for the workaround):

# Run container and build firmware
"$RUNTIME" run --rm -it $usb_args \
	$uid_arg \
	-w /qmk_firmware \
	-v "$dir":/qmk_firmware \
	-e ALT_GET_KEYBOARDS=true \
	-e SKIP_GIT="$SKIP_GIT" \
	-e MAKEFLAGS="$MAKEFLAGS" \
	ghcr.io/qmk/qmk_cli@sha256:d8ebfab96c46d3ab948dd4e87be8a976095bd31268700021a74716cbd6e5b4c1 \
	make "$keyboard${keymap:+:$keymap}${target:+:$target}"

and I was able to build again.

 $ util/docker_build.sh keyball/keyball61:TribalNightOwl
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
QMK Firmware holykeebs-master-latest
Making keyball/keyball61 with keymap TribalNightOwl

arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Linking: .build/keyball_keyball61_TribalNightOwl.elf                                                [OK]
Creating UF2 file for deployment: .build/keyball_keyball61_TribalNightOwl.uf2                       [OK]
Copying keyball_keyball61_TribalNightOwl.uf2 to qmk_firmware folder                                 [OK]

[sudomateo]

Thank you for confirming @TribalNightOwl!

I see you're building firmware for the keyball/keyball61 device. Wasn't sure if you were aware but this repository is a fork of qmk/qmk_firmware specifically for Framework devices. You should be able to build the keyball/keyball61 device using qmk/qmk_firmware without this workaround. Perhaps you already knew all that but I figured it couldn't hurt to confirm.

[TribalNightOwl]

Thank you for confirming @TribalNightOwl!

I see you're building firmware for the keyball/keyball61 device. Wasn't sure if you were aware but this repository is a fork of qmk/qmk_firmware specifically for Framework devices. You should be able to build the keyball/keyball61 device using qmk/qmk_firmware without this workaround. Perhaps you already knew all that but I figured it couldn't hurt to confirm.

Thanks for the heads-up @sudomateo. Yes I am aware, in order to build for the keyball61 I had to use a special fork for it (which also got behind from main), basically the same situation you ran into but with a different fork.

[sudomateo]

Thanks for the heads-up @sudomateo. Yes I am aware, in order to build for the keyball61 I had to use a special fork for it (which also got behind from main), basically the same situation you ran into but with a different fork.

Ah that makes sense! Thank you for commenting on this issue and raising awareness. Hopefully someone with more context and/or time will be able to fix it.