Renovating Ansible


Most of the system administration work that I do has been automated using Ansible, as I've mentioned in posts here, including Deploying with GitLab.

Now that I've got Renovate in place (Renovating GitLab Repos), I am starting to look at how to expand beyond my existing automations in order to let the computers do a bit more of the work.

This weekend's project involved experimenting with the ad hoc, regex-based integrations with Renovate to enable renovating files that might not otherwise be in a form that most dependency managers would recognize.

Conceptually, it makes a lot of sense. Renovate separates the ability to understand different datasources, which provide data on new dependencies from managers, which are used to determine which dependencies are used. This separation, and the level of control and customization enabled by the configuration files, enables some interesting use cases.

Thanks to documentation for Custom Manager Support using Regex, the implementation for my case was pretty straightforward.

Example ansible build process (SmartOS GitLab Runner)

Because Rob and I are using SmartOS, there are frequently components that need to be built separately for the OS, because they aren't available in the package manager or are not directly supported by vendors. One such example is the GitLab runner for SmartOS.

Soon after starting to use GitLab, I submitted a MR to fix some incompatibilities with SmartOS. That was not accepted, but was expanded upon in the expanded MR fixing not only SmartOS, but a number of other Unix-style OSes.

Thankfully, the changes have remained stable and I've had no problem pulling them forward with each release. However, since it's not a supported OS, there's no build for it. As with many tools, I've been building this using a bespoke Ansible script in order to make sure that I have the latest tools and environment.

In my playbook, I define the build version of GitLab runner using a variable, defined as:

vars:
    gitlab_runner_version: 'v15.10.1'

Using the RegEx Manager, I was able to mark this dependency using a comment:

vars:
    # renovate: datasource=gitlab-tags depName=gitlab-org/gitlab-runner
    gitlab_runner_version: 'v15.10.1'

by using a custom renovate.json file in the project:

{
  "regexManagers": [
	{
	  "fileMatch": ["^*\\.yml$"],
	  "matchStrings": [
		"renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\s.*_version: '(?<currentValue>.*)'\\s"
	  ],
	  "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"
	}
  ]
}

This configuration pulls out the comment (starting with the renovate: string) and then pulls the datasource, dependency name (depName), the current value of the version (currentValue), and optionally the version methodology (versioning).

Once checked in, this is now recognized by Renovate and it now generates MRs as necessary:

MR for GitLab Runner

The MR is most of the battle, as I've got plenty of experience automating ansible through GitLab.

Note: Yes, I realize that I'm not using the SmartOS runner to build the SmartOS runner directly, and I may do that in the future. That's a project for another day, since it requires refactoring further how I'm managing builds.