Combining prebuilt and prepare using multiple build jobs, validated workflows

[AaronFriel]

Suppose one has 5 build jobs each building for one target:

• darwin-amd64
• linux-amd64
• ...

This is a great way to speed up builds by utilizing extra capacity in runners. But:

1. If one wants to then run integration tests that simulate installing these artifacts and using them, goreleaser build doesn't build the full .tar.gz/.zip files for a target, just the binaries. This means that the configured archive.files files are left out of the dist dir.

2. If one solves that problem by using goreleaser release --snapshot or goreleaser release --prepare, it's not obvious how to do that for a single target or how to integrate the various dist folders in the end with goreleaser publish or goreleaser announce.

3. If one solves all of these problems by instead attempting to skip the build process and have goreleaser manage the release and announce, one finds that it's not permitted to omit "build".

Are there better ways to do this? The constraints I'm solving for are:

• Ensure all tests run using release artifacts and all releases pass tests by ordering jobs "build -> test -> release"
• Reduce the time to complete the build step by using multiple jobs
• Ensure the release uses the same artifacts that were tested

Having a devops orientation, I would like to include the archives in the build step, or allow publishing without a build step. To me, the archive is a build artifact much like a container image, .deb/.rpm, .pkg, or .msi file. That built artifact should be tested before being promoted to being released.

I would like to both:

1. Allow creating archives during goreleaser build, so that the final, bit-for-bit archives are what are tested in integration tests
2. Allow omitting build steps in goreleaser release and instead only specify "extra_files" so that the tested archives are what is released.

[caarlos0]

goreleaser build is meant to be used as "go build, but with my goreleaser config", that why it only builds the binaries, and will likely stay that way.

if you want to build in multiple different jobs and merge the jobs together later, right now, its not pretty...

you'll need several config files (one for each build, basically), and another one using the prebuilt builder importing all them and packaging et al...

goreleaser build itself also takes quite a long time, but I decided to let it take its time instead of making a mess of config files... and I test the packages on main...

goreleaser/.github/workflows/build.yml

Lines 17 to 43 in 7aeebb1

	goreleaser-check-pkgs:
	runs-on: ubuntu-latest
	env:
	DOCKER_CLI_EXPERIMENTAL: "enabled"
	needs:
	- goreleaser
	if: github.ref == 'refs/heads/main'
	strategy:
	matrix:
	format: [ deb, rpm, apk ]
	steps:
	- uses: actions/checkout@b0e28b5ac45a892f91e7d036f8200cf5ed489415 # v3
	with:
	fetch-depth: 0
	- uses: arduino/setup-task@ca745e18916de727f841ec824ac20a615f1cddea # v1
	with:
	version: 3.x
	repo-token: ${{ secrets.GITHUB_TOKEN }}
	- uses: docker/setup-qemu-action@8b122486cedac8393e77aa9734c3528886e4a1a8 # v1
	- uses: actions/cache@661fd3eb7f2f20d8c7c84bc2b0509efd7a826628 # v2
	with:
	path: |
	./dist/*.deb
	./dist/*.rpm
	./dist/*.apk
	key: ${{ runner.os }}-go-${{ hashFiles('**/*.go') }}-${{ hashFiles('**/go.sum') }}
	- run: task goreleaser:test:${{ matrix.format }}

FWIW: an example using the prebuilt thing: https://github.com/caarlos0/goreleaser-pro-prebuilt-example

FWIW2: I have been thinking in a way to better do this, aka "merge" existing dist folders et al... but haven't got the time to properly work on it yet. Once I have a testable thing I can ping you if you'd like.

[AaronFriel]

Could we introduce a way to build final artifacts independently (--single-target)?

I'd like to separate all actions that create/modify artifacts with those that tag, release, announce them. That way when we run integration tests, we can simulate a real install process and validate the artifacts we ship to end users.

If we have to fake it, because our process replies on additional prebuilt binaries, then there's a risk however small that there's a delta between our faking the final install process and what we release. (In fact, we had such an issue but it was found before release.)

[caarlos0]

This is now possible with goreleaser pro v1.12.0

example repo: https://github.com/caarlos0/goreleaser-pro-split-merge-example