Hubot with Git Submodules

I love hubot and use one in a few different places. One thing I do find though is that I often want to edit or evolve those plugins, and it seems somehow unethical to just hardcode my changes into my own repo. Once I figured out how to wire together a forked repo as a submodule, it became much easier to work with hubots with external plugins, so I thought I'd share my recipe for that.

Plugins as Submodules

Git submodules can get messy if you're not totally clear on what is going on. The basic premise is this: there's a git repo in your subdirectory, and the parent directory will notice if things change in there. You need to remember to commit and push on both the main repo and the submodule and then everything will work! The git-scm reference for this has good examples: http://git-scm.com/book/en/v2/Git-Tools-Submodules>http://git-scm.com/book/en/v2/Git-Tools-Submodules

In this case, I've got my own fork of the github notifier plugin which we use in the #joind.in channel on freenode. My fork lives here: https://github.com/lornajane/hubot-github-repo-event-notifier so I go there, and I grap the repo URL.

Then, I add it as a submodule. I've created a directory called my_modules inside my hubot folder to keep submodules in.

git submodule add my_modules/hubot-github-repo-event-notifier https://github.com/lornajane/hubot-github-repo-event-notifier.git

There are two particular things to notice about this command:

  1. It is run from the top level of the repo, not the subdirectory
  2. It uses the https version of the URL - I usually work with SSH for github, but if you're going to push to heroku, the https one makes more sense there

Tell Hubot About The Plugin

To get hubot to "see" this plugin, create a symlink in the scripts/ directory that points to the script you want to run in your plugin. My command looks like this:


cd scripts
ln -s ../my_modules/hubot-github-repo-event-notifier/index.coffee gh-notifier.coffee

Now when you run hubot, the plugin should load. You can easily test your hubot locally (without having to commit and push to heroku every time) by running ./bin/hubot from the commandline; this starts hubot with the shell adapter and is really hand for the types of commands where you say something and the bot does something. I have a trick for testing webhooks on my local machine that I'll share in a separate blog post but the main thing is, any really basic mistakes like syntax errors will become obvious at this point :)

Submodules to Heroku

There isn't anything special to do here. Make sure that both your main and submodule repositories have changes added, committed and pushed. When you push the main repo to heroku, it knows how to handle the submodules and will plug them in accordingly.

I love that so many of the hubot plugins are packaged via npm but often I want to tweak or evolve them - or even just take advantage of their newest changes without waiting for it to be packaged! The github integration in particular I found was a lot less useful than I expected from any of the plugins I could find, so if you're using hubot and github and you want to try my version, feel free ... the main reason I wanted to work with submodules and hubot is so that I could share what I was working on in case it was useful to anyone else.

Git: upstream is gone

I came across a git repo recently that output this message with every operation I did:

Your branch is based on 'origin/master', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

I was delivering a workshop at the time so I kinda snarled at it and carried on with what I was doing, but later I looked up what is happening. This occurs when a branch is tracking a branch that the git repo doesn't have any information about - the branches to be tracked aren't in the local repo metadata.

In my case, it happened because I had created and then cloned an empty repo for training purposes - so origin/master didn't actually exist yet! I added a quick commit-and-push to my script and hope that I won't be upstaged by this change that came in with git 1.8.5.

Hopefully this post will help someone else to avoid being upstaged or irritated by this as well!

5 Reasons to Consider Upgrading Your PHP Platform

In recent years, the release cycle of PHP has become much shorter. We now have a much more controlled and well-publicised process of releases, and moving between each version is no longer a leap of faith. The newer versions have HUGE performance improvements, great features, and better security, and the software is free to use. Yet we have a very, very long tail of PHP installations on older versions (around 75% on entirely unsupported versions at this point). Many of the companies I talk to think that upgrading will be pointless and painful, but that's not my experience of migrating PHP projects. Here are a few things you might like to think about or be aware of before you make the decisions that "not broken" is good enough for your applications. Continue reading

Gollum the Git-Enabled Wiki

In trying to get company documentation off google docs and people's laptops and into a more useful format, I have been researching developer-friendly tools for business documentation. Requirements went something like:
- must handle words and documents
- should be available locally, bonus points for revision history
- must publish to the web, and ideally be editable there
- should accept content in markdown
- must have access control (which wiped out my original plan of using a static site generator)

While I worked on this, we were using the wiki feature in GitLab ... which pretty much hit the nail on the head. Further investigation showed that the wiki feature in GitLab (and indeed in GitHub) is a ruby gem called Gollum. Continue reading

Set Up Your First Hubot

It took me far too long to get my first hubot working; when I finally sat down to get it going the process was much easier than I expected! So here's a little guide in the hope that this helps you get started too.
Continue reading

Hubot and Slack

I'm enjoying using hubot to integrate services very easily and both give updates and respond to commands in chat. One of my hubots chats to us in slack rather than in IRC, and there are a couple of gotchas that I wish I'd known about before I started!

  • Hubot will not respond to you in PM, you need to join a channel and then /invite @hubot and your bot will join you in that channel and then respond when you address him/her by name
  • When configuring channel names for slack (I use the gitlab plugin which needs a GITLAB_CHANNEL environment variable), do NOT include a # at the start of it if you use slack - works a treat in IRC, but skip it for slack. I spent quite a while looking for a bug in the slack adapter before I figured this one out so it's written here for me to look up next time!
  • Also note that your hubot can only speak in channels that it has joined; I have seen hubot actually crash when asked to speak in a channel that exists but which isn't known to it.

I think this central way of having plugins which can integrate with many messaging platforms on one side, and integrate with many external APIs on the other means we'll be doing much more in chat ops moving forward. Already I'm impressed by how many of the hosted tools I use have webhooks, although there aren't hubot plugins for all of them (yet!).

Todotxt on Android and Ubuntu

I'm a big fan of good tools, however struggle to find products that fit me because there are some key constraints:

  • I use Linux (specifically Ubuntu 14.10)
  • I don't use a pointing device. At all. If I can't use a tool from the keyboard, I can't use it at all (as a side effect, I use keyboard enablers in my browser so if your website has "helper" keyboard shortcuts, I probably can't use that either)
  • My other devices (phone, tablet, work phone) are all android

Taken together, this makes finding tools a challenge - but I've had good experiences with todotxt and the ecosystem around it. Continue reading

Status Check on All Vagrant Machines

Much of the development I do these days uses vagrant machines to make sure that my code is running in the correct environment. This is great, but spinning up too many machines at once can rather stretch the resources of the computer you're running them on - and I keep starting up machines and then forgetting about them!

It turns out that (since vagrant 1.6) you can ask vagrant to tell you which of its machines are running, using the command:

vagrant global-status

Where did all my system resources go? Now I know!

Vim and HTML Tags with the Surround Plugin

Marking up documents is always tedious, and usually there are shortcuts available. My favourite document format tool is Pandoc, literally a box of document-conversion tricks! Today though I was not so lucky so I marked up a plain text file as HTML by hand ... or rather, using my favourite vim tricks so I thought I'd share them.
Continue reading