we recently adopted OpenTofu into our environment
we have a highly decentralized system; hundreds/thousands of deployment jobs to different target environments. they share, however, a common set of network resources
the net effect is that all of our CI runners funnel requests through a NAT gateway; as a result, external sites like Github only see a single origin IP address. it is very easy to saturate the anonymous API limit of 60 / hr
when that happens, deployments are blocked, e.g.
Resolved version from TOFUENV_TOFU_VERSION : ~>1.9.0
Fetching all releases information from https://api.github.com/repos/opentofu/opentofu/releases
Error: you are rate-limited by GitHub. Consider using a token by setting the TENV_GITHUB_TOKEN env variable to increase the rate limit
ERROR: Job failed: exit code 1
I know that there is TENV_GITHUB_TOKEN for providing authenticated API access, but I'm wondering if there could be some other alternatives (or for the case when a higher limit is also saturated)
perhaps there could be a TENV_FORCE_LOCAL that uses only locally installed artifacts for version resolution?
or maybe some fallback error handling to use a compatible locally installed version if the remote lookup(s) fail?
e.g.
requested: ~1.9.0
available locally: ~1.9.0
available remotely (would be): ~1.9.0, 1.9.1
while 1.9.1 would be preferred, the locally installed 1.9.0 still satisfies the constraint and is much preferred to a blocking error
we recently adopted OpenTofu into our environment
we have a highly decentralized system; hundreds/thousands of deployment jobs to different target environments. they share, however, a common set of network resources
the net effect is that all of our CI runners funnel requests through a NAT gateway; as a result, external sites like Github only see a single origin IP address. it is very easy to saturate the anonymous API limit of 60 / hr
when that happens, deployments are blocked, e.g.
I know that there is
TENV_GITHUB_TOKENfor providing authenticated API access, but I'm wondering if there could be some other alternatives (or for the case when a higher limit is also saturated)perhaps there could be a
TENV_FORCE_LOCALthat uses only locally installed artifacts for version resolution?or maybe some fallback error handling to use a compatible locally installed version if the remote lookup(s) fail?
e.g.
requested:
~1.9.0available locally:
~1.9.0available remotely (would be):
~1.9.0, 1.9.1while
1.9.1would be preferred, the locally installed1.9.0still satisfies the constraint and is much preferred to a blocking error