Dockerfile: debian based build #239
Conversation
Codecov Report
@@ Coverage Diff @@
## master #239 +/- ##
===========================================
- Coverage 55.25% 43.08% -12.18%
===========================================
Files 9 7 -2
Lines 666 448 -218
===========================================
- Hits 368 193 -175
+ Misses 255 224 -31
+ Partials 43 31 -12
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Dockerfile
Outdated
|
|
||
| FROM base AS test | ||
| RUN xx-apk add gnome-keyring gpg-agent gnupg-gpgconf pass | ||
| FROM golang:${GO_VERSION}-alpine AS test |
There was a problem hiding this comment.
unfortunately can't make sandboxed test work with debian base image 😞
it seems gpg or pass does not behave like on alpine:
#15 0.721 ok github.com/docker/docker-credential-helpers/credentials 0.002s coverage: 58.5% of statements
#15 0.752 === RUN TestPassHelper
#15 0.752 pass_test.go:20: exit status 1: gpg: WARNING: unsafe permissions on homedir '/root/.gnupg'
#15 0.752 gpg: 0xD523BD50DD70B0BA: There is no assurance this key belongs to the named user
#15 0.752 gpg: cannot open '/dev/tty': No such device or address
#15 0.752 Password encryption aborted.
#15 0.752
#15 0.752 --- FAIL: TestPassHelper (0.02s)
There was a problem hiding this comment.
ah found the issue, on debian based we have to change the trust level command to:
echo '5\ny\n' | gpg --command-fd 0 --no-tty --edit-key 7D851EB72D73BDA0 trust
There was a problem hiding this comment.
For the permissions, we could probably also try to fix by setting the directory permissions when we create the directory (I recall I made that change when I was looking into things)
There was a problem hiding this comment.
For the permissions, we could probably also try to fix by setting the directory permissions when we create the directory (I recall I made that change when I was looking into things)
Yes we could take a look in a follow-up for this one 👍
There was a problem hiding this comment.
Yeah, was thinking; add a mkdir (and chmod if needed) here;
docker-credential-helpers/Dockerfile
Line 70 in 2f246b8
crazy-max
force-pushed
the
debian-base
branch
3 times, most recently
from
aa72f69
to
6fc3212
Compare
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
| @@ -13,9 +14,10 @@ FROM --platform=$BUILDPLATFORM tonistiigi/xx:${XX_VERSION} AS xx | |||
| # osxcross contains the MacOSX cross toolchain for xx | |||
| FROM crazymax/osxcross:${OSXCROSS_VERSION} AS osxcross | |||
|
|
|||
| FROM --platform=$BUILDPLATFORM golang:${GO_VERSION}-alpine AS gobase | |||
| FROM --platform=$BUILDPLATFORM golang:${GO_VERSION}-bullseye AS gobase | |||
There was a problem hiding this comment.
Do we know if -buster would work on both "bullseye" and "buster", or would that break? I recall the containerd maintainers had to downgrade their machines to ubuntu 18.04 to make them more compatible; containerd/containerd@v1.6.7...v1.6.8
There was a problem hiding this comment.
Yes I was also wondering what was our best option. I will try and let you know.
There was a problem hiding this comment.
ppc64le, s390x and armel (arm/v6) cross pkgs are not available in buster 😣 only in buster-backports afaik. also looking at release 0.6.4 it seems binaries were built on bullseye.
There was a problem hiding this comment.
Alright; if we already used bullseye, then it's probably fine
follow-up #237 (comment)
using musl to build dynamically linked secretservice helper is not suitable so switch to debian based as it is for current released binaries.
Signed-off-by: CrazyMax crazy-max@users.noreply.github.com