@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.
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.
@ijlee2 proposed that we should run more jobs in parallel:
For more context see https://github.com/jelhan/ember-style-modifier/pull/32#issuecomment-735256781, https://github.com/jelhan/ember-style-modifier/pull/32#discussion_r532059470 and https://github.com/jelhan/ember-style-modifier/pull/32#discussion_r532074120.
The TravisCI configuration created by Ember CLI addon blueprints run the jobs in two stages:
lint
andtest
, which is even run in the same job.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 ormaster
branch.