Github Actions

[General-Beck]

Check, test and build code in Actions CI
Scheme:

1. Check

• Ubuntu

2. Build Release Test Suite

• Ubuntu
• MacOS
• Windows

3. Run Test Suite

• Ubuntu
• MacOS
• Windows

4. Build Release Suite

• Ubuntu
• MacOS
• Windows

VM and environment variables

• Currently, Ubuntu 16.04 is used for compatibility with previous releases of Parity Ethereum. In the future, if necessary, you can switch to Ubuntu 18.04. During the transition phase, you can add ubuntu-latest to the matrix and test and build in parallel for the two versions.
• Windows Server 2019 (The latest version of clang is used)
• MacOS 10.15

Processes start after a push to the repository.

TODO

• Add cargo audit. github actions for cargo audit #11527
• Integrating sccache into processes to speed up compilation.
• Setup events that trigger workflows
• Settings and variables for publishing releases

[General-Beck]

Sum up. This skeleton can be used for work. In the future, we can and should expand the functionality. Add releases, nightly builds, publishing Docker images and more.
The first launch for PR will be slow (up to 3 hours), all further commits will be much faster due to caching.

[ordian]

Let's rename test.yml to check.yml, looks good otherwise!

[denisgranha]

In general looks very nice, good work @General-Beck !

I have a few open questions, considering the time it takes to execute right now the CI:

1. The build phase is the most time consuming one, instead of approaching this with sscache, couldnt we also do it with cached docker layers?
2. Im not a rust developer so my understanding of Rust build process is a bit limited right now. I think anyway right now we lack of some data to assess potential problems/improvements. Could we add timing inside the scripts to differenciate between: a) time it takes to download cache b) time it takes to download dependencies c) time it takes to compile the code

[ordian]

The build phase is the most time consuming one, instead of approaching this with sscache, couldnt we also do it with cached docker layers?

Note that that we only care about compiling tests speed for now, as building release artifacts will be only done on releasing a new version, which doesn't happen very often. sccache is the defacto standard of caching for large rust projects, and already compile time with cache are reasonable (<13 mins on macOS https://github.com/OpenEthereum/open-ethereum/runs/476907565). But if you have ideas how it could be improved with docker layers, PRs are welcome :)

Could we add timing inside the scripts to differenciate between: a) time it takes to download cache b) time it takes to download dependencies c) time it takes to compile the code

We already have a) and c)
a) is

• Cache cargo registry
• Cache cargo index
• Cache cargo build
• Cache sccache

c) is

• Build tests

b) is part of c) and negligible compared to compile times.

[denisgranha]

@ordian my bad, You are right that caching download, etc is already measured in time, I was looking for it inside the test build stage. I was asking for that because it would not be the first time I see it takes more time to download a cache than actually get all depedencies from scratch, it happened to me on travis due to the machine hardware they use.

About the docker layer caching, I don't know if it will improve times, it might be the same or worse, but I would like to test it. Not now, as I don't have capacity at the moment but in a next iteration of this.

So far looks very good, good job both @General-Beck @ordian

[roninkaizen]

excellent work from my point of view,
thanks a lot for having a comparison to my personal settings :)