factor out healthchecks API endpoint to an environment variable

[earthquakesan]

I factored out the API endpoint URL into an env variable, this way CLI can be used with custom healthchecks deployment.

[cuu508]

Thanks for the PR!

CLI already needs to store API key:

hchk setkey my-api-key
# key gets saved in ~/.hchk

How about storing the API endpoint there as well?

Also I think we should only store the https://server/api/v1/ portion as the endpoint (without the checks/ bit at the end). This way it would be easier to add support for handling other resource types (e.g. integrations) in the future.

hchk setendpoint https://my-healthchecks-instance.net/api/v1/
# endpoint address gets saved in ~/.hchk

–something like that. What do you think?

[earthquakesan]

Hi @cuu508,

I agree with the API endpoint notion, storing only https://server/api/v1/ is indeed better option.
However, saving API endpoint into the .hchk file exclusively is not exactly what I want. Environment variables usually is a more flexible option for deploying the CLI. You can find my usage scenario here (ansible):

https://github.com/earthquakesan/borg-lab/blob/master/playbooks/roles/hchk/tasks/main.yml

To have environment variables as a first class citizen in the code, we can define precedence as follows:

• .hchk configuration file
• env variables

And then both configuration options (API endpoint and key) can be defined either with env vars or with the configuration file. If env variable is set, configuration file is simply ignored.

Let me know what you think.

[cuu508]

Supporting configuration file and environment variables sounds good to me. Environment variables taking precedence also seems like the way to go. A couple quick spot checks:

Ansible prefers env vars over configuration file: https://docs.ansible.com/ansible/latest/reference_appendices/general_precedence.html
Boto3 prefers env vars over configuration file: https://boto3.amazonaws.com/v1/documentation/api/latest/guide/configuration.html