If dig returns exit code 9 (no reply from server) when checking an
instance for cloudflare records, it shouldn't fail the CI build but
rather just skip adding the instance to the non-cloudflare services
list.
This should be re-evaluated soon to see if the CI build routinely has
issues with getting a server reply. If so, a different approach needs to
be taken to check if an instance is using cloudflare.
This new dir will probably stay fairly empty, but this script could come
in handy for anyone seeking to add a new instance (for services that
aren't supported by the auto update workflow).
The filtered service list isn't guaranteed to have more than one
instance per service, which fails a test that was designed to ensure
back-to-back requests don't use the same instance. Using the full
services json file more accurately tests the intended functionality for
Farside.
This updates the services json file to exclude all instances that are
detected to be using Cloudflare nameservers.
A separate "services-full.json" file will continue to be tracked in the
repo, which will include the full list of all instances for each
service and can be used with the `FARSIDE_SERVICES_JSON` environment
variable for anyone wanting to access the full instance list for each
service.
See #43
Connection values (such as redis server port and the port to run farside
on) as well as the services json file to use can now be set via
environment variables:
FARSIDE_PORT sets the port for Farside to run on
FARSIDE_REDIS_PORT sets the redis server port for Farside to use
FARSIDE_SERVICES_JSON sets the services json file for Farside to use
This partially addresses the move towards de-listing Cloudflare
instances by default by allowing different services json files to be
used with different redis servers.
See #43
