GitHub CI-CD javascript workflow
Features
This workflow includes common continuous integration/deployment tasks you can easily reuse for any web javascript project.
It includes:
- collaboration comments
- quality tests
- deployment on Netlify
- audit with Lighthouse
It works on push and pull request situations.
To showcase this workflow, i chose the Dojo RealWorld implementation.
My Workflow
Collaboration first!
Alone we can do so little; together we can do so much. Helen Keller
Open source contributions are not just about code. That’s all about people collaborating to move a project forward.
If the contributor is making their first pull request to the project, welcome them accordingly. First open source contributions can be overwhelming as there so many considerations: code of conduct, license, guidelines…
Even if GitHub makes it easy by onboarding new contributors when they land on a project, don’t hesitate to provide additional context:
I’m not a new contributor! Who cares?
Not being a new contributor doesn’t mean you should be ignored. As a review can be delayed, provide an instant comment to welcome new contributions. Even an automated one shows how much you care:
Reusable workflows
When i started this workflow, i used actions/cache
to cache dependencies and speed up the workflows.
Meanwhile i discovered some changes happened to actions/setup-node
in July, removing the need of the previous boilerplate
Time to refactor? Not so much!
Such change didn’t affect my workflow as such implementation detail was already hidden in a dedicated and reusable job by using the GitHub new feature: Reusable Workflows
This reusable workflow is isolated in a dedicated repository.
Automate quality checks
Note: The quality checks use the previous reusable workflow
Make your code Prettier
Prettier is a famous code formatter. It removes all original styling* and ensures that all outputted code conforms to a consistent style.
Ensure maintainability with a linter
ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code, with the goal of making code more consistent and avoiding bugs.
Quality means doing it right even when no one is looking. Henry Ford
The future yourself will thank you for being able to push code with confidence thanks to tests.
Deployment
You don’t want to manually deploy anymore.
Review changes before they go live!
You want to preview changes due to a pull request. Netlify provides a preview feature for such a need! By running this job on a pull request, a preview url will be created.
It uses a reusable workflow once again:
Push to production!
By pushing code directly or by merging a pull request, this job will deploy a new version of your web app.
It uses a reusable workflow once again:
Audit
Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.
By pushing changes to your repository, it shouldn’t affect performance and common best practices.
The workflow includes 2 jobs for such a need:
- a preview one for the custom preview url (related reusable workflow)
- a live one using the production url (related reusable workflow)
Are we really done yet?
Open source contribution requires to spend significant time on it as you need to:
- understand its goal to ensure your contribution will match
- to read all guidelines
- to wait for a review before your contribution
Such dedication on a project worths to greet the contributor, not to just merge their work.
But…there is no pull_request merged event. To identify a merged content, you need 2 informations:
- the event (push)
- the merged status of the pull request
Here is the solution i used in a dedicated workflow:
Submission Category:
Maintainer Must-Haves
Yaml File or Link to Code
Workflow YAML Files:
Additional Resources / Info
GitHub Actions used:
- actions/checkout
- actions/setup-node
- actions/first-interaction
- kerhub/saved-replies
- treosh/lighthouse-ci-action
- kamranayub/wait-for-netlify-action
- nwtgck/actions-netlify
GitHub Reusable Workflows created: