go 1.17.5

[Porkepix]

Created with brew bump-formula-pr.

resource blocks may require updates.

[Loyalsoldier]

Why were tests cancelled?

[bevanjkay]

@Loyalsoldier Tests have a timeout of 60 minute unless maintainers allow longer CI runs (by labelling the PR), to ensure CI machines aren't blocked by too many concurrent long runs.

[carlocab]

We already have two long-running CI jobs at the moment. A third one is going to cause huge delays, so we can restart this when those jobs are done.

[kidoman]

Go 1.17.4 is now officially released. It fixes a nasty crash on mac OS Monterey (apparent kernel bug.) How can I help get this released?

[SMillerDev]

Check all the failing dependent formulae and help fix them

[gonzaloserrano]

@SMillerDev where can we see that list?

[SMillerDev]

In the pull request "Checks"

[iMichka]

I opened a PR for imgproxy and bosh-cli: #90670, #90669

[jidicula]

fyi Go 1.17.5 was just released. Does that mean this PR should be closed and a new one opened?

[SMillerDev]

This one can also be updated

[stefanb]

Most of tests

exceeded the maximum execution time of 60 minutes.

[stefanb]

🤔 Q: why do all dependancies need to be checked and rebuilt?
Yes, it is true, that they depend on go, but upgrading go will not break them, as those binaries are already built and statically linked with NO external dependancies on go. They will continue to be functioning as before.

I have noticed this problem with the last few go upgrades, most notably with the major revisions, eg #83413 with a huge list of fixes to dependants, which should be up to dependants to sort out, and giving them upgraded go binary would actually help them detect and fix those problems earlier.

[SMillerDev]

Yes, it is true, that they depend on go, but upgrading go will not break them, as those binaries are already built and statically linked with NO external dependancies on go. They will continue to be functioning as before.

But how will we know they don't break with the newest Go version if we don't try and build them with that version?

I have noticed this problem with the last few go upgrades, most notably with the major revisions, eg #83413 with a huge list of fixes to dependants, which should be up to dependants to sort out, and giving them upgraded go binary would actually help them detect and fix those problems earlier.

It is up to dependents to sort out, but if nobody checks if it works how would they ever know?

and giving them upgraded go binary would actually help them detect and fix those problems earlier.

They can always run CI with pre-release Go builds to see if their software will stop working soon. Depending on Homebrew to suddendly break your build when you upgrade is just lazy and irrisponsible engineering.

[stefanb]

Yes, it is true, that they depend on go, but upgrading go will not break them, as those binaries are already built and statically linked with NO external dependancies on go. They will continue to be functioning as before.

But how will we know they don't break with the newest Go version if we don't try and build them with that version?

Do we need to know that when upgrading Go? Yes it is nice to know, but not essential for go upgrade and that can be dealt with later. Their current, already build version won't be affected in any way.

I have noticed this problem with the last few go upgrades, most notably with the major revisions, eg #83413 with a huge list of fixes to dependants, which should be up to dependants to sort out, and giving them upgraded go binary would actually help them detect and fix those problems earlier.

It is up to dependents to sort out, but if nobody checks if it works how would they ever know?

It will become obvious when somebody will eventually want to build the new dependant binary (either same or newer version, locally or when trying to bump the version in homebrew).

and giving them upgraded go binary would actually help them detect and fix those problems earlier.

They can always run CI with pre-release Go builds to see if their software will stop working soon. Depending on Homebrew to suddendly break your build when you upgrade is just lazy and irrisponsible engineering.

Yes, it is chicken and egg problem in a way, but current approach is blocking gradual evolution progress.

[andig]

I think we've had the argument before and it is probably better suited for discussions. I'd suggest here: Homebrew/discussions#2618

[iMichka]

• vgrep: vgrep: make test more robust #91180
• vault: vault 1.9.1 #91181
• traefik@1: traefik@1 1.7.34 #91164
• skaffold: skaffold: fix checksum #91182
• nuclei: nuclei 2.5.5 #91183
• mmctl: mmctl 6.2.0 #91184
• charm-tools: charm-tools: deprecate #91185

[BrewTestBot]

@iMichka has triggered a merge.

[iMichka]

Let's ship this. A few issues have been fixed, I'll make a second pass for go 1.17.6 ...

[iMichka]

Thanks @Porkepix for the pull request.

[AlekSi]

Thanks, everyone