f6d7df9 ("ci: select only correct targz for rootfs build") builds the
rootfs archive name with ${TARGET//\//-}, but the heredoc generating
the build args is single-quoted, so the substitution never happens.
The literal openwrt-${TARGET_TAG}-rootfs.tar.gz then reaches setup.sh.
grep finds no match, leaving file_name empty and causing the
verification to check the entire sha256sums file. Every rootfs job
has since failed with "12414 listed files could not be read".
Expand the target tag in the shell before generating the args, while
keeping DOWNLOAD_FILE as a pattern: release branches embed the
version and revision in the filename, and malta/be has a -default-
profile infix. The pattern must also exclude targz- image variants.
Verified to match exactly one file for all eight rootfs targets on
both snapshots and releases/24.10-SNAPSHOT.
Make setup.sh fail loudly when the pattern matches nothing instead of
producing the misleading checksum error.
The job is triggered whenever a new target is uploaded. This happens the same
moment the CDN cache is flushed, so it's possible that there is a flaky
situation where the CDN is half way through purging the cache.
Unify the variables for the upstream URL, in Dockerfile it's called FILE_HOST,
in the setup.sh it's called UPSTREAM_URL. Use FILE_HOST everywhere but fallback
to UPSTREAM_URL if defined.
Let's use our own mirror for this.
Signed-off-by: Paul Spooren <mail@aparcar.org>
This hides the download progress but is still more verbose then quiet.
This should help not to pollute the logs when downloading the sdk with progress info.
Signed-off-by: Tom Herbers <mail@tomherbers.de>
Currently the container initial setup using setup.sh fails:
rm: cannot remove '/builder/keys/88CA59E8.asc': Permission denied
rm: cannot remove '/builder/keys/CD54E82DADB3684D.asc': Permission denied
rm: cannot remove '/builder/keys/2074BE7A.asc': Permission denied
rm: cannot remove '/builder/keys/0x1D53D1877742E911.asc': Permission denied
rm: cannot remove '/builder/keys/626471F1.asc': Permission denied
That is happening due to PEBKAC, where I didn't realized, that there is
such additional setup.sh happening. So lets fix it by adding the keys
with correct owner.
Link: https://github.com/openwrt/docker/pull/165
References: https://github.com/openwrt/packages/actions/runs/14242829383/job/39916509620?pr=26225Fixes: #164
Fixes: 79999f3c7e ("Dockerfile: fix rootfs container generation")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Currently several rootfs containers are failing to build, as the
buildbot user doesn't exists in those FROM:scratch containers:
/usr/bin/docker buildx build (snip) --build-arg USER=root --build-arg BASE_IMAGE=scratch (snip)
...snip...
#2 [1/5] ADD --chown=buildbot:buildbot keys/*.asc /builder/keys/
#2 ERROR: invalid user index: -1
So lets fix it by avoiding need for ownership and simply import the keys
through pipe. Move the gpg key import into setup.sh script as well,
since this is the place where the keys are being used.
Also add a new Dockerfile.rootfs that must be used to generate a rootfs
container as the generic Dockerfile is not able to build the rootfs image.
Fixes: 9b55784b18 ("BREAKING: use setup.sh instead of Dockerfile")
References: https://github.com/openwrt/routing/pull/1107#issuecomment-2768156513
References: https://github.com/openwrt/docker/actions/runs/14165468179/job/39681375639#step:9:243
Link: https://github.com/openwrt/docker/pull/161
Acked-by: Paul Spooren <mail@aparcar.org>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Instead of causing infinite amounts of traffic per day, only ship a
preconfigured setup.sh file with SNAPSHOT containers and ask the
downstream user to run `setup.sh` on their own.
Signed-off-by: Paul Spooren <mail@aparcar.org>
Josef Schlehofer
Paul Spooren
Tom Herbers
Petr Štetiar