In moving this blog to a static site generator, one concern was whether I’d still be able to work on and/or publish a post from my phone. I tend to do a fair bit of mobile drafting while I’m in the subway or waiting in line, and will sometimes publish content when I’m away from my computer. YOLO.
It’s a given—since that’s how the site has been setup—that you need a GitLab.com account, and Hugo set up with GitLab CI to build the site and deploy it to GitLab Pages.
On my iPhone, I have Working Copy, which I use for git operations on the repository. It’s an excellent app, and when you pair it with Editorial’s powerful workflow and text editing capabilities, you’ve got a great toolkit for repository management as well as writing.
I like using issues as jumping off points for new posts (including this one, so I also use Git Trident to manage this in GitLab from my phone. Matt’s working hard on making this the best app for handling GitHub and GitLab issues on your iOS device, and I’m especially looking forward to offline access.
This post was a test for how to add content to the site from my phone, and here’s how I’m going to do it from now on:
- Usually (but not always), an issue tagged
post ideais the basis for a new post. When I’m ready to write, I assign the issue to myself and set a due date for it.
- I then create a new branch as
n_post_post-subject_yyyy-mm-ddin Working Copy, where
nis the issue number and
yyyy-mm-ddis the post date. If no issue exists, I drop the
n_prefix in the branch name. I try to avoid setting a title, as this can change over the course of the post. “Post subject” is already pretty well defined, since I know what I want to write about.
- Next, I create a new text file in Working Copy under
/content/post, and open it in Editorial via the share sheet to start writing. I have a TextExpander snippet to add the TOML front matter; it’s also set as a draft, to ensure it doesn’t get published accidentally.
- Then comes the hard part: write the post. Commit as necessary with Working Copy’s workflow for Editorial. I commit and push for a “cloud save”, or if I think I might want to continue elsewhere (i.e., on my desktop, or in a web editor1.
- When it’s all said and done, I set
'draft = falsein the front matter, commit and push with message
Closes #n, where
nis the issue number.
- When I’m ready to publish, I launch Safari and go to GitLab.com to open a new merge request. Merging the draft branch into
masterwill trigger GitLab CI; once the build passes, the post will be published. I also delete the original branch.
- That’s it! The post is published. Enjoy a tasty, refreshing beverage!
I wrote the majority of this post on my iPhone, although I’ll admit that it does feel a bit silly to tap away on a 4.7” screen when I’ve got a 24” monitor and full-size keyboard to work with. Still, for drafting and editing, it’s great, and in a pinch (or, say, on an iPad with an external keyboard), you can keep your blog running from your iOS device without issue.
Web editor, you say? Why yes! You can edit a file in GitLab, then commit the changes. Neat, huh? ↩