This article is part of my #100DaysOfCode and #100DaysOfBlogging challenge. R1D3

Today I was working with keep a changelog, especially with Matthew Weier O’Phinney’s implementation of it. I am fascinated by the idea of managing the CHANGELOG from the command line.

Installation

Setup is thanks to composer straight-forward. You can either install it locally or globally. I went with the latter.

composer global require phly/keep-a-changelog

If you haven’t already, remember to add the global composer bin path to your PATH environment variable.

Commands

Now let’s have a look at it.

keep-a-changelog commands

Setup

Getting started is as simple as

keep-a-changelog new

By default keep-a-changelog starts with version 0.1.0. The option -i, --initial-version=INITIAL-VERSION allows you to overwrite it. If you want a filename other then CHANGELOG.md, use option -f, --file=FILE.

Configuration

In the configuration a (provider api) token, provider and custom domain may be stored. It can be initialized with

keep-a-changelog config

You then will be asked to provide the required information. By using the option -g, --global, it is possible to store the configuration globally. This helps reusing the configuration in other projects and prevent accidentally committing it to the VCS.

Available Providers

The package is shipped with two Providers:

  1. GitHub (default) and
  2. GitLab.

Since my employer is using Beanstalk, I got curious, if it was possible to implement a provider it.

Curiosity

I cloned the repository and digged into the code. Quickly I came across a piece of code which could be a party-pooper. The EntryCommand::preparePatchLink() method throws an exception if no valid PR link is generated by the provider. Now Beanstalk don’t do no PRs. A quick check with mwop restored hope, saying --pr is never a required option.

To infinity and beyond

Awesome. I rolled up my sleeves and started implementing a Beanstalk provider. Thanks to the neat code the internal features were done in couple of minutes. Now only adding a Beanstalk API client and that would be it. At least that is what I thought.

Disillusionment

Looking for candidates on GitHub and Packagist did not look good at all. There might be a package or two that might work, but neither received any updates in years and the code has great improvement potential.

Implementing a PHP client library for the Beanstalk API goes beyond the scope of today’s challenge.

Conclusion

Although there is currently no working provider for Beanstalk, I still want to see the keep-a-changelog in action in a project. On another day I will evaluate the tool in a GitHub or GitLab project and see how it fits into our workflow. So long.