Restricting Command Execution

Hubot is a powerful tool, but with great power comes great responsibility. To control the danger, you can restrict where and when some commands can be executed.

Restricting Execution To Certain Rooms

There may be a situation when you would want some command to be executed only in one room. For example, if you deploy your application with Hubot, you want all deployments to happen in Deployments room, so that you don’t have to skim through all the rooms to see if somebody is deploying something.

Hubot does not have any special means for this, but we can easily add restrictions to virtually any script with couple of lines of code. First, you need to know the ID of room you are in. This may be simple with some adapters, like Campfire, where room id is visible in the URL, or IRC, where room id is #something. There is bundled with Hubot scripts to help you find the room id if you have trouble with that. Add "room-info.coffee" to hubot-scripts.json, restart Hubot and say hubot room info in the room you want to rescrict a command to. This is how room IDs look in Skype:

Tomas Varaneckas: hubot room info Hubot:            This room is: #tomas.varaneckas/$hubot;5e184b59e0a11db6 

Yes, #tomas.varaneckas/$hubot;5e184b59e0a11db6 is how room ID looks in Skype, nobody could ever guess it.

Anyway, when you have your room ID handy, time to restrict the execution. Just check if msg.message.room matches your room ID in the beginning of every restricted command:

robot.respond /deploy (.*)/i, (msg) ->   if msg.message.room != '<room-id>'     msg.send 'You can only deploy in "Deployments" room.'     return   ... 

Limiting Execution Hours

Imagine a fine Friday evening. You’re sitting in a bar with your friends, having your third pint of beer, and suddenly Nagios starts knocking - your app just went down. You take out your laptop and spend 20 minutes trying to pinpoint the problem. The beer you just had doesn’t help, but finally you realize that a very inefficient query was just deployed along with other changes, and database load went over the roof. You spend 30 more minutes reverting the change and putting the site back up. You cannot really blame the developer, who was trying to do his best and started the deployment at 8 PM on Friday night, doing overtime for the sake of the company.

That scenario was based on true story, and to prevent it from happening, you can restrict dangerous operations to working hours. Here is an example how to do it:

# Your TimeZone offset time_offset = 3  # Function that tells if current time is within working hours isWorkingHours = ->   now = new Date()   current_hour = (now.getHours() + time_offset) % 24   current_day = now.getDay()   current_hour in [9..18] && current_day in [1..5]  robot.respond /deploy (.*)/i, (msg) ->   unless isWorkingHours()     msg.send 'You can only deploy during working hours'     return   ... 

This will definitely give you peace of mind next time you’re out on Friday night.