Fix firmware release workflow: docker cp instead of a bind-mount

The runner's job workspace lives in a named Docker volume, not a real
host path, so a nested docker run -v "\$PWD:/workspace" bind-mounted an
empty directory when talking to the host daemon (which has no notion of
paths inside the calling container) -- build_for_board.sh: No such file
or directory. docker create/cp/start streams the checkout into the
build container through the Docker API instead, which works regardless
of what backs either side's workspace.
This commit is contained in:
2026-07-21 21:35:30 -04:00
parent 9e630c0c6e
commit ecc5b8d197
+31 -18
View File
@@ -19,10 +19,11 @@ jobs:
# the job specifies, so checkout fails immediately with "node: not
# found" (hit this on the first real run). Checkout instead runs on the
# plain runner (which has Node), and only the two build steps below
# spin up the ESP-IDF image themselves via `docker run` -- the runner
# already bind-mounts the host's docker socket, so docker-in-docker
# works fine from an ordinary run: step (same mechanism the existing
# server-docker-build.yml relies on for docker buildx).
# spin up the ESP-IDF image themselves (docker create/cp/start, see the
# comment on those steps for why not a plain `docker run -v`) -- the
# runner already bind-mounts the host's docker socket, so docker-in-
# docker works fine from an ordinary run: step (same mechanism the
# existing server-docker-build.yml relies on for docker buildx).
runs-on: ubuntu-latest
steps:
- name: Checkout
@@ -39,33 +40,45 @@ jobs:
# set-target first since a fresh checkout has no cached sdkconfig
# (firmware/sdkconfig* is gitignored, see firmware/.gitignore).
# safe.directory guards against git's "dubious ownership" check,
# since the container runs as root over a volume owned by the
# runner's host user; idf.py shells out to git for component/
# version bookkeeping even though the embedded app version itself
# comes from version.txt, not git describe.
# since the container runs as root over content owned by a
# different uid.
#
# Deliberately `docker create`/`docker cp`/`docker start`, NOT
# `docker run -v "$PWD:/workspace"` -- the runner's own job
# workspace lives in a named Docker volume, not a real host path
# (confirmed from a failed run's container-inspect output), so a
# nested `docker run` bind-mounting "$PWD" talks to the *host*
# daemon about a path that only means something inside this job's
# own container -- it silently bind-mounted an empty directory,
# hence "build_for_board.sh: No such file or directory". `docker
# cp` streams files through the Docker API instead, so it works
# regardless of what backs either side's workspace.
- name: Build (devkit -- ESP32-C6-DevKitC-1)
run: |
docker run --rm -v "$PWD:/workspace" -w /workspace/firmware espressif/idf:release-v5.3 bash -c '
mkdir -p /tmp/release-assets
cid=$(docker create -w /workspace/firmware espressif/idf:release-v5.3 bash -c '
git config --global --add safe.directory /workspace &&
. "$IDF_PATH/export.sh" &&
./build_for_board.sh devkit set-target esp32c6 &&
./build_for_board.sh devkit build
'
')
docker cp "$PWD/." "$cid:/workspace"
docker start -a "$cid"
docker cp "$cid:/workspace/firmware/build/espresso_frame.bin" /tmp/release-assets/firmware-devkit.bin
docker rm "$cid"
- name: Build (xiao -- Seeed XIAO ESP32-C6)
run: |
docker run --rm -v "$PWD:/workspace" -w /workspace/firmware espressif/idf:release-v5.3 bash -c '
cid=$(docker create -w /workspace/firmware espressif/idf:release-v5.3 bash -c '
git config --global --add safe.directory /workspace &&
. "$IDF_PATH/export.sh" &&
./build_for_board.sh xiao set-target esp32c6 &&
./build_for_board.sh xiao build
'
- name: Collect binaries
run: |
mkdir -p /tmp/release-assets
cp firmware/build/espresso_frame.bin /tmp/release-assets/firmware-devkit.bin
cp firmware/build_xiao/espresso_frame.bin /tmp/release-assets/firmware-xiao.bin
')
docker cp "$PWD/." "$cid:/workspace"
docker start -a "$cid"
docker cp "$cid:/workspace/firmware/build_xiao/espresso_frame.bin" /tmp/release-assets/firmware-xiao.bin
docker rm "$cid"
# Plain stdlib urllib rather than `requests` -- not guaranteed to be
# pip-installed in the IDF image, and this is simple enough not to