Description

It seems like the lavamoat-viz usage in CI has been broken since #12702. The create-lavamoat-viz script is silently failing on develop:

+ npx lavamoat-viz --dest ./build-artifacts/build-viz/

[Error: ENOENT: no such file or directory, open 'lavamoat/browserify/policy-debug.json'] {
  errno: -2,
  code: 'ENOENT',
  syscall: 'open',
  path: 'lavamoat/browserify/policy-debug.json'
}

Changes

• ci(create-lavamoat-viz): Remove use of npx (undeterministic) and call the devDependency of lavamoat-viz
• add lavamoat:debug:webapp package scripts which is to lavamoat:debug:build what lavamoat:webapp:auto is to lavamoat:build:auto (that is, it produces LavaMoat policy-debug.json files alongside the browserify policy for each build type)
  • Added these to .gitignore to avoid this increasing contribution overhead.
• ci(create-lavamoat-viz): Fix invocation to lavamoat-viz to correctly generate for build-system
• ci(create-lavamoat-viz): Extend to also generate and visualize runtime LavaMoat policies just like for build policy

Related issues

• Fix viz LavaMoat/LavaMoat#984
• investigate and (maybe) re-enable lavamoat-viz in job-publish-prerelease #23704

Manual testing steps

1. Run yarn build:dev dist
2. Run .circleci/scripts/create-lavamoat-viz.sh
3. If you have plenty of RAM and CPU you can speed it up by removing the --parallel=false option to yarn lavamoat:debug:webapp
4. Open build-artifacts/build-viz/index.html in web browser
5. Contemplate who maintains all these packages

Screenshots/Recordings

Before

N/A

After

Firefox (build-system)

Chrome (flask)

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.