ci: a new prep-deps workflow with caching

[HowardBraham]

Description

Major changes

• prep-deps
  • There's a new workflow that parallels the CircleCI workflow. prep-deps runs first and caches the result, then prep-build-test-webpack makes an artifact, then the benchmarks run.
  • Several of the existing workflows were changed to now depend on prep-deps
  • Many of the file changes are just using the new setup-environment@caching and deleting the independent "Checkout repository" step
• vars.USE_CACHING
  • This allows us to toggle the caching feature on and off in a centralized way. I left instructions as a comment in main.yml for how to toggle it. We can discuss implementing this in a different way, but passing this variable through different workflows is actually kind of a pain (that's the first way I implemented it). Several of the jobs are 30-60 seconds faster when this is turned on.
• test-short-suite
  • I think this could be slightly controversial, but I think it's for the better.
  • I noticed that there were 7 individual really short tests, that each ran on their own VM. Each VM instance took about 1m30s to execute. I combined these together into a single VM that runs all the short tests in sequence, and takes about 1m20s combined. The if: always() statements make all independent tests run, even if one fails.
  • The 7 jobs were: test-lint-shellcheck, test-lint-changelog, test-lint-lockfile, test-deps-audit, test-yarn-dedupe, test-deps-depcheck, validate-lavamoat-allow-scripts
  • If this were running on VMs that cost money, this would be a no-brainer. As is on GitHub runners, it doesn't really cost us any time or money. All we can really say is 7 separate jobs burn fossil fuels for a slight bit of convenience in terms of seeing individual test failures in the GitHub PR page.

Prerequisites to merging this PR

• Depends on ci: self-hosted runners for benchmarks #29955
• Merge this caching branch of github-tools: https://github.com/MetaMask/github-tools/blob/caching/.github/actions/setup-environment/action.yml
• Change setup-environment@caching back to setup-environment@main

Related issues

Split off from: #29955

[github-actions]

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

[metamaskbot]

Builds ready [1283bfe]

• builds: chrome, firefox
• builds (flask): chrome, firefox
• builds (MMI): chrome
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6, 7
  • common: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • ui: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
  • content-script: 0
  • offscreen: 0

Page Load Metrics (1641 ± 69 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	1406	1928	1642	145	69
		domContentLoaded	1398	1902	1620	139	67
		load	1407	1926	1641	144	69
		domInteractive	21	118	38	24	11
		backgroundConnect	10	63	24	15	7
		firstReactRender	15	101	36	24	11
		getState	4	79	19	21	10
		initialActions	0	1	0	0	0
		loadScripts	998	1388	1177	115	55
		setupStore	6	63	16	16	8
		uiStartup	1586	2435	1885	200	96

[NicholasEllul]

Left one question & reviewed usage of caching from a security POV. No concerns from our end. I'll let the others chime in with regards to reviewing the functionality

[NicholasEllul]

What was the background behind choosing an env variable over harcoding?

[HowardBraham]

Pro: It's way fewer lines of code to do it this way. Setting a variable in main.yml and passing it in to a bunch of workflows is harder, much less clean, and easier to accidentally mess up.

Con: You lose some control and repeatability of workflows.

I'm kind of in a divided mind myself.

[NicholasEllul]

Ah I see what you mean. Other than slower performance due to the extra yarn install, are there any issues if the settings were accidentally set out out of sync?

I suspect most of the time we will want caching for these, and only in the odd case we may set a couple workflows to be false. In which case ${{ vars.USE_CACHING }} could be seen as being synonymous to true (but with a var that can be flipped without going through the peer review flow).

[HowardBraham]

If prep-deps had USE_CACHING set to false, and later steps had USE_CACHING set to true, it would be a problem.

[NicholasEllul]

Change setup-environment@caching back to setup-environment@main

(Not blocking) Are there plans to version changes? While for now pointing directly to the main branch allows for immediate updates, it can result in challenges down the road if a breaking change is introduced. Could be handy to have things set up now to save time in the long run.