Making a new release of Mudlet, while very exciting, is also a very intricate affair easily taking up 4-6 hours just on the day of the release – nevermind all of the preparation that happens beforehand. Doing that once or twice is okay, doing it for many months is manageable, but doing it for many years – as has it been the case – is starting to get too difficult! One can start to relate to the cavemen who are too focused on what they’re doing, and don’t devote any attention to improving:
Naturally, the obvious thing to do here is to streamline and automate the release process so it is once again a pleasant activity again that one looks forward to! With this in mind, we’ve got 15 various points of improvement laid out, tackling the many steps of the release process.
The main plan of attack here is to use github actions, a fantastic workflow that we use for everything from running our builds to updating autocompletion data inside Mudlet. Writing a new workflow has a relatively low entry barrier, the infrastructure that github offers is quite solid and stable, and there’s over 13,000 third-party actions that we can just lift and re-use within our workflow – making it an excellent choice for the task at hand.
With that foundation in mind, over the last couple of weeks we’ve started tackling the problem of overly manual releases.
FloXire was the first to step up to the plate by automating the generation of US English plural forms. For example, while in the source code we’d write “You have just destroyed %n room(s)”, what we really want the player to see is a correctly pluralized form depending on the number of rooms: for one room “You have just destroyed a room” and for many rooms “You have just destroyed %n rooms”. While we still need a human to provide the pluralization, we have at least automated all of the steps around the process and reduced the burden that way.
Next, I took a stab at automating the changelog generation. We already have a changelog generator script in place for our Public Test Builds (PTBs) – so I built upon that script and expanded it from only working for PTBs to being able to create a changelog for any two arbitrary points in time. It can now generate a changelog from the last release to the latest code in development, for any two arbitrary releases – you name it.
Now having a script is nice, but you need access to Lua and the couple of Lua libraries that it makes use of to run it – and this is an unnecessary technical barrier. To solve it, I made use of the aforementioned github actions to create a web-based workflow that any Mudlet developer can run! See the attached generate mudlet changelog.mp4 on how it works.
With these two tasks out of the way, the journey to automating releases has begun. It goes without saying that Mudlet is free and open source, so if you’d like to scratch an engineering itch or learn automation with github actions, feel free to pitch in! I’m happy to help tutor on this.
Enjoy Mudlet,
Vadim.
