DIDKit Feature request: [FEATURE] Faster CI build and test times

[wyc]

Is your feature request related to a problem? Please describe.
I'm frustrated when the CI test suite takes 30m to run, but I do appreciate how extensive it is across different platforms.

Describe the solution you'd like
Faster CI build and test times.

Describe alternatives you've considered
Host our own runner? Parallel runners?

[clehner]

Some ideas…

Parallelize

Some parts of the workflow may be parallelizable. Probably not the cargo build commands, but maybe some of the tests. I think the needs keyword can be used to express dependency between jobs, which may allow for some jobs to run in parallel that are depended on in separate dependency paths.

Downsize

We could remove some parts of the CI. The old vc-http-api test is superceded by the v0.0.2 one. Cross-compiling for all Android targets could be skipped or changed to compile for just one target.

Fork to background

Make some operations run asynchronously, e.g. on our own servers, so that they don't block the CI workflow but instead run in the background and send some notification upon completion.

Periodic workflow

Set up an additional workflow for running manually, periodically, or in preparation for releases. e.g. a nightly or weekly build.

We could pick some soft maximum time for CI execution for PRs and/or for main. Operations that would need more time go instead in the separate workflow to be run manually/periodically.

Cache more

Fixing caching of rust build artifacts (target/) is in progress in #112. This reduces cargo build times, but also adds time to save and restore the cache. target/ is very large, in part because of cross compiling and building for configurations. There may also be savings from caching other files like node_modules for tests using Node.js.

Self-hosting for incremental builds without cache

Incremental builds without overhead of saving and restoring cache may be possible by building on one of our own servers, where target/ can persist on the filesystem between runs. Cargo and make are supposed to allow incremental builds, automatically detecting what needs to be rebuilt. Running on our own server could be done possibly with a self-hosted Actions runner, or by triggering the remote operation in the existing environment with our own kind of runner. Running automatically on our own server would introduce a security consideration of what code could be running, authored by who, with access to what:

• https://docs.github.com/en/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories
• https://docs.github.com/es/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners

[w4ll3]

For sure what takes most of the time is the building process, but in my opinion we shouldn't try to evict that since it's something that should be tested too, so I'm against of reducing the number of targets for Android, but I do agree that we could run all targets tests in parallel after target/ is generated, even Android could run its build alone.

[sbihel]

With the self-hosted runner for Intake, I found that the cargo build puts all 4 cores at 100% -- so I'm not sure how much time we would gain by parallelising. Caching and making use of the incremental compilation would be our best shot in my opinion.