Upgrade test checks for "error" in output.
But release descriptions can have "fix error in ..."
Don't run this check. Checking that a new version is detected suffices.
Use the GitHub release data to decide if an upgrade is available.
Only download the release if a newer stable release is published.
Install the full release - including the DNS scripts (requires "make")
Don't check for upgrades when restarting.
Remove --keep logic - only 1 old version is kept, only if make isn't available.
Old versions are availablel from the repo; if you have local changes, --upgrade doesn't make sense.
Can upgrade (or downgrade) to any tagged release with --experimental vx.yy
Note that GitHub API requests are rate-limited; this shouldn't be an issue
unless getssl is run more than ~60 times/hr. If the limit is exceeded,
getssl will sleep until the limit is reset. The limit is per-IP address.
The tests have been modified to only check for updates in the tests that
verify the check for updates logic. This has the side effect of not
doing MANY pointless checks for updates in the tests...
Document the accounts and repo-specific domain names required to run the dynamic DNS tests.
Also document the GitHub "secrets" that must be stored for CI testing to work.
The first fail logic seems scoped to a single test file.
Set the flag globally.
Since the tests run in a container, cleanup is automagic.
Various test tweaks to allow for skipping tests & null strings.
The test harness will suppress output unless an error occurs.
Upgrade testing was failing in forked repos CI because the
source repo was hard-coded. Use the CI environment to use
the fork's repo.