Automatic Builds to Docker Hub using GitHub actions

[Anunayj]

Adds automatic Builds to DockerHub using Github Actions. Image tags used:

• letsdane:latest: For all push events in master branch.
• letsdane:tag: For all tagged commits, v0.5.0 tag will appear as letsdane:v0.5.0

DOCKERHUB_USERNAME and DOCKERHUB_TOKEN GitHub repo secrets need to be set.

Images for the following platforms are made: linux/amd64,linux/arm64,linux/arm. Might wanna consider building for linux/386,linux/arm/v7,linux/arm/v6.

[Anunayj]

This won't run builds for older versions sadly, which would have been nice to have, also a lts/stable image for major version changes would be nice.

[Anunayj]

Might wanna change tagged version to match v* instead of *

[Anunayj]

Btw How Can I build the binary statically linking libunbound? I tried doing something like go build -tags unbound -ldflags="-extldflags=-static" But that would also try to statically link glibc, which ofc hates being linked like that. I'm not really familiar with C/go.

[buffrr]

nice work! i should be able to review and set this up sometime next week.

Btw How Can I build the binary statically linking libunbound? I tried doing something like go build -tags unbound -ldflags="-extldflags=-static" But that would also try to statically link glibc, which ofc hates being linked like that. I'm not really familiar with C/go.

yeah glibc doesn't like to be statically linked. One approach is to only statically link libunbound and its dependencies but keep glibc as an external dependency (the binary may not work if glibc version is different in some other distro). Or you can use musl libc which is a lightweight alternative to glibc that can be linked statically (i like this better) but this is how you can do it. Depending on how you built unbound, it either uses nettle+gmp or openssl.

I think if you installed libunbound-dev on ubuntu it uses libnettle and libevent (which is optional)

apt install libunbound-dev nettle-dev libevent-dev
CGO_LDFLAGS="-Wl,-Bstatic -lunbound -lhogweed -lgmp -levent -lnettle -Wl,-Bdynamic"  go build -tags unbound

or if using unbound with openssl

CGO_LDFLAGS="-Wl,-Bstatic -lunbound -lssl -lcrypto -Wl,-Bdynamic"  go build -tags unbound

but this doesn't create a fully statically linked binary! and it depends on glibc version. Here's an example of how to build a proper static binary with musl libc which should work with most linux distros.

I'm building on Alpine v3.13 (linux-x86_64). This builds latest stable versions of openssl and unbound from source to create *.a libraries for linking.

apk update && apk add linux-headers gcc make perl musl-dev expat-dev
wget https://www.openssl.org/source/openssl-1.1.1j.tar.gz && tar -xzf openssl-1.1.1j.tar.gz
cd openssl-1.1.1j
./Configure linux-x86_64
make
make install

wget https://www.nlnetlabs.nl/downloads/unbound/unbound-1.13.1.tar.gz && tar -xzf unbound-1.13.1.tar.gz
cd unbound-1.13.1
./configure
make
make install

now you can build letsdane

go build -tags unbound --ldflags '-extldflags "-lunbound -lssl -lcrypto -static"'

you can verify it's a fully static binary

$ ldd letsdane
/lib/ld-musl-x86_64.so.1: letsdane: Not a valid dynamic program

[Anunayj]

Ooops seems like the pull bot just messed a thing, oof, now you'll have to manually fix the merge conflict :P, Sorry, I'll not do pull requests from master branch from now on.

Lesson learnt: cherry-picking commits from another branch is not a good way to add them to main branch.

[Anunayj]

Fixed

[Anunayj]

Hmmm I tried building the binary on alpine, though got this:

/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/go-link-038088565/000006.o: in function `_cgo_4919ea55c4da_Cfunc_ub_ctx_add_ta':
/tmp/go-build/cgo-gcc-prolog:161: undefined reference to `ub_ctx_add_ta'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/go-link-038088565/000006.o: in function `_cgo_4919ea55c4da_Cfunc_ub_ctx_add_ta_file':
...
...
lots of similar error
...
...
/tmp/go-build/cgo-gcc-prolog:564: undefined reference to `ub_version'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/go-link-115794086/000006.o: in function `_cgo_4919ea55c4da_Cfunc_ub_ctx_delete':
/tmp/go-build/cgo-gcc-prolog:314: undefined reference to `ub_ctx_delete'
/usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: /tmp/go-link-115794086/000006.o: in function `_cgo_4919ea55c4da_Cfunc_ub_resolve_free':
/tmp/go-build/cgo-gcc-prolog:512: undefined reference to `ub_resolve_free'
collect2: error: ld returned 1 exit status

Should I instead open a issue for this?

[buffrr]

It seems like it's not finding libunbound functions like ub_version() and ub_ctx_add_ta belong to libunbound. It's probably better to open a new issue if you're still unable to build it so we can document how to build it for linux or other platforms. lets keep this PR about automatic builds to DockerHub

[hugomd]

Out of interest, why push to Docker Hub instead of GitHub Container Registry? That way both the code and containers are in a single place.

[buffrr]

Out of interest, why push to Docker Hub instead of GitHub Container Registry? That way both the code and containers are in a single place.

Yeah this should make things easier to manage. I've been meaning to get to this PR. @Anunayj what are your thoughts on this?

It would be nice if this PR also set the correct letsdane version during build time. Currently, calling ./letsdane -version will show untracked dev. This is an example of how to set the version to v0.5:

go build -tags unbound -ldflags "-X github.com/buffrr/letsdane.Version=v0.5"

Perhaps you can use an env var in the Dockerfile and set the version when building the image?

[Anunayj]

Sure, Well it'd be quite easy to add push to both Github Registry and Dockerhub. I just added dockerhub cause most people will look for letsdane there first.

I'll fix the versioning too later.

On Thu, 20 May 2021, 11:55 Buffrr, @.***> wrote:

Out of interest, why push to Docker Hub instead of GitHub Container Registry? That way both the code and containers are in a single place.

Yeah this should make things easier to manage. I've been meaning to get to this PR. @Anunayj https://github.com/Anunayj what are your thoughts on this?

It would be nice if this PR also set the correct letsdane version during build time. Currently, calling ./letsdane -version will show untracked dev. This is an example of how to set the version to v0.5:

go build -tags unbound -ldflags "-X github.com/buffrr/letsdane.Version=v0.5"

Perhaps you can use an env var in the Dockerfile and set the version when building the image?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/buffrr/letsdane/pull/8#issuecomment-844744742, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGKKVACLVXYNCBWZHTN5N3DTOSTOTANCNFSM4YFUTG5A .

[buffrr]

I just added dockerhub cause most people will look for letsdane there first.

In this case lets stick with Dockerhub

[buffrr]

I will close this for now and we can revisit later