chore: Build with Go 1.21.4

[twpayne]

No description provided.

[bradenhilton]

FYI, Fedora 39 was released yesterday.

On an unrelated note, do you think it would be worth splitting out the test-release job and having it depend on the other test jobs, then have the release job depend on the test-release job? i.e.:

test-* -> test-release -> release

IIRC, sometimes the test-* jobs can fail through no fault of chezmoi's, so I can definitely understand that side as well.

[twpayne]

FYI, Fedora 39 was released yesterday.

Thanks. It looks like the Go installation in Fedora 39 broke go tool dist list due to not installing $GOROOT/VERSION. I'll see if I can find a work-around.

On an unrelated note, do you think it would be worth splitting out the test-release job and having it depend on the other test jobs, then have the release job depend on the test-release job?

release already depends on test-release. The reason for not having test-release depend on the other test-* jobs is wall clock time. As far as I can tell, GitHub Actions has very slow CPUs and little or no support for re-using results across jobs, and so every job has to rebuild everything from scratch. Consequently, test-release already takes 20 minutes (slow CPUs) so having it depend on test-* (some of which already take 10 minutes, again due to slow CPUs) would add 10 minutes to the overall build time. A release build already takes 60 minutes of wall clock time, and frankly I don't have the patience to wait longer.

If some of the results from test-* could be re-used in test-release, and if some of the results from test-release could be re-used in release then the situation would be significantly better.

[twpayne]

Confirmed that this is a bug in Fedora 39:

$ docker pull fedora:latest
$ docker run -it fedora:latest /bin/bash
[root@01330dfaac82 /]# dnf update && dnf install -y golang
...
[root@01330dfaac82 /]# go version
go version go1.21.3 linux/amd64
[root@01330dfaac82 /]# go tool dist list
go tool dist: FAILED: not a Git repo; must put a VERSION file in $GOROOT

[bradenhilton]

The reason for not having test-release depend on the other test-* jobs is wall clock time. As far as I can tell, GitHub Actions has very slow CPUs and little or no support for re-using results across jobs, and so every job has to rebuild everything from scratch. Consequently, test-release already takes 20 minutes (slow CPUs) so having it depend on test-* (some of which already take 10 minutes, again due to slow CPUs) would add 10 minutes to the overall build time. A release build already takes 60 minutes of wall clock time, and frankly I don't have the patience to wait longer.

Ahh, I didn't know that. Thanks for the explanation, anyway.

[halostatue]

release already depends on test-release. The reason for not having test-release depend on the other test-* jobs is wall clock time. As far as I can tell, GitHub Actions has very slow CPUs and little or no support for re-using results across jobs, and so every job has to rebuild everything from scratch. Consequently, test-release already takes 20 minutes (slow CPUs) so having it depend on test-* (some of which already take 10 minutes, again due to slow CPUs) would add 10 minutes to the overall build time. A release build already takes 60 minutes of wall clock time, and frankly I don't have the patience to wait longer.

If some of the results from test-* could be re-used in test-release, and if some of the results from test-release could be re-used in release then the situation would be significantly better.

I'm not quite sure what would be needed to make this the case from a logical perspective, but there are at least two ways to pass data between dependent jobs:

• outputs
• artifacts

Toward the end of the month, I should have some time to look into this if I had a better understanding of what you would want to reuse downstream.

[twpayne]

Toward the end of the month, I should have some time to look into this if I had a better understanding of what you would want to reuse downstream.

I opened #3366 for this.