[INFRA] Reduce the number of GitHub job runs

[tbouffard]

We have a limited number of GH hosted runners available at a given time (max 20). So we should review the current triggering configuration of workflows.

To limit the number of runners, we can use concurrency on the workflow syntax.
Also, see https://stackoverflow.com/questions/68418857/how-to-cancel-existing-runs-when-a-new-push-happens-on-github-actions-but-only.

Status

At least the following workflows shouldn't be triggered on every change:

✔️ npm-package

It was introduced with #2071 but we almost never used the produced package locally.

If we want to only test the build of the npm package: allow to run on on demand (workflow_dispatch) and limit run to changes to
- '.github/actions/build-setup/**/*' workflow defintiion dependency
- '.github/workflows/upload-npm-package.yml' the workflow definition
- 'package.json': prepack depends on it but very limited impact as it calls the build-bundles that is tested as part of the "build" workflow

We already build bundles as part of the "build" workflow, so we generate it only once.
We need type elements provides in the npm package to test the lowest TypeScript version that can be used with bpmn-visualization. #2258 add tests for that and they run in the workflow that build the npm package.

So I suggest we keep this workflow and let it run as today on each Pull Request.

✔️ build test_bundles

Currently, they run on 3 OS for chromium, chrome, firefox, on macOS for webkit and on windows for edge. So 11 jobs are run!

Do we need to test all browsers with all OS every time? probably not

• the npm package is only generated on Ubuntu during npm publish. We never publish from local machine, so we don't really care if it cannot work on other OS
• we do some minimal checks to verify that the SVG is correctly generated. If it works on Chromium, it means that the bundle includes all the code correctly. It may test that the bundle doesn't work in a specifig OS/browser combination but we never face this problem. So the benefits seems too small comparing to the cost.

So I suggest we run the tests as part of the workflow that check the generation of the npm package
In addition, #2272 requires that the whole npm package is built to make the tests pass

✔ test-e2e

They shouldn't been run when only the integration and unit tests code change. If needed, move shared utilities out of this 2 folders to a dedicated folder trigger e2e only when utility code changes. --> done in #2717

Other improvements: Setup concurrency + provide a way to skip tests on demand on PR by setting a label. #3197

Future changes and proposals: see #3196

✔️ performance tests

Note: done in #2717

Only run on PR when performance tests change
Review the schedule configuration to see if we can run them less often. This may be not needed if they run when there is no or few activity in the GH organization

Configuration for v0.27.0

    paths:
      - '.github/actions/build-setup/**/*'
      - '.github/workflows/test-performance.yml'
      - 'test/performance/**/*'

My suggestion: nothing to change

Decisions

npm package and bundle tests

2022-10-04 by @csouchet and @tbouffard

Based on the proposal

• Do not run "bundle tests" as part of the build workflow
• Only run "bundle tests" on Ubuntu with Chromium as part of the "npm package" workflow
• Gain: drop 11 jobs for each PR that runs the 'build' workflow!
• Keep running the "npm package" often as it checks the
  • npm package generation
  • minimal TS version to integrate bpmn-visualization
  • bundle tests

See #2284