My team is using Renovatebot for automatic dependency management and is quite happy with it.

Renovate can manage a bunch of dependencies out of the box:

• Tags and Digests of Docker images
• Refs of GitLab Include directives
• Ansible Collections / Roles
• Helm Charts
• Python packages
• and more…

However, we have some versions in a Dockerfile which we use for downloading packages during the build process:

FROM alpine:3.14.0@sha256:234cb88d3020898631af0ccbbcca9a66ae7306ecd30c9720690858c1b007d2a0

ARG KUBECTL_VERSION=1.21.1

RUN wget -q -O /usr/local/bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VERSION}/bin/linux/amd64/kubectl && \
    chmod 0755 /usr/local/bin/kubectl

The KUBECTL_VERSION variable isn’t picked up by Renovatebot automatically, as it has no way of knowing which package this variable references. However you can use the regex manager in the .renovate.json file to provide some context.

I’m currently writing an Ansible role, where I needed to convert a dictionary with camelCase keys to snake_case keys. I can’t change the source dict directly, as it is some form of external config for which the camelCase actually makes sense. As ansible works with snake_case variables normally, I needed to convert the input to a sane format for later consumption.

After a lot of trail-and-error and searching, I found the following two Stack Overflow questions, which massively inspired my final solution:

• All text from camelCase to SNAKE_CASE
• Transform dictionary keys to uppercase

Combining these two methods, I came up with the following solution, which I’d like to share:

converted_dict: |-
  {{
    source_dict.keys()
    | map('regex_replace', '((?!^)|\b[a-zA-Z][a-z]*)([A-Z][a-z]*|\d+)', '\1_\2')
    | map('lower')
    | zip(source_dict.values())
    | items2dict(key_name=0, value_name=1)
  }}  

Update for Grails 2.2+

As of Grails 2.2-RC1 it is possible to simply add a bindable:true to the constraints section of the domain class to allow assignment in the constructor / findOrCreateWhere:

class MyDomain {
    static constraints = {
        // allow binding of "id" attribute (e.g. in constructor or url parameters)
        id bindable: true
    }
}

Intro - Why I chose Maven

Recently I wrote a small program in Groovy. As many of my Groovy projects it all started with a single script. After some coding, I ended up with a script containing 3-4 classes with more to come. So I decided to go for a “real project”: Add a build script and separate every class in its own file.

But… what technology should I use to build this? I knew Maven and Ant and just heard of Gant and Gradle. As I have written some Ant scripts before and have seen different ones from other developers, I quickly decided to skip Ant as an option: The build scripts are way to cluttered and long for “modern times” in my opinion. Furthermore I do not want to spent as much time for writing my build script as I need to write the actual software.

Unfortunately I had not time to research for Gradle or Gant. I know both tools are basically Groovy driven build tools, which makes them a quite natural choice for building a Groovy project. However, my company uses Maven and Ant for nearly all of its builds. So using another build tool would add a technology, developers in my company (including me) need to learn first. So here we are… Maven it should be. (I hope I will be able to use Gradle some time in the future - at least in my hobby projects.)