Extract workflows from build
job to new lint
and test
jobs
#1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Related to #1807. Pull requests into master have been experiencing build failures. These failures are due to errors thrown by commitlint. This PR aims to make the
linting
process of the CI pipeline more explicit so contributors can more easily identify issues with their code.Description
This PR divides the current monalithic 'build' workflow (
build.yml
) and job (build
) into a development workflow (development.yml
) with distinct 'build and test' and 'code standards' jobs. To make the workflow names consistent,npm-publish.yml
has been renamed torelease.yml
, and has a dependency ondevelopment.yml
running prior to publishing the package(s) within thepublish-npm
job.Changes in the codebase
build.yml
todevelopment.yml
npm-publish.yml
torelease.yml
npm run bundle
,npm run bundle-min
,npm test
), and 'code standards' (withnpm run commitlint
andnpm run lint
)build-test
/Build and test
)Additional information
The ideal setup was to have separate workflow files for linting, building, testing. Separate workflow files would show up as separate 'checks' on the main page of the PR, which would make failures immediately obvious. However, it's very difficult to get these workflows into separate files without lots of complicated dependencies, repetitive actions and storing of build artifacts, which creates unnecessary computational overhead. The approach taken here to at least create distinct jobs within the workflow files makes it easier to see the jobs within the PR checks tab at the very least, rather than just 'build failure'.
Screenshots
Some screenshots illustrating visibility of CI flows.
Before
After