I’m submitting WIP to the marketplace. I hope it will become an even better reference app that way, not only regarding the code, but also requirements such as policies and my answers to all the questions that GitHub will ask you when you submit your own app.

You can follow the progress of the code changes at #94. I’d particularly appreciate your input to how configuration should work (#96).

There will be a change of how the app works and I’m not yet clear how the transition will work exactly. It’s one of the things I’ll make sure to document for y’all :)

Here is a sneak preview of the upcoming WIP app, featuring

• configuration (see #96)
• checks
• custom actions

Enjoy

Hello, Marketplace!

WIP is now on the GitHub marketplace: https://github.com/marketplace/wip 🎉

I want to thank you all for using WIP, for your questions, bug reports and ideas 💐

Changes

First things first: WIP is still the same app. You do not need to uninstall/install anything.

Find usage details in repository’s README.

Notes

• Accept the new permissions requested by the WIP app

  You might need to accept the new permissions requested by the WIP app for your account and organizations. The app will continue to work as before for a transition period, but eventually I will remove the legacy code.

  Explanation for the additional permission requirements

  1. read/write access to checks: Using checks allows the app to explain why a status was set to pending. There is also an action that allows you to manually override the status to "success".
  2. write access to the pull requests: Needed for the status override. It add’s a @wip read for review string to the end of the pull request body. That way the author can override the status, too.
  3. read access to .github/wip.yml file: Needed for configuration. No other files can be access by WIP.

• Getting the Pro Plan features for free

  WIP is a not-for-profit project and I will donate all revenue from the Pro Plan to Rails Girls Summer of Code.

  Until the WIP is listed on the marketplace or if you cannot pay for the Pro plan, you can send a pull request to add your account or organization with an explanation to the pro-plan-for-free.js file.

• Legacy Commit Status Override

  Unfortunately, when setting a pull request state using a check that has the same context name as a commit status, one does not override the other, instead they are both listed. That means that a previous "pending" commit status can block a pul pull_request indefinitely, as the new version no longer sets commit status directly, but instead is using checks. So for a transition period the app checks if there is a commit status set and overwrites it, Unfortunately there is now way to simply delete a status instead. That’s why the app requires the read/write permission for commit status for the same transition period.

It’s been a month

We have a new logo thanks to @micahilbery! See #143 for discussion

Here is a screenshot of Marketplace insights. The data does not include the past two days, but good enough I guess :)

What I have learned

• Many people missed the notification to accept the permissions. I’ve reached out to a few folks that didn’t to ask why they did not accept them, and none of them have seen the email. I’m not sure how to know the ration of installations that are still using the legacy permissions. Telling from the logs it’s roughly 30%.
• Some people are hesitant to accept the new permissions or install WIP because it requires write access to pull requests. The reason WIP requires it is the check action that overrides the status by adding or removing the string "@wip ready for review" from the pull request body. At the same time, nobody used the check action in the past 7 days. So I will remove that code and the required write access to pull requests and instead explain how folks can do it manually.
• Marketplace only pays out revenue ones it reaches $500 USD, so that might take a few more months
• There seems to be a memory leak in Probot: #151

Things I plan to work on next month

• #147 Remove custom check actions and requiring pull request write access.
• #148 Add timing to the logs. I’d like how long it takes to handle the pull request webhooks under different states. Once I have a baseline, I want to look into replacing the REST API calls with GraphQL and see what difference it makes.
• #149 Making the status text more useful. Instead of just showing in progress – Work in progress I’d like to show something like in progress – "WIP" found in title
• #150 Update the documentation to explain how you can configure WIP in a central place for an installation, you can do that by creating a .github repository and put a .github/wip.yml file in there. This became possible via probot/probot-config#16

Still WIP

I’m sorry for the lack of updates. I’ve been busy providing for my family and in February, GitHub announced the new Pull Request Draft feature. I honestly wasn’t sure if people would still be interested in WIP after that, but it looks like they do:

I’m still waiting for the first payout! I’ll pass it on to Rails Girls Summer of Code as promised. Stay tuned!

So just to make it official, I’ll give the WIP some love today and am looking for things you’d be interested in. I'll start with some chore work

• #147 Remove custom check actions and requiring pull request write access
• #124 Officially deprecate the legacy support: nudge people to accept write permission for check runs in order to continue using WIP.
• #98 After install, set status on existing pull requests

Update: I’m all done now and will deploy it to production. What could possibly go wrong on a Friday night 😜

Happy birthday 🎈

Wow, what a year it has been. These three little humans entered my life shortly after the tiny WIP GitHub App started its adventure to get listed on the Marketplace. WIP is older, but today in 2018 I decided that WIP is more than a little hack running on Glitch (I still love you, Glitch 🎏). It became a legit GitHub App.

Its very first commit is nearly two years old. The very first working version from that day had barely 20 lines of code. That version makes a great example for a minimal GitHub App if you would like to build one yourself!

Over time I added new features. Besides looking for only "WIP" in the title, the app started to look for related terms and in other places (commit subjects and labels).

More and more people started to use WIP and a few optimizations became necessary. Instead of setting a status each time, I started to check if the status changed first, as rate limits for mutating requests are much more strict.

Around that time I made the decision to submit WIP to the marketplace. Version 3 - the marketplace edition - was finally released on October 13th. Our triplets just turned one month old and I have no recollection of how I managed to accomplish that 🤔

WIP was always meant to be an experiment that everyone can use and learn from. I wanted to make sure that everyone who cannot pay for a paid plan but would benefit from its features can do so, by enabling the pro-plan-for-free workaround. Thank you all for being fair 💜

The marketplace edition also introduced the usage of check runs instead of just setting commit status. It faced an interesting challenge, because it required new permissions. I didn’t want to break WIP for people who couldn't accept the new permissions (or simply missed it, like many do I fear). So I kept the old version alive as a legacy handler. I only replaced it a few days ago, the new version sets the status to error and prompts to update the new permissions. Many of you saw this error and promptly accepted the new permissions. Thank you 🙏

In order to not leave you stranded with pull requests that have an error state from WIP, I also implemented a reset of all open pull requests when you accept new permissions. The same happens when you install the WIP or add new repositories. This only became possible thanks to the great work by @SGrondin to implement request throttling and request retries. Probot ships with it by default now 🚀

Looking back, I might have gotten too excited about check runs. There is a feature that allows to request custom actions from a check run. I introduced a manual override action. It required write permission to pull requests which several people mentioned prevented them from installing the WIP app. I think in the past year less than 10 people used that feature, so I decided to remove it again. One permission less 👍

Somewhere in between GitHub introduced draft pull requests. At first I thought WIP’s day were counted, and I took a break from it to see how usage would change. But it doesn’t look like the draft feature is a full replacement. WIP is going strong and I’m confident that it’s here to stay 😊

Oh yes, it’s WIP’s birthday, and look what we got: the very first payout! 🤑

As promised, I’m donating 100% of the revenue to Rails Girls Summer of Code. Talking about it, RGSoC is taking a breath and are working on their rebranding. I for one am very excited to see what its future brings and will continue to support their outstanding work.

Thank you all for using WIP ❤️💚💙

Dear WIP pro users, I'm planning on donating WIP's revenue to a new project moving forward. Please chime in on the discussion at #215 if you have any questions or concerns.

Update Dec 20th, 2019

There were no objections. WIP's revenue will be donated to Processing | p5.js moving forward. Thank you all for your feedback and support!

What's up

👆 The above screenshot is a live dashboard of data logged from the WIP app. I wrote a short blog post about how I put it together. It only has data since December 13, so the comparison to the previous week is not yet very useful. But it's fascinating nevertheless, and I like how transparent the WIP becomes thanks to it. And surprising simple to put together. Please comment on my blog post above if you have any questions!

There have also been some over newsworthy updates:

1. Thanks to Probot v11, the WIP app is now deployed as a serverless app to Vercel. The required change was trivial. The Probot app function did not require any changes at all, which also means that I can run the app locally using Probot's built-in server, which makes testing and debugging much easier, and it does not require an internet connection (unlike vercel dev). The only two additions were:

   1. An API function at api/index.js. WIP's app function is a bit more complicated because it implements a redirect for wip.vercel.app, the minimal amount of code would be

      const { createNodeMiddleware, createProbot } = require("probot");
      const app = require("../");
      module.exports = createNodeMiddleware(app, { probot: createProbot() });

      We've spent a lot of time on Probot to make this possible and to make the upgrade path smooth. If you use Probot today, make sure to update and to report back!

   2. A vercel.json file in order to redirect POST / requests to the function in api/index.js

2. After two years, I removed the code for handling legacy installations that still didn't accept the new permissions. There were still 323 such installations, barely any of which was active in recent weeks. Fair to say the owners of installations would have never accepted the new permissions, so I used the new DELETE /app/installations/{installation_id} endpoint to simply remove them myself.

   My goal for the WIP remains to be a reference application of a real-life GitHub application, and I'm glad I could finally remove code that added a non-significant amount of complexity.

3. Lastly, I'm happy to report that there I received 3 payouts for WIP's marketplace subscriptions which totaled to 1810.14

   

   I used $600 to directly support members of the team who made p5.js transition to a rotating leadership model possible. I just donated the rest

   

   If you would like to join me supporting the most amazing p5.js project, their holiday fundraiser is open until Dec 31, and they have some beautiful perks you can get: https://donorbox.org/supportp52020

Moving forward, I want to be as transparent with the revenue as I am with other WIP data. Stay tuned for project "open purse"!