Test workflow has some false-negatives

[philclifford]

The excellent testing workflow thanks to @OhMyMndy seems to have some "false negative" failures that need a tweak or two.

Now it may well be that there is a valid failure of #449 I'm unable to spot, which still fails today. (Edit: found and fixed, and replaced with #457 , which works but is ugly and less readable )

But trying to "fix" that over recent days I stumbled into a few types of apparent false-negative "failures" , including:

• API rate-limit (fixed in #457 ) causing temporary failure because the cache update is rejected
• running the tests on debian needs to skip/pass rejected ppas if a test install is ppa-sourced
• if the test app is already installed the nothing-to-do exit does not count as a + so the exit check fails (sse https://github.com/philclifford/deb-get/commit/254782c08077f7d8c05810b44f7d0ede9e1dbc76 and https://github.com/philclifford/deb-get/commit/8d56f73751ef3449e9e18736852849ce76b4a2fd for a workround)

compare my testing ,mainor auth-github branches and e.g. this revised multi-OS workflow for some of the head-banging and some possible fixes for some of the above,

Getting to #457 also suggests that it would be wise to ./deb-get clean >/dev/null before the test installs (or in the prior stanza) to be sure to start them with a cleared cache

[philclifford]

Also: should install tests be run if only README or other Documentation is touched? Maybe another workflow for docs or just limit jobs by file(s)

[OhMyMndy]

Makes completely sense to increase the counter when it is up-to-date, didn't think about it when implementing that...

In bin-get I made sure that before running an installation (in the tests), the program isn't installed, but that wouldn't have worked out in this case.