In a prior commit, I mistakenly used "architecture: x64" instead of
"architecture: x86", and tests actually passed.
That was surprising, because netifaces do not have amd64_win will on
PyPI. But mystery was solved when itamarst pointed out that netifaces
wheel (that we previously built) is present on pip cache.
But pip cache might be purged one day, and tests will fail again that
day. We can't have that, so we will try to stick with x86 for now.
I can't figure out the correct GitHub Actions magic incantation^w^w
expression syntax that is needed to isolate (Windows && Python 2.7),
so let's just run also run x86 Python 3.6 on Windows.
Per GitHub documentation:
When you use expressions in an if conditional, you may omit the
expression syntax (${{ }}) because GitHub automatically evaluates
the if conditional as an expression, unless the expression contains
any operators. If the expression contains any operators, the
expression must be contained within ${{ }} to explicitly mark it for
evaluation.
https://docs.github.com/en/actions/reference/context-and-expression-syntax-for-github-actions
Another test matrix setup I tried is this:
jobs:
coverage:
matrix:
os:
- macos-latest
- windows-latest
- ubuntu-latest
python-version:
- 2.7
include:
- python-version: 3.6
os:
- macos-latest
- ubuntu-latest
- python-version: 3.6
os: windows-latest
experimental: true
But that failed on Python 3.6 + macOS with a simple error message, and
no further explanation: "This check failed". Huh?
Might simply exclude Windows altogether, because that approach sort of
worked in another experiment.
Following PR review feedback.
Some parts of GitHub Actions configuration follows convention in GA's
documentation, in which YAML strings are not quoted, but that probably
is not a good idea. We also don't want to change all the strings in
this unrelated set of changes. So we will quote strings as we go, in
the blocks we touch.
At the time of writing this commit message, GitHub Actions offers pip
v20.3.3 for both ubuntu-latest and windows-latest, and pip v20.3.1 for
macos-latest. Those are sufficiently recent pip versions that have
"cache dir" sub-command.
From pip 20.1+ onward, "pip cache dir" can be used to find location of
pip cache, and this is useful across all three major OSes supported by
GitHub Actions.
just looking for an excuse to trigger another build and see if inviting
"coveralls" to be a collaborator on LeastAuthority/tahoe-lafs fixes the status
reporting issue.
coveralls complained:
{"error":"No build matching CI build number 467026020 found"}
So try constructing a build_num that looks like the value we observed from
`coveralls` output when it was submitting coverage data.
* We stopped using Appveyor a while ago so entirely remove its configuration.
* There's no release step where coverage information is *examined* so why
collect it?
* Switch GitHub Actions config to py27-coverage tox environment
Integration tests are currently not run on Windows, because they
turned out to be a little unreliable: sometimes they fail, and when
that happens restarting the test would make things pass.
We will re-enable them and see what happens.
Per GitHub's documentation for on.release events, `on.release` event
will run our workflow any time the `release` event occurs, but it is
unclear if Tahoe will need this yet. Removing for now.
