Test Using Github Actions

[ryanio]

This is a test PR to try out converting from Travis to Github Actions (web3#3393).

This PR:

• Updates all travis references to GH Actions.
• Verdaccio: adds yarn as a fallback upstream proxy.
• Coveralls: removes dev dep in favor pushing to Coveralls through GH Actions.
  • Benefits: coverage reporting on forks, one less dev dep

[cgewecke]

Hi @ryanio! This is super cool :)

Windows passes which is fantastic. Also looks faster.

Historically, only the mosaic_e2e has had intermittent timeout problems - they seem yarn specific. In Travis, you could usually get installation to complete by restarting that specific job, but sometimes it really struggled. Might be network congestion?

Have also treated mosaic_e2e and ganache_e2e as "allowed failures" (Travis supports this). They're meant to be conveniences to let you see if changes might be problematic downstream rather than strict requirements.

For example, in web3#3190 - the ganache job always errors because those changes flushed out a bug in one of their unit tests... but that shouldn't block the PR. Conversely in web3#3378, the mosaic test failure shows that the changes break an environment which injects an ethereum provider into the global namespace. They're sort of only meaningful case by case.

One approach might be to move those two runs into their own "job" and set continue-on-error: true, allowing them to pass even when there are problems. And perhaps we could modify the Github PR template to have a reminder in the checklist that those two jobs can/should be manually checked.

Another possibility is to leave them in Travis as allowed failures and have two CI providers. That might be the simplest thing, idk.

[ryanio]

@cgewecke gotcha, thanks for the helpful additional info!

Looks like an easy solution will be to use:

- run: bash ./scripts/ci.sh
  continue-on-error: ${{ matrix.testCmd == 'e2e_ganache' || matrix.testCmd == 'e2e_mosiac' }}

And with that... everything is passing! 😯🎉

One side question, is there a prettier config for web3.js? For example in EthereumJS repos we have npm run lint:fix that ensures everything is prettified as a pre-push hook. My diffs in this PR have some changes because my editor is set to automatically format prettier on save (huge productivity gain) but I don't see a prettier config in the root.

[cgewecke]

everything is passing

Yes! That's awesome.

Interestingly, the ganache job (npm) is timing out now and I don't think I've seen that before...it was always yarn before.

How do you re-run a job in Github actions? I don't see retry button in UI on my side, is it there for you?

is there a prettier config for web3.js

No there isn't - the project is effectively unlinted - the only rule is no-trailing-whitespace.

Not sure how difficult it is to disable it in the text editor but yes the diffs here get really mangled if it's done on automatically on save. We've talked about linting the project in a single sweep or set of PRs that don't change any logic, essentially every file would have changes.

[ryanio]

Interestingly, the ganache job (npm) is timing out now and I don't think I've seen that before...it was always yarn before.

I haven't been able to get the ganache job to pass fully yet. It always gets caught after

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Installing updated web3 via virtual registry 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

with Error: connect ETIMEDOUT 104.16.20.35:443

I tried a handful of things like increasing retries and timeouts and using yarn registry instead of npmjs but nothing worked yet. I'll keep thinking or tinkering around with what it could be.

How do you re-run a job in Github actions? I don't see retry button in UI on my side, is it there for you?

Yeah it is because we're on my fork, it is normally in the top right header like this:

If you want you can try to open this branch as a PR on your own fork and see if you can control the actions (that would be pretty cool).

Not sure how difficult it is to disable it in the text editor but yes the diffs here get really mangled if it's done on automatically on save. We've talked about linting the project in a single sweep or set of PRs that don't change any logic, essentially every file would have changes.

Ok no problem, yeah it's a tough transition (but worth it imo!). I'll remove all the unnecessary formatting so the diff is clean with just the important changes.

Thanks!!

[cgewecke]

Stumbled upon a small problem with this pattern matcher during #2...

If the branch name has a slash in it - e.g issue/3112, BRANCH will be set to 3112 and not get found.

[ryanio]

Ah good catch, ok I’ll have to dig into some more bash syntax to learn how to extract it properly (* after 1st or 2nd slash?)
Let me know if you have a suggestion.

[cgewecke]

Peeked at the env vars in CI and it seemed like GITHUB_HEAD_REF is the extracted branch name. Maybe you just get this for free?

I tried

• PR into local branch
• PR from fork
  .. and both were routed through this refs/pull/ clause. Is the other clause for push builds?

[ryanio]

Interesting, I was under the impression that head ref was only populated for PRs from forks, but if what you said is true then that’s great and makes it easy :)
It might not be there for push builds though as you mentioned, so it would be worth trying and see what the value is.

[cgewecke]

@ryanio

head ref was only populated for PRs from forks

Yes, that's what it says in the GH Actions docs...mmm.

[ryanio]

Attempted fix in 7297b53

[github-actions]

Pull Request Test Coverage Report for Build 0a4f8537ba1c558e6713129d0046f0df234340d3-PR-1

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 86.464%

---

Totals
Change from base Build 3:	0.0%
Covered Lines:	2719
Relevant Lines:	3069

---

💛 - Coveralls