GitHub Actions Pivot
I’ve recently shipped a number of changes to
restyled-io/restyler
and
corresponding restyled-io/actions
to
make Restyled’s primary use-case be within a GitHub
Actions
workflow. I’m encouraging all users
to migrate to this approach instead of the GitHub Marketplace App and jobs that
run on Restyled-maintained infrastructure. Eventually, I plan to decommission
that infrastructure and support only GitHub Actions usage. Restyled will no
longer be a source-available business with a free offering and paid features; it
will just be an open source project. As such, I will likely re-license it AGPL,
stop with the CLA, etc.
Why #
I started Restyled in August of 2017 because I wanted a thing like it to exist. In the ensuing 6 years, I managed to build an extremely robust and automated architecture that I’m very proud of. This robustness and automation allowed me to spend time on it when I wanted, but only when I wanted. I’d go months or years without committing anything, then spend a weekend rewriting some huge component to experiment with a new technology. Despite having 72,000+ repositories, with 5,000+ unique owners, running 1,000+ Restyled jobs every day, I still managed to keep the all-in costs to me under $100 per month, and I can count on one hand the number of times I had to respond to any kind of “outage”. All the while, I (with some help ) maintained about 60 individual Restylers through a robust CI/CD process. Paid Restyled usage fluctuated around $30-60 a month, so I was happy to pay the difference for this “hobby” that also provided a service to that many users.
During that time, GitHub Actions was created and grew massively. It’s clear that if I were to do it over, that’s what I would’ve done. For users, implementing via GitHub Actions would mean:
- We get features like concurrent build cancellation and retry for free
- Inherit all the effort and support put into the official
actions/checkout
action, instead of our own clone logic - Control over resource constraints , including going as far as self-hosting
- Ability to DRY config through Shared Workflows
- Leverage everything the
peter-evans/create-pull-request
action does to avoid issues like this , this , this , and this - Free up complexity budget to tackle other things , either ourselves or via contributions in completely independent actions
- Safety in updates
from the conventional
@v{major}
tagging - With no hosting costs to me, Restyled can be available for free without restriction
This effectively closes every open issue and obviates many documented “common error” scenarios. With all of that opportunity, and with yet another email from Heroku about how my Redis add-on is end-of-life and I have to update, I think it’s time.
When #
You are able to convert your projects away from hosted restyling and to a GitHub Actions workflow right now. How well this works will depend on your specific use-case and change over time as I continue to iterate. I plan to leave things in this state for at least 3 months collecting feedback, particularly from paid users.
Date | Action | Status |
---|---|---|
2024-07-23 | GHA usage available | ✔ |
2024-07-26 | Paid plans no longer available from GitHub marketplace | ✔ |
2024-07-30 | Warning visible on restyled.io | ✔ |
2024-11-01 | Hosted usage emits an error status to PRs | |
TBD | Hosted usage stops accepting webhooks |
How will this affect me? #
If you are a user of Restyled for PRs that are “same origin” (so not from forks). Your experience should be largely the same; you gain all the benefits mentioned above and lose nothing. With a small GitHub workflow that runs Restyled, the behavior of fixing style and managing a sibling PR is the same. I encourage users in this group to make the switch as soon as possible.
If you are a user of Restyled for PRs that are forks, you’re experience may
change. Forks are difficult for Restyled to handle
generally
,
and we’ve landed on a workflow whereby Restyled makes changes and stores a patch
file that can be applied by your contributor through a simple curl|git
command. Doing things through GitHub Actions doesn’t give us the best options
for storing the patch file. I hope to explore this problem during the “beta”
period. Users in this group can hold off, or dive in and help decide our future.
To my many users and contributors, thank you! Any questions, please email .