In the first part of this article, we described how we use an IRC REPL for SSH tunneling, continuous integration and pinging. Today, we will tell you more about October’s deployment, integration with Github and why is it nearly an AI.
Sometimes I cannot connect to a machine where our October is installed yet I need to restart it. And as always, this puzzling ‘impossible’ task can be easily solved by our IRC REPL itself, as you will see.
Way of the Samurai
First, we have to kill the running bot and we do it with a simple
!seppuku command. It orders October to perform a hara-kiri (i.e.exit). However cruel it may be, remember that October has not (yet) passed the Turing test. But it is quite close:
Anyway, as October ceremonially exits:
we have to start it again somehow and that can hardly be performed by October itself as it is sleeping with the fishes right now. But we have other tricks in our sleeves. Namely a watchdog which re-spawns the bot whenever it dies so that we can immediately see:
Restarting is cool but what for would you use it? Well, apart from the Windows world, where reboot is used mainly as a standard configuration procedure, it is usually needed when new code is deployed. So let’s take it one step further and create
!selfupdate command that pulls new code from GIT, install new dependencies (
bundle install) and then calls
!seppuku all by himself. The watchdog then spawns a new process and October is back online! More fresh than ever!
A bit of code
So how does it all work inside? The October re-spawning implementation has 3 parts: an initializer, a loop and a spawner. The initializer is super easy, it just stores
The second part, spawner, creates a new process by forking the current one and loads October in it. Any passed block gets executed in the context of a new process so that no code leaks to the watchdog.
Last but not least, a
loop! method that supervises the spawned processes and creates new ones when they die:
As you can see, forking and process management in Ruby is really easy and straightforward. In case you want to read more about it I cannot but recommend you the Jesse Storimer’s blog. You can also check out the whole spawner code in October repository.
Stop bugging me
As it is annoying to switch to the browser just to do such a common task as creating or reading an issue, we have an October plugin for it. To create an issue just write:
or if you want to ask others about one, all you have to know is its number:
Quite an improvement, but that’s not all! On Github, you can attach code to your issues or in other words, every pull request is just an issue with some source code attached. Unfortunately, you cannot convert a normal issue to a pull request via web UI, but you can do it using an API. That allowed us to create yet another command,
You can find more feature in the issues plugin code.
The issues plugin features described above are very simple stuff: they basically allow you to switch one console for another, more accessible to your fingers. But Tiago wrote a plugin that really adds some value by integrating GitHub Issues and Jenkins, a continuous integration server the same way Travis does. Each time a build successfully finishes and informs about it in the
October checks all open pull requests and if one of them belongs to a branch that was just built, it posts a comment informing about it, like this:
That way, whenever we are about to merge some code, we can be sure that the tests are green for it.
How do you do?
There are many things October does and many many more that it can do. If you yourself have any suggestions or if you use similar tools to automate your workflow, please share it in the comments!