Speed up release GitHub Action

[twpayne]

Is your feature request related to a problem? Please describe.

I'm always frustrated when chezmoi's CI takes about 40 minutes of wall clock time. I wish that chezmoi's CI would run quicker. This is especially frustrating in release builds where the test-release job and the release job each take about twenty minutes to run, one after the other, when they share the same work.

Describe the solution you'd like

chezmoi's GitHub Actions should re-use work where possible to reduce the overall wall clock time. Specifically, work from the test-release job should be re-used in the release job.

Describe alternatives you've considered

Leaving things as they are. The current CI works and only runs a few times per day.

Additional context

I expressed frustration in this comment and @halostatue asked for clarification in this comment.

[halostatue]

I’m going to look at ways that this could be improved in my spare time over the holiday week. I can't promise a lot, because I’m also going to start an upgrade to Sonoma (probably tonight).

[bradenhilton]

On a more general note regarding the other jobs, would being just a touch more selective about the changes each job depends on be an easy win?

I'm aware we already sort of do this, but I'm wondering if we can't go a bit further and see if it increases or decreases friction.

For example, I'd imagine in most cases that editing one of the install scripts wouldn't necessitate building and testing chezmoi, on several different platforms no less.

Likewise, a quick chore change on the website also shouldn't typically require building and testing chezmoi.

Perhaps we could split them as best we can into groups such as src/website/scripts etc. and be more explicit about what changes the jobs in each group require to run.

The src group would naturally contain the most jobs.

The website group could largely depend on changes to assets/chezmoi.io/** etc. and only run jobs related to the website.

Each group could have its own workflow file.

Just thinking out loud.

[twpayne]

Yes please! The changes job already tries to identify code changes and other jobs depend on its output. Further refinement very welcome :)

[halostatue]

I believe we can get even more speedup, but I am entering a very busy period and don't expect to surface until late May.

[twpayne]

Thank you @halostatue! This is a volunteer project and there are zero expectations. All the best for your busy period :)

[KapJI]

It seems for splitting goreleaser job by platform or reusing results from previous test-release job you need goreleaser pro subscription: https://goreleaser.com/customization/partial/

Maybe they have discount for OSS projects, if you are interested.

Here is an example implementation: https://github.com/goreleaser/goreleaser-pro-split-merge-example/blob/main/.github/workflows/nightly.yml

To leverage this feature build-release-<os> jobs can be created, on which test-release can depend on. And release can depend on test-release and reuse the same artifacts. Then all binaries should be only built once for the cost of using some extra cache space (around 1 GB per build). And probably CGO can be used for more platforms as well.

[twpayne]

Fixed by @KapJI, thank you so much!

[twpayne]

To close the loop on this:

I just pushed the v2.54.0 release. Thanks to @KapJI's work here, the entire release job took under 17 minutes, which is over 20 minutes faster than the previous release job. This is fantastic!

Regular CI builds have are also 10 minutes or more quicker. Thank you @KapJI!