GitLab Container Registry is a convenient choice to store Docker images when using GitLab CI. When every pipeline produces a new Docker image tag, you might want to clean up these image tags periodically. By default GitLab only offers a simplified Cleanup policy, which relies on regular expressions to clean up old image tags. But this approach does not take into account which image tags were recently deployed to your environments.

In this blogpost we outline an alternative image tag cleanup mechanism. We query the GitLab API to see which image tags were recently deployed to our environments, and retain these image tags in case we want to rollback.

Getting involved in Open Source software can be fun, as it gives you a glimpse into the future for upcoming versions. One project I’ve been following over the past couple of years is Cucumber for the Java Virtual Machine. There’s a noticeable upcoming change that will remove cucumber-java8, which will certainly affect users of that dependency.

If you’ve been working with Spring Security for a while, it should come as no surprise that from time to time, they deprecate the old, and guide you towards the new. In 5.7.x such a change involves the often used WebSecurityConfigurerAdapter.

And while there are blog posts, release notes, and even an instruction video to highlight the required changes, in the end you will have to change your code. But what all those sources so far have failed to cover, is that there’s now also an easier way to migrate your code, using OpenRewrite.

Renovate can automate your dependency updates, similar to what you might have seen with Dependabot. But where Dependabot requires a community maintained project to run on GitLab.com, Renovate integrates nicely with GitLab.com through official support.

In this blogpost we will walk through setting up Renovate for use on GitLab.com.

Vulnerable and Outdated Components are a top 10 OWASP security threat to applications. To mitigate this risk, there’s a commonly used OWASP dependency-check to scan software to identify the use of known vulnerable components.

In this blogpost we will outline a way to run the OWASP dependency-check for Maven projects on GitLab.com.

Sonarcloud.io is the cloud offering of SonarQube.org. It offers code quality and security scanning, to help developers build maintainable and secure applications. Typically developers install a SonarLint.org plugin in their IDE, for direct feedback. Merge request decoration acts as second line of defence, to ensure no new findings make it past the merge or pull request review.

This blogpost walks you through the steps to setting up Merge request decoration on GitLab.com for Apache Maven projects. There’s a few gotcha’s around setting up merge request decoration, which could lead you to threads like these to debug what you did wrong.

To demonstrate OpenRewrite, this blogpost will walk through upgrading a Spring Boot 1.5 application to 2.5+. Along the way we will pick up JUnit 5, and migrate from Java 8 to 17, with minimal manual intervention.

We’ll start with the Spring PetClinic Sample Application, back as it was almost five years ago in 2017!

When consuming event streams in Apache Kafka, there are various ways of handling exceptions. This blog post will give a detailed example of publishing dead-letter records with Spring Kafka. Areas where we deviate from the defaults will be highlighted, along with the considerations, and tests are provided.

The Gradle Build Cache is particularly well suited to speed up your CI/CD build times. But to set it up properly in GitLab you need to get a few things exactly right. This blogpost will guide you through the steps, as well as provide you with some background.

Kafka Connect is a great tool for streaming data between your Apache Kafka cluster and other data systems. Getting started with with Kafka Connect is fairly easy; there’s hunderds of connectors avalable to intregrate with data stores, cloud platfoms, other messaging systems and monitoring tools. Setting up a production grade installation is slightly more involved however, with documentation at times scattered across the web.

In this post we’ll set up a complete production grade Kafka Connect installation, highlighting some of the choices and configuration quirks along the way.

For illustrative purposes we will set up a JDBC source connector that publishes any new table rows onto a Kafka Topic, but you can substitute any other source or sink connector. All configuration is available on GitHub.

Apache Kafka is often used together with Confluent Schema Registry, as the schema registry allows you to store and retrieve your Avro, JSON Schema and Protobuf schemas for Kafka message (de)serialization. By storing a versioned history of schemas for topic values, with configurable enforced compatibility, you ensure producers and consumers can continue to exchange compact serialized messages even as schemas evolve.

Our team has a (not so) slight tendency to not immediately follow through with our deployments to production. We’ll create and review our changes, merge and deploy to staging, and dilligently test the changes there. And then…​ nothing happens.

It could be that something else needs our immediate attention, or someone else wants to confirm an issue is fixed; Or we might want to deploy at a different point in time as to not disrupt an ongoing process by a service restart. Any which way the result is the same: changes accumulate in staging, and with that the risk involved with the next production deployment.

To nudge ourselves to deploy to production more often we created a Slack App that gives us a daily report of such pending deployments. In this post I’ll showcase the code we use, and how to set up something similar yourself.