Description

• Remove caching around yarn install to reduce bitrise build times by approximately 1m46s.
  It is a "quick win" until a decision is made on a caching strategy.
• Add caching of node_modules specifically to e2e tests: The end-to-end (e2e) tests on Bitrise leverage caching to ensure that artifacts generated during the build stage are available during the test stage for runtime. Without this caching mechanism, we would arrive at the test stage without the necessary components for a fully functional runtime.
  Passing pr_smoke_e2e_pipeline
  Passing pr_regression_e2e_pipeline

Background and discussion in this internal document, but the gist is:

• @Gudahtt highlighted that a restored node_modules directory does not guarantee a fully functional environment due to potential modifications by dependencies' lifecycle scripts outside of node_modules.
• Furthermore, the current approach to yarn cache management results in a net-negative impact, as loading and saving the cache takes longer than the time saved by yarn install.
• By eliminating caching, the code_setup workflow duration decreases from approximately 5m29s to 3m53m.

Related issues

Fixes: https://github.com/MetaMask/mobile-planning/issues/1512

Pre-merge author checklist

• I’ve followed MetaMask Coding Standards.
• I've clearly explained what problem this PR is solving and how it is solved.
• I've linked related issues
• I've included manual testing steps
• I've included screenshots/recordings if applicable
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.
• I’ve properly set the pull request status:
  • In case it's not yet "ready for review", I've set it to "draft".
  • In case it's "ready for review", I've changed it from "draft" to "non-draft".

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.