MacOS report uploaded!

@alalazo see #14236
Spack test will need to be run with

spack test --basetemp /tmp/spack

on macOS once gnupg2 is found correctly.

There's another thing we need to understand before merging this PR:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

The sentence above can be found here and it's not completely clear to me what does the emphasized part mean.

The previous PR #13826 couldn't upload to codecov because it couldn't find the appropriate secret token. That's reasonable, since from a forked repository I submitted a PR that was trying to use a secret of this repository. I wonder though what happens if we were to merge this in the case of a normal PR that doesn't touch the workflow file but comes from a forked repository - which is fairly normal on Github. If they can't use the secret token to upload to codecov it would be a major pain point.

EDIT: Main issue to track for codecov action codecov/codecov-action#29

To follow on the previous comments we might have an answer:

• unable to upload coverage report codecov/codecov-action#43 (comment)
• Passing secrets.CODECOV_TOKEN not recognized codecov/codecov-action#44 (comment)

It seems this PR needs to wait for early 2020 to be merged, see codecov/codecov-action#44 (comment). Before a tokenless upload to codecov is implemented all the forks need to store the same secret as the upstream repo in order to upload coverage which is definitely less than optimal.

Note there's an issue open for passing secrets to forks. It's marked as "solved" but really means "won't fix".

@tgamblin For convenience a few references as we were discussing this topic offline:

• Permissions given by the GITHUB_TOKEN
• Permissions required to Apps to make API calls

GITHUB_TOKEN is the only secret passed to forked repos and it basically gives read/write permissions on a lot of stuff if it comes from THIS repo and only read if it comes from a fork. Note that we are not using it in this workflow and my understanding is that it will be useful for us only if we start having workflows that e.g. merge or label issues and PRs automatically (see for instance what you can do with the "contents" permissions).

Currently the only way to have this PR work seamlessly also for forks is to expose the token from codecov in the YAML file - since there's no option at the moment to authenticate with codecov from a fork and preserve our secret codecov token at the same time. The risk is that anybody will in principle be able to upload xml reports to our codecov. Let me know if you want to proceed with that or if we should wait until the codecov guys work on a tokenless integration with Github Actions (the same way they are doing with Travis).

I tried to update this PR since the homepage of codecov/codecov-action now says:

For public repositories, no token is needed

We have another issue to investigate though. It seems that due to a setup specific to Github Actions tests that use capfd to capture output fail and apparently all the output is sent directly to stdout and stderr instead of being captured.

@tgamblin @ax3l Ready for a review!