WIP GitHub Actions for CI

[echeran]

@zbraniecki Here's my progress so far, in case you also play around on your personal fork.

• full instruction docs
• Cache action config for Rust - caching deps across builds for build speedup
• build matrix config doc - for having "parameterized" builds (multiple OSes, multiple runtime versions)

[srl295]

probably future but si there a way to refactor these caches into something importable with uses?

[echeran]

I'm not sure I understand. When you said uses, were you referring to a config key in the step of a workflow in the YAML file? That particular uses key just seems to hold the coordinates of the external action to invoke for that particular step within the workflow steps list.

The way that the Cache action works is interesting -- it hashes a file (for Rust, Cargo.lock) to know whether deps have changes or not.

I obviously just took the defaults for Rust - Cargo. But we can definitely try modifying if useful.

[srl295]

they are interesting… And I'm completely new to this, so just speculating.

Look at https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#example-using-action-in-the-same-repository-as-the-workflow - it suggests to me that we could move "Cache cargo registry" etc .to a separate file, and then just add: `uses: ./cache-cargo' ?

[echeran]

Ohh, yeah, I think relative path syntax applies if we had a special ICU4X action that we created in our repo, and wanted to invoke it from within this workflow. The standard coordinates refer to a public repo on Github. The last option is referring to an action defined in a Docker image on Dock Hub.

As I imagine it, most workflows would just take advantage of pre-written actions, as need be.
Github own the "github.com/actions" project, so actions/checkout refers to their github.com/actions/checkout repo. As I understand it so far, actions/checkout clones your repo code into the runner environment, actions/cache fetches previously cached deps to start with or else saves the new deps at the end of the run.

The blog post tutorial @nciric shared uses another pre-built action that loads multiple specific versions of Golang, which was useful for version compatibility testing purposes.

[srl295]

@echeran this can be a future refinement. the caching you're doing seems like it could be useful separately.

[srl295]

LGTM!

[zbraniecki]

LGTM!

[zbraniecki]

That looks good! Let's land this and then I can try to plug code coverage into it later :) Thanks @echeran !