Don’t you feel frustrated when you make a trivial change in your codebase, like editing some text using the web editor…:
…or bumping some dependencies…:
…only to see your CI build failing because of reasons like these?:
- Prettier doesn’t like it that you don’t wrap lines at 80 characters:
- You forgot to update your test snapshots:
- You didn't run
yarnto update the lockfile:
- Other trivially fixable errors:
I get very annoyed when issues like this happens. It’s important to put in checks to keep things tidy and ensure coding style is used consistently. But perhaps we can make it a bit less annoying…
I was once on a large codebase where running the linter and the tests takes 5 minutes. When I make simple changes that breaks any formatting or any snapshot, I lose a lot of time: 5 minutes to know that there’s a problem. 5 minutes to run
eslint --fix or
jest -u and commit+push the changes. And 5 more minutes to verify the fix on CI.
While it’s important to speed up the CI builds, why not also let the CI generate a patch file that you can instantly apply on your branch?
(Before) Instead of simply running checks and failing the build…:
- run: yarn --frozen-lockfile - run: yarn lint - run: yarn test - run: yarn prettier --check .
(After) …we let GitHub Actions try to fix the auto-fixable problems…:
- run: yarn --no-immutable - run: yarn lint --fix - run: yarn test --updateSnapshot - run: yarn prettier --write .
…then we stage the changed files and finally use the Patch Generator action (newly created for this hackathon) to generate a patch command:
- run: git add --update - uses: dtinth/patch-generator-action@v1
When this workflow is run and there is any auto-fixable changes, Patch Generator will generate a shell command that you paste into your local machine to instantly apply the required changes. It also works with binary files. And if the changes are too big, you can download the patch file from the build artifacts and apply using the
git apply command.
Finally, you can also review the diff from the actions log to see what would happen when you run the above command.
People can fork and modify the action without having to install any build tool or go through any build steps. Development for this action mostly happen in
github.devwithout any other build tooling.
Since composite actions uses the same syntax as a workflow, people can also yoink the action code, and put them directly in their workflow files, if they so choose.
I am using the workflow in these open source projects:
- Bemuse (Rush + markdown-toc + ESLint + Prettier; workflow file)
- Fresh App Factory (Yarn + Prettier; workflow file)
- Patch Generator Action (Itself!) (Prettier; workflow file)
The action is released under the Unlicense, i.e., into the public domain.