Introducing: Annoying Problem #6,399
Every year around this time I make little resolutions to myself. I’m a rebel so I make them in February or March instead of January 1st. Last year, my resolution was to learn more about, and use, Git for my projects, which I have (for the most part) successfully accomplished. This year, it has been to learn more about automated testing and continuous integration with some of my projects.
Enter: the annoyance.
Normally, all I need to get started on something new is to be really annoyed at the problem I’m trying to solve. In this case, the problem was getting apps submitted to Splunk that weren’t in some violation of their instructions (the amount of submissions that violate security and/or good coding rules happens, a lot). I wanted to spell out my thinking a little bit in the hope of a.) helping someone else at some of the things they get annoyed at and b.) having something my developers will take it into account when they start chasing me with pitchforks. So, here we go.
Let’s put some automation in the process
We build A LOT of Splunk apps, some of which get punted back to us for a variety of reasons. Some are handled by AppInspect, or at least it tells us about them, and others it does not.
I decided to try to minimize/shorten the process of us building and submitting a good app, one that follows their rules and pretty much the rules of the world in general. I would not call this “fully continuous integration”, or anything like that, because it doesn’t really push anywhere; however, it is definitely some of the automation we have needed.
An overview of the process goes like this:
Coder Commits code to GitLab (our internal git server) — CI/CD gitlab-runner gets the configuration from our configuration file (.gilab-ci.yml) and runs all the tests, in order (set in the stages section), and only runs the next test if the one before it passes — it will then notify the developer of the status (email, Slack, whatever you have configured).