use separate goreleaser config file to generate docker images based on alpine

[eine]

Close #243

In this PR, .goreleaser.yml is split (a new .goreleaser.docker.yml file is created) and Dockerfile is modified to use alpine as a base image (again).

Since dive is not statically compiled any more, it needs to be built inside an alpine docker container (or on an Alpine host). To do so, script docker.sh is added. Temporal image wagoodman/dive:devis built, which contains build dependencies. Then, goreleaser is executed inside the dev container.

Note that images are not pushed yet. This is because I'd like to discuss whether to build wagoodman/dive:dev in docker.sh or to add a GHA workflow to build it periodically (say weekly). Also, I wonder if the docker run command in docker.sh should be merged into the makefile. I'll keep this PR as a draft for now.

[wagoodman]

This is fantastic, thanks for the support!

Building wagoodman/dive:dev ephemerally in docker.sh will work just fine --that is, I'd be happy to merge it as is and work out enhancement details. If you were up for the extra mile, then the GHA workflow would be great (and the way to go). As for the docker run, this should stay in the docker.sh until I figure the best way to merge scripts/makefile and Circle/GHA (I'm up for it, I need to invest a bit more time in a more robust CI for dive).

[eine]

Building wagoodman/dive:dev ephemerally in docker.sh will work just fine --that is, I'd be happy to merge it as is and work out enhancement details. If you were up for the extra mile, then the GHA workflow would be great (and the way to go).

It is actually no effort for me. But I need you to setup a couple of secrets for me. Please add DOCKER_USER and DOCKER_PASS to https://github.com/wagoodman/dive/settings/secrets. That will allow to push wagoodman/dive:dev (and other images) to hub.docker.com. If credentials for quay.io are different, those will be required later.

Alternatively, we can use GitHub's Registry (docker.pkg.github.com/wagoodman/dive/dive:dev. The advantage is that the GITHUB_TOKEN that is available in GitHub Actions by default is enough to push/pull from it. The disadvantage is that GitHub's Registry does not support unauthorized access (not even for reading). Hence, it is cumbersome to use images locally.

As for the docker run, this should stay in the docker.sh until I figure the best way to merge scripts/makefile and Circle/GHA (I'm up for it, I need to invest a bit more time in a more robust CI for dive).

Ok.

[wagoodman]

GitHub Registry seems to be the right choice for security: keeping the dev image inaccessible from the "prod" docker hub registry. The extra login step is annoying, though not really a problem. I'm mentally stuck on:

We strongly recommend that you do not use this feature for high-value workflows and content during the beta period

From: https://help.github.com/en/github/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets .

[eine]

GitHub Registry seems to be the right choice for security: keeping the dev image inaccessible from the "prod" docker hub registry. The extra login step is annoying, though not really a problem.

Then, I need you to sign for the beta of the GitHub Registry (https://github.com/features/package-registry). Once it is enabled, the default GITHUB_TOKEN will have access to your own registry.

Apart from that, this PR is ready to merge. However, note that merging this now will break the automatic publication of docker images. In order to enable it, --snapshot --skip-publish options must be removed from docker.sh and docker/quay secrets must be added and passed to the wagoodman/dive:dev container.

Alternatively, it is possible to docker push quay.io/wagoodman/dive and docker push wagoodman/dive outside of the container. Say, as an additional step after docker images.

How do you release images now? Do you execute goreleaser on your workstation/laptop?

[eine]

We strongly recommend that you do not use this feature for high-value workflows and content during the beta period

I forgot to comment this. I believe that this note is because many things have been changing during the last months, and because the service has been 'free' during this period. Nevertheless, it will be out of beta next week; hence, each user will be able to define the complexity of the workflow within the limit of their budget. For public open source projects, the budget is 'maximum 20 parallel jobs'. No minutes per month limit.

[wagoodman]

Today, I build and release images from my laptop. However, this weekend I'll start working on incorporating a pipeline that cuts releases on tag. Additionally I'll be adding steps that will test package installations for various platforms/OSs.

This PR is a great starting point --I'll merge it and open another PR to accommodate the 0.9.1 changes I put in this morning.