Add docker to stackbrew #3
Conversation
|
I'm definitely a fan of this idea, and would even go so far as to say it is probably worthwhile to create tags of some of the previous docker version tags, too. 👍 Since we don't really have a way to detect changes to the source from stackbrew (as an artifact of the way it runs), I think it would be better if we tagged "latest" to a specific, recent commit so that it can be more easily updated, since the premise of the base images is that they're fairly static targets, but if they do update, there's a PR we can reference for said update, which using a raw commit hash provides very nicely. We should probably also have @shykes chime in on whether or not he minds having docker directly as an official base image. |
|
I think having docker as a base image makes a lot of sense. Agree with @tianon that |
|
I think it's a great idea. Maybe we should call it "dockerdev" to make it clear it's the build environment for docker. Also, you should point to a specific commit or tag instead of HEAD on master, because stackbrew will only build each url once. |
|
Ok @vieux, we have all the votes in. We definitely want this, and I do fully agree that the name "docker" could be misleading and also like "dockerdev" or even "docker-dev". You'll need to update to the new syntax and tag to a specific commit. 👍 |
|
Who will be the maintainer? I think we should not merge anything on On Tue, Nov 5, 2013 at 1:24 PM, Tianon Gravi notifications@github.comwrote:
|
|
Also, will "latest" refer to the closest approximation of master we can get, or will this image only be on release tags? I'd vote for release tags, especially since it's so easy for someone to build their own for "master". |
|
(and that will cause a LOT less churn) |
|
I vote for tags, @tianon do you want to be maintainer of this ? |
|
I'm certainly willing - it'll be pretty low volume. :) |
|
I think every time we add a new tag with a pull request, we may also submit On Tue, Nov 5, 2013 at 1:33 PM, Tianon Gravi notifications@github.comwrote:
|
|
That would be the idea, yes. I'll take this. Want me to take over this whole PR, @vieux? (ie, should we close this?) |
|
go ahead |
https://github.com/elixir-lang/elixir/releases/tag/v1.2.5 and switch to maintain both `erlang:18` based (to be developer friendly) and `erlang:18-slim` based, this should resolve docker-library#3 also resolves docker-library#4
Fix generate stackbrew for onbuild commit ids
New repo is bonita-distrib (community version) New release 7.11.3
We ran into a race condition that we _think_ might be GC related, but we don't want automatic GC generally anyhow so we'll just disable this entirely and keep our eyes open for that race to resurface.
$ printf 'FROM ubuntu:20.04\n' | docker buildx build --builder bashbrew-arm64v8 --output type=oci --build-arg BUILDKIT_SYNTAX=docker/dockerfile:1@sha256:7f44e51970d0422c2cbff3b20b6b5ef861f6244c396a06e1a96f7aa4fa83a4e6 --provenance=mode=max --sbom generator=docker/buildkit-syft-scanner:stable-1@sha256:71c6aab70e25388abf054da2eaaf121727e3a4f464ddfb1987052b83c9419949 --platform linux/arm64/v8 - > oci.tar
#1 [internal] load .dockerignore
#1 transferring context: 2B done
#1 DONE 0.0s
#2 [internal] load build definition from Dockerfile
#2 transferring dockerfile: 55B done
#2 DONE 0.0s
docker-library#3 resolve image config for docker.io/docker/dockerfile:1@sha256:7f44e51970d0422c2cbff3b20b6b5ef861f6244c396a06e1a96f7aa4fa83a4e6
docker-library#3 DONE 0.1s
docker-library#4 docker-image://docker.io/docker/dockerfile:1@sha256:7f44e51970d0422c2cbff3b20b6b5ef861f6244c396a06e1a96f7aa4fa83a4e6
docker-library#4 resolve docker.io/docker/dockerfile:1@sha256:7f44e51970d0422c2cbff3b20b6b5ef861f6244c396a06e1a96f7aa4fa83a4e6 done
docker-library#4 DONE 0.0s
docker-library#4 docker-image://docker.io/docker/dockerfile:1@sha256:7f44e51970d0422c2cbff3b20b6b5ef861f6244c396a06e1a96f7aa4fa83a4e6
docker-library#4 CACHED
docker-library#5 resolve image config for docker.io/docker/buildkit-syft-scanner:stable-1@sha256:71c6aab70e25388abf054da2eaaf121727e3a4f464ddfb1987052b83c9419949
docker-library#5 DONE 0.1s
docker-library#6 [internal] load metadata for docker.io/library/ubuntu:20.04
docker-library#6 DONE 0.6s
docker-library#7 docker-image://docker.io/docker/buildkit-syft-scanner:stable-1@sha256:71c6aab70e25388abf054da2eaaf121727e3a4f464ddfb1987052b83c9419949
docker-library#7 resolve docker.io/docker/buildkit-syft-scanner:stable-1@sha256:71c6aab70e25388abf054da2eaaf121727e3a4f464ddfb1987052b83c9419949 0.0s done
docker-library#7 DONE 0.0s
docker-library#8 [linux/arm64] generating sbom using docker.io/docker/buildkit-syft-scanner:stable-1@sha256:71c6aab70e25388abf054da2eaaf121727e3a4f464ddfb1987052b83c9419949
docker-library#8 CACHED
docker-library#9 [1/1] FROM docker.io/library/ubuntu:20.04@sha256:24a0df437301598d1a4b62ddf59fa0ed2969150d70d748c84225e6501e9c36b9
docker-library#9 resolve docker.io/library/ubuntu:20.04@sha256:24a0df437301598d1a4b62ddf59fa0ed2969150d70d748c84225e6501e9c36b9 0.0s done
docker-library#9 DONE 0.0s
docker-library#10 exporting to oci image format
docker-library#10 exporting layers done
docker-library#10 exporting manifest sha256:7ee27ad7ace5741767778121ad82066c09383c68e462efcfaad124cc074b48a8 0.0s done
docker-library#10 exporting config sha256:b559481b22258f45e33c28e36cab179693b1d6ca1bfa8d7acf2b068cd61d4b39 done
docker-library#10 ERROR: content digest sha256:a774dfcdedc7c7c4f0009ddadc2f33557d60452450684534df5625f9693df81a: not found
------
> exporting to oci image format:
------
ERROR: failed to solve: content digest sha256:a774dfcdedc7c7c4f0009ddadc2f33557d60452450684534df5625f9693df81a: not found
Support for this was implemented in my images back in tianon/dockerfiles@8c85466 as a PoC (and support for it was kept in tianon/dockerfiles@2b78191 when the explicit 0.13 builds were added), and I've actually been using it pretty heavily since without issue, both locally *and* for all of my `tianon/xxx` personal image builds (including building of `tianon/buildkit` itself, for maximum meta 😂). The primary benefit is that we get the exact same architecture support matrix as our BuildKit images (and the same set of applied patches, if they happen to impact the frontend code as well). $ docker buildx build --pull --no-cache --build-arg BUILDKIT_SYNTAX=tianon/buildkit:0.13 - <<<$'FROM bash\nRUN echo see, it works!' #0 building with "default" instance using docker driver #1 [internal] load build definition from Dockerfile #1 transferring dockerfile: 71B done #1 DONE 0.0s #2 [internal] load .dockerignore #2 transferring context: 2B done #2 DONE 0.0s docker-library#3 resolve image config for docker.io/tianon/buildkit:0.13 docker-library#3 DONE 0.2s docker-library#4 docker-image://docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab docker-library#4 resolve docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab 0.0s done docker-library#4 CACHED docker-library#5 [internal] load metadata for docker.io/library/bash:latest docker-library#5 DONE 0.2s docker-library#6 [1/2] FROM docker.io/library/bash:latest@sha256:ce062497c248eb1cf4d32927f8c1780cce158d3ed0658c586a5be7308d583cbb docker-library#6 CACHED docker-library#7 [2/2] RUN echo see, it works! see, it works! docker-library#7 DONE 0.3s docker-library#8 exporting to image docker-library#8 exporting layers 0.0s done docker-library#8 writing image sha256:ceb5fb7b6904a68eeedd25c253e54e9ae1160c404c7e9fbb26c142d8a8143ef8 done docker-library#8 DONE 0.0s
Support for this was implemented in my images back in tianon/dockerfiles@8c85466 as a PoC (and support for it was kept in tianon/dockerfiles@2b78191 when the explicit 0.13 builds were added), and I've actually been using it pretty heavily since without issue, both locally *and* for all of my `tianon/xxx` personal image builds (including building of `tianon/buildkit` itself, for maximum meta 😂). The primary benefit is that we get the exact same architecture support matrix as our BuildKit images (and the same set of applied patches, if they happen to impact the frontend code as well). $ docker buildx build --pull --no-cache --build-arg BUILDKIT_SYNTAX=tianon/buildkit:0.13 - <<<$'FROM bash\nRUN echo see, it works!' #0 building with "default" instance using docker driver #1 [internal] load build definition from Dockerfile #1 transferring dockerfile: 71B done #1 DONE 0.0s #2 [internal] load .dockerignore #2 transferring context: 2B done #2 DONE 0.0s docker-library#3 resolve image config for docker.io/tianon/buildkit:0.13 docker-library#3 DONE 0.2s docker-library#4 docker-image://docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab docker-library#4 resolve docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab 0.0s done docker-library#4 CACHED docker-library#5 [internal] load metadata for docker.io/library/bash:latest docker-library#5 DONE 0.2s docker-library#6 [1/2] FROM docker.io/library/bash:latest@sha256:ce062497c248eb1cf4d32927f8c1780cce158d3ed0658c586a5be7308d583cbb docker-library#6 CACHED docker-library#7 [2/2] RUN echo see, it works! see, it works! docker-library#7 DONE 0.3s docker-library#8 exporting to image docker-library#8 exporting layers 0.0s done docker-library#8 writing image sha256:ceb5fb7b6904a68eeedd25c253e54e9ae1160c404c7e9fbb26c142d8a8143ef8 done docker-library#8 DONE 0.0s
Support for this was implemented in my images back in tianon/dockerfiles@8c85466 as a PoC (and support for it was kept in tianon/dockerfiles@2b78191 when the explicit 0.13 builds were added), and I've actually been using it pretty heavily since without issue, both locally *and* for all of my `tianon/xxx` personal image builds (including building of `tianon/buildkit` itself, for maximum meta 😂). The primary benefit is that we get the exact same architecture support matrix as our BuildKit images (and the same set of applied patches, if they happen to impact the frontend code as well). $ docker buildx build --pull --no-cache --build-arg BUILDKIT_SYNTAX=tianon/buildkit:0.13 - <<<$'FROM bash\nRUN echo see, it works!' #0 building with "default" instance using docker driver #1 [internal] load build definition from Dockerfile #1 transferring dockerfile: 71B done #1 DONE 0.0s docker-library#2 [internal] load .dockerignore docker-library#2 transferring context: 2B done docker-library#2 DONE 0.0s docker-library#3 resolve image config for docker.io/tianon/buildkit:0.13 docker-library#3 DONE 0.2s docker-library#4 docker-image://docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab docker-library#4 resolve docker.io/tianon/buildkit:0.13@sha256:95db7c7b47f142af3fe0cae7de217996dadde8c44ef9e331ddd564857ca277ab 0.0s done docker-library#4 CACHED docker-library#5 [internal] load metadata for docker.io/library/bash:latest docker-library#5 DONE 0.2s docker-library#6 [1/2] FROM docker.io/library/bash:latest@sha256:ce062497c248eb1cf4d32927f8c1780cce158d3ed0658c586a5be7308d583cbb docker-library#6 CACHED docker-library#7 [2/2] RUN echo see, it works! see, it works! docker-library#7 DONE 0.3s docker-library#8 exporting to image docker-library#8 exporting layers 0.0s done docker-library#8 writing image sha256:ceb5fb7b6904a68eeedd25c253e54e9ae1160c404c7e9fbb26c142d8a8143ef8 done docker-library#8 DONE 0.0s
Why do you think about adding the docker image to stackbrew ?