I intentionally put this in a separate job as it's not fast, and it blocks all the remaining jobs such as the app and UI building even though they don't need this. We can still use the conditions to skip the steps when running in a release though, and even create a command to avoid duplicating the conditions.

My thinking was that as the e2e tests depend on both build App, build UI and build Extension, they indirectly pending on the install. The upside of splitting could be a very small performance improvement (in case the ui and app build would take longer than the extension build.. which is not the case btw).
Then the downside is If we split this job into two, we would make the workflow more complex. I believe we would need this:

• have a command to run the setup extension + recreated lavamoat policies
• have a job that runs and echo script to just run something and then would run the previous command created if certain conditions are met.
• update the test_and_release workflow and add the previous job as required for the build-extension-* jobs. (We need the echo script on the previous job in order for the job to run something successful and be considered complete. Otherwise the build-extension-* jobs would never start)

Is it worth sticking with environment variables for configuration, just for readability and consistency? At a glance we don't know what this means plus an env is a little more flexible as it can be defined at any level.

Ah dam.. I left that on the package workflows, but I'll remove it (there's no need for that step on the package workflow as there's nothing to setup on the extension). Then the flags is just for dev, but yeah I can replace it with an env var. Makes more sense 👍

❤️