Are there any best practices yet for production, private, automated CI builds?

Hi, first post and glad to be part of the Go community!

Little background: I learnt Go to interact with an API for a microservice at my company, ever since then I’ve loved the language and it has served well and I’ve been writing a lot of our software in it - I’m also the only one using Go here and I’m always pushing it as a great microservice and server-sided language.

However, since we’ve switched to an internally hosted Jenkins from CircleCI for various reasons it has suddenly gone from the easiest language to dockerise (static build, scratch container, <20MB, easy) to the most difficult! Mostly because of problems with dependency management with private repositories. Go is great in open source but we’ve not reached a stage where we have decided what parts of our code we want to open-source yet.

The main question here is: is there an accepted and standard production-level method of doing this yet or is Go just not mature enough yet?

The guy who set up our Jenkins wanted to build the Go app inside the container but I’ve been doing the static/scratch workflow because of the tiny container size and I assumed this way was the most widely accepted way of doing Docker images with Go. Doing it outside would require installing the Go environment onto the Jenkins nodes and the third method would be to build a container specifically for just building the image but with this, I’m not entirely sure how to extract the resultant binary out of the build container for inserting into the production “scratch” container.

Looking forward to some answers to this! I’ve tried searching but I get lots of outdated results and methods that don’t work any more. I’ve tried the git config insteadOf method to at least get SSH git-pulls but that doesn’t work (and hasn’t since 1.4 afaik).

You may be interested in two-stage builds that are possible since Docker 17.05. Here is a blog post that explains how to do this for producing tingy Go containers.

1 Like

This solution seemed perfect but unfortunately the Jenkins version we’re using does not support multi-stage builds.

Indeed, multi-stage builds are a quite new Docker feature.

I am not familiar with Jenkins, but should a CI tool even bother whether the Dockerfile runs one or two build stages? From the outside, it is a single docker build command in both cases.

That’s what I thought but apparently it’s related to how Jenkins mounts its filesystem and injects its own stuff into the container after it starts.

Annoyingly, I think this means it fails on FROM scratch containers because it can’t execute common tools - we had a confusing error saying it failed to execute command cat. Alpine it is I guess for now…

That’s already a lot smaller than a full “golang”-based image

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.