Remote repositories are one of fundamental concepts promoted by Maven. Its use is quite common. It is handled by maven-deploy-plugin, so its migration is something you will probably notice sooner or later. This short post will explain changes in new version of plugin which you need to take care of when moving from 2.8 or earlier releases.
One of most annoying things these days is managing CI/CD with multiple repositories. For quite long time github didn’t offer private repositories while gitlab did. This lead to situation where people been asking gitlab for additional features. One of these is support for mirroring git repositories from github to gitlab just to run pipelines. I happened to have the same requirement.
In this pretty short introduction I am going to describe you a trick which I learned recently while doing new CI/CD configuration for one of open source projects I work with.
Over past couple of months I’ve been playing with gitlab ci as it brings a bit of refreshing breeze after years of struggle with Jenkins. Don’t get me wrong, I value what Jenkins did for us over past decade. I just think that maintenance of it is a bit of nightmare. Yet, I’ve reached a place where I had to adjust some more stuff for gitlab in order to get my builds straight.
One of most important things, if not the most important in software, is release process. There are whole books written about “shipping software” and software release is one of key parts which needs to happen in order to deliver our programs to end users. In this very short post I will give you a short tip about how to do a test drive of a release which is not published yet. One of main principles of maven central is “what goes there, stays there”, meaning that anything which becomes public will stay public. For that reason we, as software developers, want to deploy things which are free of any major issues at release time. Staged release is one of things which are supported by maven-release-plugin. Overall idea behind this is to let people have a test drive before deploying artifacts to public repositories from which they can not be removed. Of course this might be seen as completely unnecessary step if you release a small library, but could be extremely useful for bigger projects, avoiding something I would call a quick fix hiccup. ...