| title | description |
|---|---|
Artsy Engineering Automation via Peril |
How do we take on our workflow in GitHub |
Peril has been running in Artsy since mid 2017, the blog post which covers what Peril is and why it was created is useful reading for this document.
This document covers, at the highest level, what Peril does at Artsy. The real source of truth for these rules is
the peril.settings.json in artsy/peril-settings.
Artsy uses a fork of Peril. It currently runs in our staging Kubernetes environment.
- All PRs should have a description RFC #5
- All PRs should have an assignee if not WIP RFC #13
- All PRs to repos with a CHANGELOG should require an entry in the CHANGELOG RFC #16
- All PRs with a reference to a Jira ticket will be moved along their board for you RFC #74
- Any commit message with a
[tag]that matches a repo's label will be synced to the PR's metadata RFC #7 - When PRs with specific labels are merged, they can send a notification to slack rooms RFC #33
- You can comment "#mergeOnGreen" or "#squashOnGreen" on a PR to have Peril automatically merge the PR RFC #10
- Any PR to an project that adds a new JS dependency gets a comment with an overview of the package and its dependencies.
- Any PR changing a markdown doc will go through a spell checker
- Any PR opened in a repo with an
.autorcwill have "Release: Patch" label added by default RFC #1095
- Any issue with RFC in the title becomes an "RFC" RFC #40
- Any "RFC" gets sent into slack three times in the upcoming week
- When any repo has a new tag created, a message goes to our #deployments slack channel
We used to have Peril run scheduled tasks. Some of those have been migrated over to the Joule repository and run as GitHub Actions.