… is consultant for software quality at CQSE GmbH. He studied computer science at the Saarland University and, after obtaining his master’s degree, worked for five years as software engineer and agile coach in various projects before joining CQSE in 2016.
If you are using GitLab CI as your build server, you might be familiar with the
[skip ci] syntax documented in https://docs.gitlab.com/ce/ci/yaml/#skipping-jobs—it gives you the option to skip a build entirely by including this tag in your commit message, for example when you are only committing documentation changes.
However, there are scenarios when a build is still required but certain stages can be skipped. Let’s say you are preparing a new release, which requires a changelog entry. In this case, you can’t use
[skip ci] because you’ll probably have the release build included in your pipeline as one of the last steps (and if you don’t, I am going to suggest that it’s high time you did). On the other hand, even if you need the release build, you can probably skip some of the earlier steps (such as test executions) if they
Since release version 3.4, Teamscale has offered support for Gerrit. Over the last months, we have steadily worked to extend and improve this support even further to cover all conceivable use cases. In this post, I am going to show you how this support looks like to the Teamscale end user.
If you are developing a legacy code base with tests, you might still be stuck with JUnit 3—up until recently, I was in the same boat. However, we decided to take the plunge and migrate to JUnit 4. It was well worth it! If you want to know why and how we did it, read on…