-
Notifications
You must be signed in to change notification settings - Fork 2
Description
@ijlee2 proposed that we should run more jobs in parallel:
- I believe, currently, the workflow uses parallelization in the following manner. Step 2 can occur only when Step 1 succeeds, Step 3 only when Step 2, etc.
1. lint 2. test, floating-dependencies 3. try-scenariosFor addons (public repos, free of charge), a maintainer may want to run everything in parallel:
## An alternative 1. lint, test, floating-dependencies, try-scenarios ## Another alternative 1. lint 2. test, floating-dependencies, try-scenariosJust something to consider. slightly_smiling_face
For more context see jelhan/ember-style-modifier#32 (comment), jelhan/ember-style-modifier#32 (comment) and jelhan/ember-style-modifier#32 (comment).
The TravisCI configuration created by Ember CLI addon blueprints run the jobs in two stages:
lintandtest, which is even run in the same job.- Floating dependencies and ember try scenarios.
Not sure if we should aim to replicate that or run everything in parallel as we don't have constrains on CI minutes.
GitHub Additional Product Terms include a section about GitHub Actions, which forbids "any activity that places a burden on our servers, where that burden is disproportionate to the benefits provided to users". I think we can argue that having quicker CI results and getting detailed failure reports for all scenarios even if linting or default tests are failing, may outweigh the additional load on the servers.
Not sure if it may speed up overall executing time if one quick job (lint) prepopulates the dependency cache for all following jobs. This may also only be the case if dependencies are changed in the pull request. Otherwise cache may be prepopulated before by runs for other pull requests or master branch.