3 Simple Ways To Get Started With GitHub Actions | by Ashley Peacock | Feb, 2022

Linting permits you to mechanically verify your code for programmatic and stylistic issues. Code is far simpler to learn if it’s written in a constant method, so linters intention to supply a constant type on your code.

Working code linting earlier than a PR is merged to the principle department is a wonderful use case for a GitHub Motion, and it’s tremendous easy to do! Right here’s how I did it for a Ruby repository:

identify: Ruby

on:
pull_request:
workflow_dispatch:

jobs:
lint:
runs-on: ubuntu-latest
steps:
- makes use of: actions/checkout@v2
- identify: Arrange Ruby
makes use of: ruby/setup-ruby@v1
with:
ruby-version: '2.7.1'
bundler-cache: true
- identify: Run Rubocop Linting
run: bundle exec rubocop

GitHub Actions are outlined utilizing YAML. As that is the primary GitHub Motion we’re , I’ll run by step-by-step:

identify: Ruby

Beginning off straightforward, that is the identify for this explicit GitHub Motion.

on:
pull_request:
workflow_dispatch:

Subsequent, we outline which occasions ought to set off the GitHub Motion. On this case, we’re selecting to run this motion at any time when a pull request is opened, reopened or dedicated to. These are the defaults, however you may set off occasions on quite a few occasions associated to tug requests, which you’ll see .

The second occasion we specify is workflow dispatch, which permits us to run the motion manually from the Actions tab for the repository. I discover this notably helpful when testing an motion.

jobs:
lint:
runs-on: ubuntu-latest

Now that we’ve outlined when the motion ought to run, we will specify what the motion ought to do. Actions are damaged down into jobs (you may outline a number of per motion). On this case, now we have one job — named lint — and we should outline what surroundings to run the GitHub Motion in.

I’ve chosen Linux, however Home windows and macOS is accessible too. These runners are all hosted by GitHub, making them very accessible to everybody, however if you happen to want extra highly effective runners, or require particular {hardware} or instruments, you may .

- makes use of: actions/checkout@v2
- identify: Arrange Ruby
makes use of: ruby/setup-ruby@v1
with:
ruby-version: '2.7.1'
bundler-cache: true
- identify: Run Rubocop Linting
run: bundle exec rubocop

Every job can have a number of steps, outlined as a listing. Most actions will at all times begin with the checkout motion, which is constructed by GitHub, and it’ll take a look at your repository into the runner.

Then we get into the specifics of this motion. First, we should set up Ruby, which once more there’s a pre-configured motion out there to make use of. We will cross parameters to actions, such because the Ruby model for this one. The bundler-cache parameter will set up dependencies (gems in Ruby).

Lastly, we will lint our code. Rubocop is a linter for Ruby, and as soon as run, will both produce a 0 exit code (success) and the motion will cross, or exit code 1 (failure) and the motion will fail. If there are failures, they’re out there to view within the output from the runner. You possibly can see an instance of the runner working .

Utilizing GitHub Actions As Standing Checks

If we have been simply working this motion within the background, it wouldn’t be a lot use. The probabilities of engineers trying within the Actions tab earlier than merging their PR is fairly slim.

Nonetheless, GitHub permits you to outline on pull requests. These standing checks might be configured to solely permit merges as soon as all standing checks have handed.

So, as a substitute of engineers having to recollect to verify the motion, we will make sure the linting passes earlier than a PR is merged. Right here’s an , that’s at the moment blocked because the linting failed.

More Posts