Migrate from self-hosted Peril to Danger on GitHub Actions

[loremattei]

We've been using Peril to support PR reviews for a couple of years now and it has become a key part of our process.

Peril is basically a self-hosted version of Danger.

Since GitHub released Actions, the development of Peril has stalled and the authors and maintainers have focused on improving Danger and making it work flawlessly with GH Actions.

We currently host Peril on a free Heroku account and with the projects we've now hooked we're reaching its limits.

Given the above, it would be interesting for us to investigate the migration from Peril to Danger on GitHub Actions.
Our rules are Danger's rules and they are already stored in a shared repository, so it should be possible to run mixed environments and to migrate on a phased roll out.

[mokagio]

Here's an update on the state of this. We decided to pause the migration effort, because of time and return of investment considerations.

Danger, whether the Ruby or the Javascript implementation, works great for PRs. We were able to replicate the centralized nature of the Peril configuration by defining project specific Dangerfiles that imported and run the granular checks they needed, see here.

Unfortunately, I wasn't able to replicate Peril's behavior for issues and status webhooks in the Danger + GitHub Actions setup.

• There is a bug that makes Danger when running on a workflow triggered by an issues event.
• When a GitHub Actions workflow runs as a result of a status event, there is no PR attached to it, and Danger only expose its GitHub API interface. We'd have to add extra code to manipulate the status value and post on the PR like we currently do with Peril.

We could adopt Danger only for PR checks and keep Peril for the other ones, but this would mean maintaining two setups instead of one, for no real gain. Danger even runs slower than Peril, because of the GitHub Actions CI boot time.

Moreover, Danger via GitHub Actions fails to run on PR coming from forks. This is a limitation that CircleCI has as well, meaning that if we were to migrate we'd already have in place the processes to take over a PR for a fork to run CI on it. Still, it's something that "just works" on Peril, adding another point against using Danger right now.

Given we have more impactful work to do right now, we decided to pause the migration project. I'll be keeping an eye on the Danger repos and revisit every 3 months or so.

I'll also set Danger via GitHub Actions up in one of our internal tools in Automattic, in order to keep the setup up to date, so that when the time comes, we'll have a quick start reference.

[stale]

This issue has been marked as stale because:

• It has been inactive for the past year.
• It isn't in a project or a milestone.
• It hasn’t been labeled [Pri] Blocker, [Pri] High, or good first issue.

Please comment with an update if you believe this issue is still valid or if it can be closed. This issue will also be reviewed for validity and priority during regularly scheduled triage sessions.

[jkmassel]

This was done a few months ago.