Skip to content

Build pipeline overhaul #154

@kernle32dll

Description

@kernle32dll

This is a collection of things, that caught my attention and/or interest.

1. Leverage docker multi-stage builds
While it is fine to build the binary outside the docker context, there is still something to gain from docker multi-stage builds. For example, for a fully static binary build, it is not necessary to use the "full" alpine image. Instead, an additional "FROM scratch" layer could be used, which copies the htpasswd and ca-certificates from the alpine layer. Like so:

FROM alpine as builder
RUN apk --update --no-cache add ca-certificates
RUN addgroup -S loginsrv
RUN adduser -S -g loginsrv loginsrv

# ----------

FROM scratch
ENV LOGINSRV_HOST=0.0.0.0 LOGINSRV_PORT=8080
EXPOSE 8080
ENTRYPOINT ["./loginsrv"]

COPY --from=build /etc/passwd /etc/passwd
USER loginsrv

COPY --from=build /etc/ssl/certs/ /etc/ssl/certs/
COPY loginsrv /

2. Build the binary inside the docker image
In preparation for #153, the actual binary build should be moved into the dockerfile.

Currently, the binary is build on a glibc system, and then inserted into an Alpine (musl) container. This is a very hot dance, and prune to fail some day.

I imagine that by statically building against musl, we could also save a few bytes - but thats probably neglectable.

3. Fix docker image push
This is actually an oversight of #144. Since we now not only build on tip, but go 1.12 and go 1.13, the push script must be adjusted to only run for go 1.13. Currently, the build result for the latest tag is undefined! :/

4. Use versioned alpine image
Also related to #144. Stabilizing the go version was a start, but the build is still not 100% predictable. A concrete version of the alpine docker base image should be used.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions