Jean-Yves Gastaud blog

Install and configure Renovate Bot on GitLab CE

Sat, 27 Nov 2021 16:14:35 +0100

Renovate Bot is a tool to control the versions of dependencies of your projects.

It can be compared to the Dependabot project which is available on GitHub.

In this article, we will explore how to install and configure Renovate to run on a Gitlab CE instance.

Prerequisites

In order to follow the initialization process you must be able to:

Create groups and projects
Have access or install at least 1 GitLab Runner with a docker executor
Have a GitHub account (even if we are going to use GitLab, it will be used to get the release notes of the projects)

Initialization

Project structure

Create a Renovate project group
Create 2 projects in the group
- a renovate-config project which will contain configuration files that can be shared with all GitLab projects;
- a renovate-runner project which will contain the configurations to dedicate to the Renovate container.

Gitab user

As the name of the project indicates (RenovateBot) we will have to create a user account representing our Bot.

For our example, we will call it Renovate Bot <renovatebot@example.com> and the username renovatebot.

This user will be used for 2 things:

merge requests, commits… will be created by the Bot ;
restrict renovate’s rights to browse only those projects on which it is explicitly invited.

Renovate-runner project configuration

We will start by working on the runner part. Let’s go to the renovate-runner project we created earlier.

Creation of user tokens (PAT : Personal Access Token)

GitLab

On your GitLab instance, log in with the renovatebot account created earlier.

We’ll create an Access Token via your user profile (/-/profile/personal_access_tokens).

Name the token whatever you like (renovatebot for example) and choose the following scopes as indicated in the documentation:

read_user,
api,
write_repository.

Copy the token and go back to the renovate-runner project, in the CI/CD Settings (menu Settings > CI/CD > Variables)

and create a new variable named RENOVATE_TOKEN with the retrieved token value.

GitHub

In order to be able to retrieve release notes from projects and not be subject to the limitations of the GitHub API, we will need to create a GitHub and create a Personal Access Token there.

Copy the token and go back to the renovate-runner project, in the CI/CD Settings (menu Settings > CI/CD > Variables)

and create a new variable named GITHUB_COM_TOKEN with the value of the recovered token.

Our `.gitlab-ci.yml` file

image: renovate/renovate:29	

variables:
  RENOVATE_BASE_DIR: $CI_PROJECT_DIR/renovate
  RENOVATE_GIT_AUTHOR: Renovate Bot <renovatebot@exemple.com>
  RENOVATE_OPTIMIZE_FOR_DISABLED: 'true'
  RENOVATE_REPOSITORY_CACHE: 'true'
  LOG_LEVEL: debug


cache:
  key: ${CI_COMMIT_REF_SLUG}-renovate
  paths:
    - $CI_PROJECT_DIR/renovate

renovate:
  stage: deploy
  resource_group: production
  only:
    - schedules
  script:
    - renovate $RENOVATE_EXTRA_FLAGS

Renovate offers most of these configurations as environment variables. However, to be able to use the bot in other contexts than GitLab (a manual launch for example), I only kept the GitLab specific parameters in the .gitlab-ci.yml file.

The rest of the configurations are in the config.js file that we’ll look at right now. ⬇️

Renovate configuration file

Renovate is based on a configuration file config.js.

It defines the Git platform to use, the configuration options of the runner and the configuration profiles (Config Presets) which will be applied for all the projects onboardingConfig.

module.exports = {
        endpoint: 'https://[url of gitlab]/api/v4/',
        platform: 'gitlab',
        persistRepoData: true,
        logLevel: 'debug',
        onboardingConfig: {
                'extends': [
                        "local>groups/subgroups/renovate/renovate-config"
                ],
        },
        autodiscover: true,
};

Recurring task

CI/CD menu > Schedules
Create a new scheduled task with the frequency you want (I made the choice, totally arbitrary, to run the analysis twice a day) and to trigger.
Save

Configuration of default configurations

In the renovate-config project we will create a simple renovate.json file which will be the one searched by default by the config.json file and in particular the line "local>groups/subgroups/renovate/renovate-config".

Here are the choices I made:

 {
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "depTypeList": [ "devDependencies", "require-dev" ],
      "updateTypes": [ "patch", "minor", "digest"],
      "groupName": "devDependencies (non-major)"
    }
  ],
  "extends": [
    "config:base",
    ":preserveSemverRanges",
    ":dependencyDashboard",
    ":rebaseStalePrs",
    ":enableVulnerabilityAlertsWithLabel('security')",
    "group:recommended"
  ]
}

packageRules allows to create new groupings. In our case, this allows us to have a single Merge Request containing all the development dependencies of the project when they are not major.
Extends allows us to define the rules/configs presets that we want to activate. In particular, we activate the Dependency Dashboard which allows us to follow in a ticket the status of all available updates and/or current MRs and various Group Presets.

Activate the bot for projects

With these configurations, each project that wants to activate the bot has only 4 steps to follow:

Add the user renovatebot on the project, with at least a contributor right
Enable the issues for the dependency Dashboard.
Enable merge requests for first with a 1st Merge Request to create the renovate configuration, then the MRs associated with the updates to apply.
Refine the Renovate configurations according to the specificities of your project

And that’s it 🍾

We now have a Renovate bot that runs regularly and will update all the repositories it has access to.

Sorting tags from a Git repo using semantic versioning

Mon, 20 Sep 2021 23:10:00 +0200

A quick post today to tell you about a recent discovery in Git’s sorting functions and tags based on semantic versioning.

By default, if you run the git tag -l command, Git will do an alphabetical sort.

However, this sorting gives confusing results when the tags use semantic versioning notation.

git tag -l
v2.6.1
v2.6.10
v2.6.11
v2.6.12
v2.6.2
v2.6.3
v2.6.4
v2.6.5
v2.6.6
v2.6.7
v2.6.8
v2.6.9
v2.7.0

Notice here the sequence v2.6.10, v2.6.11 and v2.6.12 which is interposed between version v2.6.1 and v2.6.2.

To solve this problem, it is possible to use the --sort function with the version attribute in Git.

git tag --sort=version:refname

This will display the sorted results consistently:

git tag --sort=version:refname
v2.6.1
v2.6.2
v2.6.3
v2.6.4
v2.6.5
v2.6.6
v2.6.7
v2.6.8
v2.6.9
v2.6.10
v2.6.11
v2.6.12
v2.7.0

Upgrade Buildx in Docker CLI

Sat, 02 May 2020 14:29:42 +0200

Docker CLI, since version 19.03 includes the buildx plugin to extend the build functions of Docker based on Buildkit.

Among the main points that Buildkit brings are the following:

parallel resolution of dependencies
better cache management (import/export, resolution)
ability to distribute workloads
run without root privileges

And so, as mentioned above, buildkit is now included in docker CLI. Problem, the available and pre-packaged version is not up to date with the latest developments.

If you want to take advantage of the latest evolutions, you will need to update.

buildx version

This tutorial uses buildx version 0.4.1.
Remember to check the latest version number before copying and pasting the instructions.

The steps

Check the existence of the ~/.docker/cli-plugins directory. If it doesn’t exist, create the

mkdir ~/.docker/cli-plugins

Download the latest buildx version from the Buildx release page on Github or directly from your terminal.

wget -O ~/.docker/cli-plugins/docker-buildx https://github.com/docker/buildx/releases/download/v0.4.1/buildx-v0.4.1.linux-amd64

Set execution rights on the binary: chmod +x ~/.docker/cli-plugins/docker-buildx.

and voila!

We just have to check if the buildx version is now the expected one.

docker buildx version

If you want buildx to become the default builder of Docker CLI

docker builx install

Demo

Azure-cli, activate autocomplete on Zsh

Tue, 26 Nov 2019 23:35:18 +0100

Out of the box, Azure-cli doesn’t have autocomplete activated in Zsh and Oh-My-Zsh framework doesn’t have plugin available natively.

However, Azure-cli comes with an autocomplete script that should be located in bash_completion.d directory.

In my setup, using Ubuntu 18.04, I found the azure-cli script in /etc/bash_completion.d/ directory.

Now we just need to load the autocomplete script inside our ~/.zshrc with the following line:

source /etc/bash_completion.d/azure-cli

Save and reload your terminal. Done.

Additional notes

If you encounter an error when restarting, you may have to add that line before the script loading to ensure cross compatibility between bash and zsh script

autoload -U +X bashcompinit && bashcompinit

Looking at different blog post, you may find that the script is called az, not azure-cli.
According to the directory I found it, the script was natively loaded if I use bash shell. If you use bash and doesn’t have autocomplete activate, you probably have to search for azure-cli or az script and load it to your ~/.bashrc file.

GoHugo - Generate alternative images that can be used in the homepage

Thu, 11 Apr 2019 16:51:22 +0200

Translate from French on dev.to and backport here.

GoHugo, since version 0.32, is able to manage dedicated one-page resources as well as to generate image declinations.

This feature is particularly useful for automatically managing responsible declinations of these images and using them in a template or shortcode.

It works perfectly when you are in a content.

So what’s the problem?

Let’s assume that we want to use responsible images on the homepage of our site.

The home page is not part of a section or bundle and therefore does not have access to resources
Files placed in the static directory are not treated as resources by Hugo

It will therefore be necessary to manage “by hand”, the declination of these images and include them manually in our template.

To simplify, we have the following aborescence:

.
| content
| | | _index.md
| layouts
| | | index.html

What? But I have too many images to decline and the content changes often?!

To automate the generation process, we will use the Headless Bundles introduced in version 0.35.

This new type of bundle allows you to manage content that will not produce a full page when rendered by Hugo.

It is therefore convenient to use it to manage blocks, messages… which are then injected into the pages.

By using this type of bundle and combining it with the image generation functionality, we will be able to automatically obtain our various image declinations.

We will follow the following steps.

Creating a new bundle `headless-img`

We will now have the following content tree structure:

.
| content
| | | _index.md
| | | headless-img
| | | | | images
| | | | | | my_image.png
| | | | index.md

The file headless-img/index.md will contain

+++
headless = true
title = "homepage images"
+++

{{< imghp src="images/mon_image.png" alt="A nice image for our homepage" >}}

So we have created here a headless resource that will call a hugo shortcode named imghp and that takes a path and an alternative text as parameters.

Creating the shortcode

In the layouts/shortcodes aborescence we will create a new file named imghp.html which will contain the logic of generating our images and their rendering.

{{ /* The shortcode for HP's responsive images */ }}

{{/* get file that matches the filename as specified as src=""" in shortcode */}}
{{ $src := (.Site.GetPage "/headless-img").Resources.GetMatch (printf "*%s**" (.Get "src") }}}

{{/* set image sizes, these are hardcoded for now, x dictates that images are resized to this width */}}

{{ $tinyw := default "500x" }}}
{{ $smallw := default "800x" }}}
{{ $mediumw := default "1200x" }}}
{{ $largew := default "1500x" }}}

{{/* resize the src image to the given sizes */}}

{{{.Scratch.Set "tiny" ($src.Resize $tinyw) }}
{{{.Scratch.Set "small" ($src.Resize $smallw) }}
{{{.Scratch.Set "medium" ($src.Resize $mediumw) }}
{{{.Scratch.Set "large" ($src.Resize $largew) }}

{{/* add the processed images to the scratch */}}

{{$tiny :=.Scratch.Get "tiny" }}
{{ $small :=.Scratch.Get "small" }}
{{ $medium :=.Scratch.Get "medium" }}
{{$large :=.Scratch.Get "wide" }}

{{/* only use images smaller than or equal to the src (original) image size, as Hugo will upscale small images */}}
{{/* set the sizes attribute to (min-width: 35em) 1200px, 100vw unless overridden in shortcode */}}

<img 
{{{with .Get "sizes" }}sizes='{{.}}'{{ else }}sizes="(min-width: 35em) 1200px, 100vw"{{end }}
srcset=''
{{if ge $src.Width "500" }}}
    {{ with $tiny.RelPermalink }}{{{.}} 500w{{{end }}
{{end }}
{{if ge $src.Width "800" }}}
    {{ with $small.RelPermalink }}, {{.}} 800w{{{{end }}
{{end }}
{{if ge $src.Width "1200" }}}
    {{ with $medium.RelPermalink }}, {{.}} 1200w{{{end }}
{{end }}
{{if ge $src.Width "1500" }}}
    {{with $large.RelPermalink }}, {{.}} 1500w {{{end }}
{{end }}''.
{{if.Get $medium }}}
    src="{{$medium.RelPermalink }}" 
{{ else }}}
    src="{{$src.RelPermalink }}}" 
{{end }}
{{{with.Get "alt" }}alt='{{.}}'{{{end }}>>

This template can be found on many sites as an example.

The main difference with the others is in this line:
{{{$src := (.Site.GetPage "/headless-img").Resources.GetMatch (printf "*%s*") (.Get "src") }}}
which allows us to retrieve the resources of the headless-img bundle.

When this shortcode is executed, it will look for the image defined in the headless-img/index.md file and automatically generate the declinations.

And now, how do I display this on my homepage?

All we have to do now is call our bundle in our template index.html.

If you have only one single index.md index content

{{define "content" }}
  {{ /* The rendering of the headless section. Assume */ }}
  {{$headless :=.Site.GetPage "/headless-img" }}
  {{{$headless.Content }}
{{end }}

If you need to render multiple.md files based on a name. `img1`, `img2`… by example

{{define "content" }}
  {{$headless :=.Site.GetPage "/headless-img" }}
  {{ $reusablePages:= $headless.Resources.Match "img*" }}
  {{range $reusablePages }}
    {{{.Content }}}
  {{end }}
{{end }}

And that’s it, now your images are well rendered on your homepage and their responsive versions are also available.

Translated with www.DeepL.com/Translator

Manage distinct profiles in Git

Tue, 02 Apr 2019 00:02:55 +0100

Translate from French on dev.to and backport here.

You use your computer to work and, more than ever, you probably use Git (what would you do on this article if not?).
Perhaps you also work on a personal project on the same computer?
Or to contribute to an Open-Source project, always on the same machine.

You have probably defined a global identity (name + email) for your machine and overloaded it for each project according to the context.

Perfect! Perfect!

And yet despite these usual precautions, who has never commited in a project with a wrong identity? Sometimes you may find this out late and your personal email is now ad vitam æternam in the project logs.

So how can we try to limit the risk of errors?

Could we automate the selection of the right identity for our projects?

Well, the good news is that the answer is YES and we’ll see how right after that.

.gitconfig and conditional includes thanks to IncludeIf

Let’s take the file .gitconfig, usually present in your $HOME.

[user]
	name = Jean-Yves Gastaud
	email = mon.super@mail.com

[alias]
  amend = commit --amend
  st = status
  co = checkout

This file defines our default identity and global aliases.

Thanks to the use of the includeIf¹ directive in our .gitconfig file, we can now add conditional includes linked, especially to directories.

[includeIf "gitdir:/workspace/work/"]
  path = ~/.gitconfig-work

[includeIf "gitdir:/workspace/opensource/"]
  path = ~/.gitconfig-opensource

[includeIf "gitdir:/workspace/perso/"]
  path = ~/.gitconfig-perso

For each defined includeIf, all we have to do is create the file corresponding to the path we defined in path.

In the ~/.gitconfig-work file, we only have to add or override the configurations we are interested in.

Example :

[user]
        email = my.work@mail.com

[core]
        editor = "code -w"

In this file, we overload our email and add a default code editor.

Now, any folder under the /workspace/work directory will automatically benefit from loading the configuration of the .gitconfig file, overloading or supplementing with those of the .gitconfig-work file.

To check your configuration, go to any directory under the target directory, /workspace/work in our example and run the command git config -l

You should see the merging of your config files.

user.name=Jean-Yves Gastaud
email = my.super@mail.com
alias.amend=commit --amend
alias.st=status
alias.co=checkout
includeif.gitdir:/workspace/work/work/.path=~/.gitconfig-work
user.email=my.work@mail.com
core.editor=code -w
includeif.gitdir:/workspace/opensource/.path=~/.gitconfig-opensource
includeif.gitdir:/workspace/perso/.path=~/.gitconfig-perso
core.repositoryformatversion=0
core.filemode=true
…

As you can see, the 2 defined emails are present in the listing.
The last “speaking” being right, it is therefore the value of the file .gitconfig-work which will be considered during the commit.

You will also notice that the other 2 include are listed but do not add new variables / overloads because their application condition is not met.

This always gives us the possibility to overload, locally at the repository, all desired configurations, as before.

In a few lines and a simple management of your working directories, it is therefore possible for you to no longer risk making mistakes in changing your identities.

Since Git, version 2.13 (2017, May). [Documentation on Includes in Git] (https://git-scm.com/docs/git-config#_includes) ↩︎