Skip to content
This repository has been archived by the owner on Jul 11, 2023. It is now read-only.
/ nag Public archive

The mother-in-law of linters

Notifications You must be signed in to change notification settings

utensils/nag

Repository files navigation

Nag Build Status

The mother-in-law of linters

A microservice to nag you about code quality; Pronto-as-a-Service.

Lifecycle

Life cycle

Deploying

Nag is built to work with releases, courtesy of Distillery. To build a new release:

$ MIX_ENV=prod mix release --env=prod
==> Assembling release..
==> Building release nag:1.1.0 using environment prod
==> Including ERTS 8.2 from /usr/lib/erlang/erts-8.2
==> Packaging release..
==> Release successfully built!
    You can run it in one of the following ways:
      Interactive: _build/prod/rel/nag/bin/nag console
      Foreground: _build/prod/rel/nag/bin/nag foreground
      Daemon: _build/prod/rel/nag/bin/nag start

Note: The current configuration includes the ERTS so releases must be built on the same architecture they are targetting; the included Dockerfile can be used for building Ubuntu releases:

$ docker build --tag=elixir-build .
$ docker run -v ~/Projects/nag/releases:/app/_build/prod/rel elixir-build mix release --env=prod

Testing Nag locally

As it stands today, Nag relies on GitHub webhooks to know when and what to analyze. During local development Postman (or any REST client) can be used to fake webhook requests to our local Nag server. Local requests should target localhost:4000/webhook.

There are only a handful of fields required by Nag so a minimal request with only those values will suffice:

{
  "action": "opened",
  "pull_request": {
    "number": 1,
    "state": "open",
    "head": {
      "ref": "branch-name",
      "repo": {
        "full_name": "doomspork/repo-name"
      }
    }
  }
}