I recommend separating the unit-tests/linting from the E2E tests. Since the unit tests do not depend on secrets, you can have a one-click approval to run them on public PRs if you separate them into their own Github Action file. That way you can see if a public PR at least passes unit tests before going through the process of making a branch in the local fork in order to run the E2E tests. Another reason to separate them out is that, because they are much cheaper to run, you can have different trigger conditions/exclusions.

Currently unit and e2e tests are running as a separate jobs, but in single workflow. It should stay this way in order to properly collect coverage data (each job emits own coverage report; separate job waits for test jobs, then retrieves all coverage files and sends them to codecov)

+ unit tests indirectly depend on secrets (coverage job needs a Codecov token stored as secret)

For my knowledge, where / how do these get used? It might be a pattern I want to pull into dbt-databricks.

I use this env here to have unique filenames for coverage reports from different jobs (e.g. coverage_e2e, coverage_unit_node16, etc.), and because that names are used in many places across the workflow file. Those files are later collected by another job which then sends them to Codecov. We cannot send them one by one, because in this case Codecov won't merge those coverage reports and just use the last submitted one