per·il ˈperəl noun

1. serious and immediate danger. "their family was in peril".

Peril is a tool that takes GitHub webhooks, and makes it easy to build one-off actions. It does this by having a per-account settings JSON, that connects JavaScript files to events from webhooks. So, for example, you can write a rule which runs when closing an issue in GitHub that looks for associated Jira tickets and resolves them. Peril provides no implicit actions like that, it instead offers a JavaScript runtime environment optimised to this domain so you can make actions to fit your needs.

Want to understand what the plan is? Consult the VISION.md

Peril uses Danger JS under the hood, Danger is a tool built for adding extra tests inside Pull Requests that can work at a different level of abstraction to unit and integration tests. For example, you could write tests which:

• Enforce CHANGELOGs
• Enforce links to Trello/JIRA in PR/MR bodies
• Enforce using descriptive labels
• Look out for common anti-patterns
• Highlight interesting build artifacts
• Give warnings when specific files change

... and any other rules specific to your team's culture and needs.

80% of Peril is available today in GitHub Actions. Key things which are not:

• Multi-repo support (which is on the Actions roadmap)
• Pre-workflow evaluation on webhook data (basically the ability to refuse to run the workflow unless something is set in the webhook JSON)
• Triggering delayed jobs from webhooks (e.g. do this thing in 5m)

Is this enough to warrant self-hosting? Maybe, but it's pushing it a bit if you aren't comfortable hosting a JS project. Danger got extended with a lot of Peril's features in order to better support GitHub Actions during the alpha.

Given that I, Orta, can't install Peril on the Microsoft GitHub org, and GitHub Actions has most of Peril's features - it's unlikely that I'll be building much more into the core. I'll keep it ticking though, it's not much work.

You have two choices:

• Wait for me to ship Peril to production (probably mid-2019)
• Self-host your own Peril

OK, I made a quick tutorial for running a private Peril against your org - this is for Heroku, but the underlying principles work for all of them.

Ace, great, cool. So, it's a bit of a process. I'm not sure if this will get easier in time. It's a complex app. You can find out more here.

This repo is a mono-repo with three main responsibilities:

• api - The Peril WebHook + API
• dashboard - The Admin Panel for logged in users
• web - A static website for the public

• Introducing Peril to the Artsy Org
• On the obsessive statelessness of Peril
• Reference: Terminology
• Reference: Settings Repo JSON
• Reference: Running Peril Locally