Avoiding Neighbours

 2 years later and where did my CI journey take me?  Well as it turns out not very far. My first migration to CircleCI was so successful that I didn't feel the need to go any further! CircleCI  hasn't been perfect, there have been issues with performance and a pretty public data breach but that has not put me off! Once you have fixed on a CI system that fulfils the basic requirements then they are pretty sticky! In hindsight I knew  CircleCI  would be pretty good if you look at the number of posts and public reviews it always comes out well so I should probably have started with the unlikely candidates first! Now we're 2 years on has anything changed? The answer is no - not really. As of the date of this post this GitHub repo  ligurio/awesome-ci  has a great well maintained list of CI servers/services so if  CircleCI  doesn't do it for you then you're bound to find one that does by reviewing that list.  For me, I'll stick with  CircleCI  - at least for now!

Migration number 1... CircleCI  how did it go and what did I think? Well it was pretty smooth, the free tier worked pretty well. The configuration for a Java project was smaller than what I ended up with with Shippable (I could remove some of the boiler plate setup). The builds were significantly faster than Shippable. Initial implementation was quick to do, I like the way it walked me through creating the first configuration. however trying to refine it into something more robust took a fair amount of time and that is where I came across some of it's shortcomings: Workflows are a bit confusing, and whilst it seemed like they would be ideal for different flows for building and publishing the artefacts this ended up not being the case and it would have been simpler just to use jobs at the top level if it wasn't wanting to inject 'secrets' into the build. Unable to define a global setup step, this looks like what an 'orb' would be used for but ended up just sourci

Well the news today is that Shippable has gone , well at least in my mind it's gone in reality it is going on May the 3rd 2021. To be honest it came as a surprise, how did I miss that JFrog had bought Shippable? How did I miss any announcements that Shippable would disappear? How did I miss that there wouldn't be a simple migration to JFrog Pipelines and Why did JFrog name the product the same as Atlassian? All rubbish questions, the one question really is where shall I move my CI to? Which CI? There's the million dollar question. I am a huge proponent of the Gradle build system and and loved the Nebula plugins, but the CI build info plugin only supported a few of the more common CI tools at the time so I extended it with the  Gradle Extended Info Plugin  to provide support for more CI systems. Why this preamble? It led me to review CI and came to the conclusion that Shippable was the one for me and I had stuck with it since even through breaking changes and weird docker is

I previously noted that Gradle has no built in enforcement rules, there is a blog here detailing how you can add your own, but that's not satisfactory for a number of reasons which I won't go in to. What is one to do? Well this one took that as a challenge so the gauntlet has been thrown down and accepted! Sweeney Well the first rule of any development is to come up with a suitably obscure and memorable name. So my thinking went: enforces rules -> like the police -> what do we call the police? Well a number of things but in the UK 'The Sweeney' was a memorable Police drama (at least for me) hence sweeney! Sweeney Gradle Plugin The sweeney gradle plugin supports a few basic rules out of the box with a couple of specifics for the Java and Gradle versions, it also supports enforcing rules and emitting warnings from rules.  Built in Rules Out of the box it has an equality, pattern and version range rules that can be configured, using syntax very similar

If you use Shippable as your Continuous Integration server on an open source project hosted on Github you will find that by default you cannot push any changes back to Github such as when you increment a version number and wish to push the changes back. This is because Shippable uses HTTPS for public Github repositories so trying to push changes back to it will require a username and password. Solution The solution is actually simple and requires two steps, firstly installing the the deployment key in your user or repository and then switching git over to ssh rather than https. Deployment key You can find your shippable deployment key on the right hand side of your account, this is a standard SSH public key, copy this key. You can either add this key to your repository or to your user (or another user if you so choose) that has access to your repositories. Be aware though that Github restricts the re-use of keys so if you add it to your repository then you can only have it

We've all got used to various maven features that we have come to rely on, and in my effort to migrate to Gradle I have endeavoured to find alternative replacments, one of which is the parent POM functionality. Gradle does not natively have this feature that as Maven users we rely on. Workarounds There are a number of workarounds documented, firstly the most common is to use the apply from to load a file from a URI (you can use a URL) but this is not ideal for many reasons. The alternative is to write your own plugin that alters your build.gradle file. Anorakgirl has a great write-up on how to do this here  Gradle and the parent POM  and is the inspiration for my plugin. Gradle pater-build plugin I love Anorakgirls write up but I was thinking that it really is a workaround and devs would need to start to understand the internal Gradle API, so if the apply from syntax has its short comings as Anorakgirl pointed out then how about subverting or working around them. I created