This repo contains a GitHub action to run code linters and report their findings on GitHub.
The currently supported code linters are:
- flakeheaven, using reviewdog to annotate code changes on GitHub.
This action was created from reviewdog's awesome action template.
For push events to the master branch:
name: linting
on: [pull_request]
jobs:
flakehell:
name: lint-runner
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: sailingpalmtree/lint@latest
with:
github_token: ${{ secrets.github_token }}
# Change reviewdog reporter if you need [github-pr-check,github-check,github-pr-review].
reporter: github-pr-review
# Change reporter level if you need.
# GitHub Status Check won't become failure with warning.
level: warningThere are three ways to test this action:
- The included test workflows will run some sanity tests.
- You can test the full flow of the Action with
act. - You can also test the steps the Action will invoke with a locally built
dockercontainer.
These are defined in test.yaml. One can further configure these, but you can see in mine how I set them up.
For this I used the tool act.
I saved the platforms I cared about in my ~/.actrc file:
-P ubuntu-latest=ghcr.io/catthehacker/ubuntu:act-latest
-P ubuntu-20.04=ghcr.io/catthehacker/ubuntu:act-20.04
-P ubuntu-18.04=ghcr.io/catthehacker/ubuntu:act-18.04
(note that you could pass these in on the command line too with -P)
In order to pass in secrets and other env variables to the action, I saved these in .env and .secret files.
(Don't forget to add these to .gitignore for obvious reasons)
act by default will read these files with these names but you can name them differently and pass them in with their flags.
Alternatively, you can pass them in on the act command line too.
I ran act with the simple act push command. Here, push was meant to simulate a GitHub push event. You can use any other event, and you can further configure them if you wish.
There's an included Dockerfile.testing that can be used to build a container identical to the one the Action uses when it's running. The only difference is that Dockerfile.testing doesn't invoke the entrypoint.sh script - instead it drops you into bash upon running the container. This is so that you can then manually inspect the contents of the container and run any commands you like, including the ones the entrypoint.sh script has. Naturally, you'll have to set the needed environment variables yourself in this case.
Example commands for the above:
docker build . -t linter -f Dockerfile.testing
docker run -it linter
# Inside the container
mkdir /tmp/devel
cd /tmp/devel
git clone <your desired repository>
python3.8 -m flakeheaven lintFeel free to modify the Dockerfile or the Dockerfile.testing, but always make sure they only differ in their entrypoint. In other words, running diff Dockerfile* should show only the following:
diff Dockerfile*
# [some line numbers here]
< COPY entrypoint.sh /entrypoint.sh
<
< ENTRYPOINT ["/entrypoint.sh"]
---
> ENTRYPOINT [ "/bin/bash" ]