Check Echidna publishing results for failure or success #1821
Conversation
|
Hm, I forgot that secrets aren't passed to PRs that come from forks. It's a bummer that Echidna requires a token even for dry runs. |
|
The current version of the workflow can use either the Echidna tokens (stored as a secret on WebAssembly/spec) or personal W3C username/password (which are handy for testing in forks, since anyone can put their own credentials as a secret in their own fork). Unfortunately even if a user has their W3C account info in their fork, it still doesn't get passed to workflows in PRs against upstream. I haven't yet figured out a way to get user credential information into PRs against upstream (we can't get and don't want our echidna token exposed to PRs from random forks). |
dschuff
requested review from
rossberg,
sideshowbarker and
Ms2ger
and removed request for
rossberg and
sideshowbarker
.github/workflows/w3c-publish.yml
Outdated
| W3C_ECHIDNA_TOKEN_CORE: ${{ secrets.W3C_ECHIDNA_TOKEN_CORE }} | ||
| W3C_ECHIDNA_TOKEN_JSAPI: ${{ secrets.W3C_ECHIDNA_TOKEN_JSAPI }} | ||
| W3C_ECHIDNA_TOKEN_WEBAPI: ${{ secrets.W3C_ECHIDNA_TOKEN_WEBAPI }} | ||
| YARN_ENABLE_IMMUTABLE_INSTALLS: false | ||
| ECHIDNA_DRYRUN: ${{ github.event_name == 'pull_request' && github.repository == 'WebAssembly/spec'}} |
There was a problem hiding this comment.
I'm confused, why do a dry run when it is a PR against the main repo? Shouldn't it be the other way round? In fact, shouldn't it be a dry run unless it is an actual push against the main repo?
Also, this flag is set for the WD-echidna-CI target, but in two of the makefiles it's only used by the WD-echidna target.
There was a problem hiding this comment.
ah oops, I made it supported in more places, changed the default in the Makefile to true, and inverted most of the logic after it was originally written, but missed this.
Yes, it should be a dryrun for every case other than a push in the WebAssembly repo. Maybe I'll also add a condition on the branch name, just in case we find it useful for testing other branches in the future.
There was a problem hiding this comment.
Note though that as I mentioned yesterday, this doesn't actually work at all yet for PRs against upstream that originate from a fork, because those don't get repository secrets from either the source or the destination repo.
The API call does not return its results synchronously, so the script polls for the result and
exits with an error if it fails.
This PR also introduces the ability to run the publishing step as a dry run, so it can be
used with pull requests.