feat: allow dynamic configuration of artifact host

[tklever]

The change replaces static references to releases.hashicorp.com with a configurable environment variable that defaults to releases.hashicorp.com.

This allows a user to do the following HOMEBREW_HASHICORP_ARTIFACT_REPOSITORY_HOST="https://my.hashicorp.releases.mirror" brew install terraform and the zip would be retrieved from the host of the user's configuration instead of releases.hashicorp.com

Who would use this and why

For those developing in environments with limited or restricted access to the public internet (i.e. behind corporate firewalls), external artifacts like the ones hosted on releases.hashicorp.com may often be made available on private systems via mirrors or proxies or rehosted entirely.

In these scenarios where direct access to the canonical releases repository is unavailable, to use homebrew successfully with these "hashicorp mirrors", it is a requirement to deploy a MODIFIED fork of this tap repo, swapping the static references to releases.hashicorp.com for references to the mirror / proxy / private artifact host. The need for these modifications from the public tap is what I'm trying to eliminate by making these formula more configurable.

With this configuration option available, this tap can be pulled into private environments UNMODIFIED, presumably eliminating the need for modifications or any effort to make them.

What about the copywrite formula?

The copywrite formula is a bit of an outlier in this repo. It has a unique artifact host (github releases), and it has a "This file was generated by GoReleaser. DO NOT EDIT." comment at the top. I chose to heed that instruction and left it alone. Willing to hear feedback if there's desire to add another environment variable there.

[hashicorp-cla]

All committers have signed the CLA.

[radeksimko]

@tklever I don't actively maintain this repo to have say over whether this would be accepted or not, however would you mind expanding on the motivation here?

The formulae and casks (as in the Ruby code with instructions on how/where to download the software from) are all hosted in this repository which itself is on GitHub, so whatever proxy/firewall is in the way would already have to allow access to github.com in order to install anything. What is the rationale behind allowing github.com but not releases.hashicorp.com?

[tklever]

The formulae and casks (as in the Ruby code with instructions on how/where to download the software from) are all hosted in this repository which itself is on GitHub, so whatever proxy/firewall is in the way would already have to allow access to github.com in order to install anything. What is the rationale behind allowing github.com but not releases.hashicorp.com?

You are correct, in my use case, both github.com and releases.hashicorp.com are obscured by a firewall, and both the binaries (releases.hashicorp.com) and this tap would have to be rehosted/proxied. However, this change adds flexibility to this tap which makes that redeployment easier, specifically adding configurability that enables this tap to be rehosted without any modifications.

From above:

With this configuration option available, this tap can be pulled into private environments UNMODIFIED, presumably eliminating the need for modifications or any effort to make them.

Current workflow is:

graph LR
resolve[Resolve conflicts with modifications to support private binary hosting]
pull[Pull public tap updates into private environment] --> resolve
resolve --> deploy[Deploy new modified private tap]

This middle conflict resolution step, while not overly challenging, is something that has to be completed by a human. It's a manual step, and it presents friction to stay up to date with the public tap (this repo).

If this change is accepted, new workflow would be:

graph LR
pull[Pull public tap updates into private environment] --> deploy[Deploy public tap with private configuration]

With the additional configuration options, the resolution step is removed, there's no longer a bespoke "private tap", only a rehosting of the public tap with different configuration. The manual "conflict resolution" step between the two codebases (taps) is gone, because they are no longer different. The private tap is an exact copy of the public tap, it can be updated automatically and without human intervention.