Using Netlify Webhooks With IFTTT

Any time I update my site and push the changes to GitHub1, Netlify sends me an email once it has been successfully deployed (or if the deploy failed for some reason). Netlify can also send these notifications as outgoing webhooks, and even receive notifications from other services to trigger builds automatically.

Although implementing webhooks can often be complex, a basic solution for notifications can be done with IFTTT.

Build notifications

IFTTT's Webhooks service can receive web requests (i.e., webhook notifications) to trigger actions. A custom event name is specified when creating an applet which must be included in the URL provided by IFTTT2. This allows the platform to identify which applet the request corresponds to.

I use this service to receive a push notification when a site deploy is successful. I created an applet that uses the Webhooks service to receive a web request, setting the event name to deploy_success. For the action, I chose Send a notification to the IFTTT app. Finally, I set up an outgoing webhook in Netlify, (under deploy notifications) using the URL and event name from IFTTT.

Netlify notification options

Whenever my site is deployed, Netlify sends a webhook notification to IFTTT that triggers a push notification on my iPhone. I also use the same process to be notified if a deploy has failed, using deploy_failed as the event name instead. A separate outgoing webhook notification is configured in Netlify for failed deploys.

With so many services supported by IFTTT, you can perform many different actions based upon the status of a build. For instance, you could post a tweet when a deploy has succeeded or blink your Philips Hue lights if a deploy has failed.

Build hooks

Netlify also supports incoming web requests to trigger builds (build hooks). IFTTT can send web requests using the Webhooks service as an action triggered by another service. To use this, create a new build hook in Netlify and include its URL in the applet as a Webhooks action. Any POST request that reaches this URL triggers a build.

Creating a build hook

For example, builds can be triggered on-demand using IFTTT's Button widget service. Applets can be run when tapping it in either the Today widget in iOS or on Apple Watch.

iOS Widget

Apple Watch.png

You could also use Amazon Alexa to trigger a site build whenever you ask it to (e.g., "Alexa, trigger site build").

IFTTT and build hooks can add scheduled post functionality to a statically generated blog. Static site generators like Jekyll can't support scheduled posts themselves3. To include a new post dated in the future, the site has to be rebuilt on or after that date.

Using IFTTT's Date & Time service, you can schedule a site build to automatically occur on a regular basis, even as frequently as hourly. Scheduled posts would then be included once the appropriate date and time have been reached.

Keep in mind that if you create an applet to schedule a recurring build and have another one set up for notifications, you'll be notified each time it happens.

  1. I had been using GitLab but decided to move back. I didn't have any issues with GitLab, I just find GitHub easier to use.

  2. You can retrieve your URL from IFTTT's webhooks documentation. The URL is unique to you as it includes an account key. Replace {event} with the event name specified.

  3. I use the option future: false in Jekyll's _config.ymlso that posts with a date in the future are skipped. Only when the date has passed are they included when the site is built.

Goodbye, Mac

Goodbye, Mac

Today sees the release of iOS 11, so it seems fitting that it's also my last day as a Mac owner. My Late 2012 13" Retina MacBook Pro has been erased and boxed up, ready to ship to Apple for recycling. I'll even get about $450 from the Apple Renew program, money which won't go towards a replacement.

The iPad has been my personal computer for a couple years now. During the early days, I would occasionally need to use my Mac to do things that I couldn't do (or hadn't yet figured out how to do) with iOS alone. But as iOS and its ecosystem of apps further improved and became more powerful, that need diminished. Once I upgraded to an iPad Pro, became an expert with apps like Workflow, and set up an iPad approach to blogging and web development using Coda and Working Copy, the writing was on the wall.

While using the iOS 11 public beta, I realized that I hadn't used my Mac in months. It spent its summer under a pile of papers in a desk drawer. I tried to think of reasons to keep it, but nothing compelling came to mind. In fact, the only task I can't use my iPad for is to update my Logitech Harmony remote control. However, I still have a gaming PC and can just use that instead.

A part of me has known this for a while, but I kept the Mac around as a security blanket in much the same way that some people keep old cables for devices they no longer own, just on the off chance that they might somehow be useful again. I'm not ruling out the possibility of owning another Mac in the future, but unless Apple ceases development of the iPad and iOS, I can't see myself switching back.

Workflow Directory Is Now on GitHub

In December 2016, I announced that I'd no longer be updating Workflow Directory. The Workflow team had made some great improvements to the gallery, the biggest of which was user submissions. At the time, it didn't make sense to continue working on the site when the built-in feature was so much better.

Fast forward to March 2017 and the news broke that Apple had acquired Workflow. While the app continues to be updated, the gallery is not accepting user submissions. Since then, I had often wondered if it'd make sense to reopen Workflow Directory.

So I've decided to do just that, but in the process I've made a fundamental change. After testing the waters last week with a similar endeavor, Workflow Directory into a GitHub repository. Existing workflows have been migrated (with the exception of a few that are non-functional) and I've added a few new ones too. Each workflow has an accompanying README containing a description.

If you're unfamiliar with Git, don't fret. Browsing the repository and downloading workflows is essentially the same experience as before, you're just doing it through GitHub's web interface. There's even a new Submit to Workflow Directory workflow if you want to create a submission1.

For those of you that do know Git, you can clone or fork the repository (I recommend the awesome Working Copy for iOS) and you're more than welcome to submit pull requests for submissions (in fact, I'd prefer it!)

Moving to GitHub provides some much needed flexibility. Unlike the previous website, the repository hosts actual workflow files. Should Workflow ever lose the ability to share workflows using workflow.is links, the repository isn't affected (unlike the old website). It also means that I can have others help out with submission reviews. The drawback of the migration is that the existing RSS feeds for Workflow Directory are no longer available, though you can follow the repository so you're notified of new updates. The Twitter account will still be active and posting updates though.

Check out the GitHub repository and I look forward to receiving your submissions!

  1. The submission workflow files an issue within the repository that will be actioned when the next batch of updates are made.

GitHub Repository of My Workflows

Workflows can be shared either by creating a workflow.is link or exported as a .wflow file using "Share as File". Using the latter option, I've set up a GitHub repository of workflows that I've created. I'll be regularly adding to the repository so it's a handy way to always have a copy of the workflows I create.

You can quickly clone the repository using an app like Working Copy (one of my favorite iOS apps). You don't need to be familiar with Git to do this or even have a GitHub account.

Alternatively, you can simply download a ZIP archive of all the workflows. I'd recommend cloning the repository as you can easily keep it updated whenever I add new workflows.

Device-Framed Screenshots in Workflow Redux

It's been almost two years since I made a workflow to create device-framed screenshots. Since then, Workflow added an Overlay Image action that allows users to place one image on top of another, making the need to slice up device images redundant. I figured that those wanting to create device-framed screenshots would eventually use this as a replacement for my workflow.

Nonetheless, the original workflow proved to be quite popular and I still get asked about it from time to time. Just last week, I helped someone on Twitter who was having trouble using the old workflow. I've now created a replacement action extension workflow that uses Overlay Image to generate device-framed screenshots for iPhone, iPad, iPhone SE, and Apple Watch.

Device-framed screenshot for Apple Watch

Unlike the old one, this workflow doesn't need you to download image assets manually. The workflow operates as an action extension for images, but if you run it from within Workflow it will automatically download the image assets and save them to iCloud Drive for you.

Run the workflow from within the app to install the device images it needs

The workflow also automatically detects orientation and provides either portrait or landscape device-framed screenshots (excluding Apple Watch).

Device-framed screenshot for iPad

To correctly place the screenshot within the device, the following measurements were taken for each device image1:

  • Height and width of the screen area
  • X and Y distance of the top-left corner of the screen area from the edge of the image (where the image is to be positioned)

When the workflow is run and a device chosen, Workflow resizes the screenshot to the dimensions of the screen area. It then overlays it onto the device image at the appropriate coordinates so as to completely cover the screen area.

This workflow becomes especially useful when coupled with the new screenshot process in iOS 11. Instead of just saving a screenshot to the Camera Roll, iOS now provides an option for annotating and sharing a screenshot before deciding whether to save it. This means you can create a screenshot, annotate it (if needed), then share it and use the workflow to create a device imageā€”all as part of one process. You can then discard the original screenshot without needing to save it.

Annotating screenshots in iOS 11

For use on the web, I highly recommend using my Optimize Image workflow to reduce the file size of the resulting PNG image. You can add a Run Workflow action at the very end of this workflow to pass the image directly into Optimize Image workflow, providing a single process for generating and optimizing device-framed screenshots.

Run workflow

This workflow only includes one color of device (Space Gray), so consider it a starting point for further customization. You can easily add more devices or colors by customizing the workflow and using the same process for all other devices.

  1. I used the Crop tool in Pixelmator to get these dimensions. I'm almost certain there's a better way of doing this, but it worked fine for what I needed.