Evaluate use of Cache vs Artifacts in workflows

[hawkrives]

I've been doing more reading, and it seems like a simple test to determine if something should be a cache or an artifact is:

is it shared across workflows, or is it only shared within one workflow?

If it's shared between workflows, it should be a cache.

If it's only used within one workflow, it should be an artifact.

---

I guess that our caches are really "per-branch"? Or just "per hash," right? I designed them fox maximum safe sharing. So the stuff should probably all remain in cache.

It might be nice to upload the jsbundle and generated app as artifacts, too, for debugging? At least until GitHub gets around to letting you download caches from the UI!

---

Trade offs:

•	Cache	Artifact
Expiry	Unlimited?	90 days (after last commit to a PR?)
Size	20GB	Unlimited?
Name	User-controlled	GitHub-controlled
Referencability	If you know the name	Only within that workflow, by reading the output of an action

---

I'm posting this so that I'm not just carrying this info around in my head.

Action items?

• Evaluate which steps should publish artifacts (probably not the dependency caching steps)

[hawkrives]

I had a few realizations:

There's no point to storing the bundler cache as a separate artifact, since it's only used by one job per platform.

There's no need for separate cocoapods or gradle caching jobs; just shove them into the respective native build jobs, after the .app/.apk check.

We will have significantly less cache pressure if we only write to our caches from trunk.

So here's an updated set of flowcharts about how data can flow in our build pipelines. All data flow below will happen through artifacts, instead of caches, with the exception of trunk, who will write caches of the current state.

---

The job "npm" is meant to unpack the global ~/.npm cache into $root/node_modules, then store that as an artifact for later use.

TODO: Should trunk store the "npm" node_modules folder as an artifact, too, to avoid this job having to unpack on each branch? Maybe… need to test!

The {ios,android}.app jobs will either download the binary from trunk's cache or build the app itself, then store the resulting .app/.apk as an artifact.

The {ios,android}.bundle jobs will either download the bundle from trunk's cache or generate the bundle itself, then store it as an artifact.

Finally, the e2e jobs download the .app/.apk and .jsbundle artifacts from the earlier jobs, insert the .jsbundle into the .app/.apk, and kick off the e2e tests, uploading any e2e artifacts that they create.

graph TD
    npm --> eslint
    npm --> tsc
    npm --> jest
    npm --> ajv
    npm --> prettier

    npm --> ios.app
    npm --> ios.bundle

    npm --> android.app
    npm --> android.bundle

    npm --> e2e.ios
    ios.app --> e2e.ios
    ios.bundle --> e2e.ios

    npm --> e2e.android
    android.app --> e2e.android
    android.bundle --> e2e.android

Loading