[WIP] add goreleaser as build/release process

[guilhem]

As a first step to fix #1377, I begin to work on goreleaser.

First major problem for this to be merged:

• I don't decorrelate helm-operator from fluxctl/fluxd.
  It, maybe, can be done with 2 different files but I suggest slipping this 2 projects into 2 different repo...
• I didn't add CI
• I didn't add snap / deb / rpm building (easy but waiting for your input about this work)

[2opremio]

I am not sure it makes sense to package the helm operator and fluxd, since they are designed to work inside a kubernetes cluster (and there are already Docker images for that). I would say it only makes sense to package fluxctl. @squaremo would you agree?

[guilhem]

goreleaser can also package docker images ^^
But yes, that's not main point.

One advantage I see with goreleaser in process, is to be able to push ARM docker images easily.

Having a release as tar.gz is only a "plus" for people who don't trust image "from the internet", but trust a binary on GH :x

[stefanprodan]

I would keep fluxctl only and remove the changelog. We have a curated change log in the repo and I don't think we want goreleaser to publish all the commits on the GitHub release page. As for automating this I would go with GitHub Actions.

[stefanprodan]

Also we should not run goreleaser when we tag a helm-op or chart release. This could be done with GitHub Action filters similar to https://raw.githubusercontent.com/weaveworks/flux/master/.github/main.workflow

[stefanprodan]

Will this inject the version at build time? see https://github.com/weaveworks/flux/blob/master/Makefile#L33

[guilhem]

default is -s -w -X main.version={{.Version}} -X main.commit={{.ShortCommit}} -X main.date={{.Date}}

[2opremio]

I think that the current process works fine. Let me know if you think otherwise