… ist Berater für Software-Qualität bei der CQSE GmbH. Er hat an der Universität des Saarlandes Informatik studiert und war nach Abschluss des Studiums fünf Jahre in verschiedenen Projekten als Softwareentwickler und Berater für agile Entwicklungspraktiken tätig, bevor er 2016 seine Tätigkeit bei der CQSE antrat.
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…