2b50af0cbc
* HETZNER: implement the provider for Hetzner DNS Console Signed-off-by: Jakob Ackermann <das7pad@outlook.com> * HETZNER: apply review feedback - add domain into error messages - insert sub-strings using `%q` - insert sub-errors using `%w` - change api.getZone() signature to return a (potentially `nil`) Zone pointer instead of a (potentially empty) Zone value - sort imports and confirm with `$ goimports -w providers/hetzner/` - use exact 'api_key' term in error message of settings validation - add blank line for logic separation - drop internal record id from correction messages Co-Authored-By: Tom Limoncelli <tlimoncelli@stackoverflow.com> Signed-off-by: Jakob Ackermann <das7pad@outlook.com> * HETZNER: add request rate-limiting handling There are a limited number of data-points on how their rate-limiting works at this time. I deduce from my account to others and use a fixed/ constant backoff of 1s as the initial delay. Thereafter exponential increase with factor 2 (not needed at this time). Hetzner has not made any official statements on rate-limiting, so this is guesswork only. Signed-off-by: Jakob Ackermann <das7pad@outlook.com> * HETZNER: address golint complaints - baseUrl -> baseURL - mark Record as private -> record - mark Zone as private -> zone - mark RequestRateLimiter as private -> requestRateLimiter - capitalize Id fields as ID - keep delay logic on same level, move return out of branch Signed-off-by: Jakob Ackermann <das7pad@outlook.com> * HETZNER: rate_limited: init the response timestamp on requestRateLimiter Signed-off-by: Jakob Ackermann <das7pad@outlook.com> * HETZNER: requestRateLimiter: align local variable with struct name Signed-off-by: Jakob Ackermann <das7pad@outlook.com> Co-authored-by: Tom Limoncelli <tlimoncelli@stackoverflow.com> |
||
|---|---|---|
| .. | ||
| config | ||
| zones | ||
| integration_test.go | ||
| providers.json | ||
| readme.md | ||
| test-numbers.txt | ||
Integration Tests
This is a simple framework for testing dns providers by making real requests.
There is a sequence of changes that are defined in the test file that are run against your chosen provider.
For each step, it will run the config once and expect changes. It will run it again and expect no changes. This should give us much higher confidence that providers will work in real life.
Configuration
providers.json should have an object for each provider type under test. This is identical to the json expected in creds.json for dnscontrol, except it also has a "domain" field specified for the domain to test. The domain does not even need to be registered for most providers. Note that providers.json expects environment variables to be specified with the relevant info.
Running a test
- Define all environment variables expected for the provider you wish to run. I setup a local
.envfile with the appropriate values and use zoo to run my commands. - run
go test -v -provider $NAMEwhere $NAME is the name of the provider you wish to run.
Example:
$ egrep R53 providers.json
"KeyId": "$R53_KEY_ID",
"SecretKey": "$R53_KEY",
"domain": "$R53_DOMAIN"
$ export R53_KEY_ID="redacted"
$ export R53_KEY="also redacted"
$ export R53_DOMAIN="testdomain.tld"
$ go test -v -verbose -provider ROUTE53
WARNING: The records in the test domain will be deleted. Only use
a domain that is not used in production. Some providers have a way
to run tests on domains that aren't registered (often a test
environment or a side-effect of the company not being a registrar).
In other cases we use a domain we squat on, or we register a domain
called dnscontrol-$provider.com just for testing.
ProTip: If you run these tests frequently (and we hope you do), you
should create a script that you can source to set these
variables. Be careful not to check this script into Git since it
contains credentials.