Jean-Yves Gastaud blog

Running GitLab CI on Cloudflare Workers & Containers: a custom GitLab Runner executor

Tue, 11 Aug 2026 10:00:00 +0200

GitLab CI runners traditionally run on VMs or Kubernetes pods that you have to size, keep warm, and pay for even when idle.

What if job execution was pushed onto a serverless platform like Cloudflare instead, with a container provisioned on demand, by the second, for each job?

That’s the question I wanted to dig into with gitlab-runner-cloudflare: a GitLab Runner executor that runs CI jobs on Cloudflare Workers + Containers.

Why this project

GitLab Runner exposes a Custom Executor: a very simple interface (config / prepare / run / cleanup), deliberately agnostic of transport and underlying infrastructure. There’s no built-in notion of Docker or SSH — it’s entirely up to the executor to decide how and where the job runs.

That genericity is what made me want to test a hypothesis: is this interface open enough to be wired onto a serverless platform like Cloudflare Workers and Cloudflare Containers, instead of the usual VMs, Docker, or Kubernetes?

If it holds up, the interesting payoff is a very different cost model: no runner fleet to keep warm at all times, a container provisioned (and billed) on demand for each job, at Cloudflare’s edge scale.

This is a POC/R&D-style project: the goal wasn’t to ship a finished product, but to validate feasibility, document the decisions as ADRs, and push through the hard parts (building images without Docker-in-Docker, dynamic job images, arm64…) until there was a concrete answer rather than a gut feeling.

How it fits together

GitLab Runner (on any host, anywhere)
  │  Custom Executor contract (config/prepare/run/cleanup)
  ▼
executor/   Go binary: gitlab-cf-executor
  │  HTTP
  ▼
worker/     Cloudflare Worker control plane
  │  one Durable Object + Container per job
  ▼
container/  Alpine + Kaniko agent (runs the job's script, builds images
            without a Docker daemon)

executor/ is the binary GitLab Runner invokes directly. It talks HTTP to a deployed worker/, with a fully local fallback mode (no Cloudflare account needed) to develop and test without any external dependency.
worker/ is the control plane: it provisions one Container (via a Durable Object) per job, and proxies prepare/run/cleanup to a small CGI agent baked into the container image.

Objectives achieved

The feasibility question has an answer: yes, a GitLab Runner Custom Executor can drive CI jobs on Cloudflare Workers + Containers, validated against a real Cloudflare deployment (not just locally with wrangler dev).
Image builds without Docker-in-Docker: Cloudflare Containers doesn’t grant privileged mode, which rules out Docker-in-Docker, Buildah, and BuildKit (all three need unshare(CLONE_NEWUSER)). The dind-validation spike confirmed that Kaniko manages without any special privileges, and it’s the one that got adopted.
Live-streamed logs: a job’s output streams live instead of being buffered and returned all at once, with a dedicated endpoint to fetch the exit code once the stream reaches EOF — a constraint forced by CGI headers needing to precede the response body.
Dynamic job images: instead of one fixed, curated container image, prepare.cgi pulls and unpacks (via skopeo/umoci) whichever image: a job requests, and run.cgi runs the job’s script chrooted into it — see ADR-0004.
git clone that works even on an image without git: get_sources runs outside the chroot, in the sandbox that does have git, symlinking /builds//cache into the job image’s rootfs — the same principle GitLab Runner’s own Docker/Kubernetes executors use with a dedicated helper.
services:, cache:, and artifacts: support: covered in detail just below.
Tests and CI: 41 Go unit tests on the executor/ side, Vitest unit tests on the worker/ side, and an E2E test that runs a real Kaniko build through a local wrangler dev. All of it automated in .gitlab-ci.yml (tests on every relevant change, manual deploy on main).
Documentation: 5 ADRs tracking the architecture decisions (execution platform, multi-architecture support, docker_autoscaler/fleeting compatibility, dynamic job images, services/cache/artifacts), 2 spikes documenting the hands-on validations, and a README per component.
Authenticated control plane: the Worker’s HTTP API used to be open to anyone who knew its *.workers.dev URL — every route now requires a shared-secret Authorization: Bearer token, see below.

`services:`, `cache:`, `artifacts:`: how it actually works

GitLab exposes a job’s services: to a Custom Executor through exactly one variable, CUSTOM_ENV_CI_JOB_SERVICES — a JSON array, and it’s entirely up to the executor to start/stop them itself. Nothing else is provided: no Docker network, no API to implement, just that one piece of information.

# .gitlab-ci.yml
cf-executor:demo-services:
  services:
    - name: redis:7-alpine
      alias: redis
  script:
    - for i in $(seq 1 10); do nc -z redis 6379 && break; sleep 1; done
    - nc -z redis 6379 && echo "OK" || exit 1

Because every job already runs inside one Cloudflare Container instance (one network namespace), a service doesn’t need container-level isolation — it just needs to run as a background process, chrooted into its own rootfs (unpacked with skopeo/umoci, same as the job’s own image), and be reachable by its alias. start-service.sh uses setsid to detach the process from the CGI request that started it, and the OCI runtime-spec config.json that umoci produces to recover the image’s ENTRYPOINT/CMD without having to redeclare them:

# simplified excerpt from start-service.sh
ROOTFS_DIR=$(pull-image.sh "$IMAGE" "$BUNDLE_DIR")
jq -r '.process.args[]' "$BUNDLE_DIR/config.json" > "$ARGV_FILE"   # ENTRYPOINT+CMD already resolved by umoci
setsid "$LAUNCH_SCRIPT" "$ENV_FILE" "$ARGV_FILE" "$ROOTFS_DIR" >"$LOG_FILE" 2>&1 &
echo $! > "$PID_FILE"

cache:/artifacts: turned out differently: restore_cache/download_artifacts/archive_cache/upload_artifacts are scripts GitLab Runner generates like any other stage, but its own docs are explicit that they shell out directly to the gitlab-runner binary itself — which has no reason to be inside a job’s (dynamically pulled) image. The fix reuses the same pattern already in place for get_sources/git: widen the set of stages that run outside the chroot, in the sandbox that has that binary:

# run.cgi
case "$stage" in
  get_sources|restore_cache|download_artifacts|archive_cache|archive_cache_on_failure|upload_artifacts_on_success|upload_artifacts_on_failure)
    unchrooted_stage=1 ;;
  *)
    unchrooted_stage=0 ;;
esac

docker:dind as a service remains explicitly unsupported, for the same reason it is as a job image (needs privileged mode) — see ADR-0005 for the full writeup.

What the real deployment revealed

This POC runs on one rule: nothing counts as working until it’s run against a real Cloudflare deployment, not just locally or under wrangler dev. Adding services: support paid that rule back three times over — three bugs invisible locally, only surfacing once worker:deploy actually ran and the demo jobs went through the registered runner for real.

1. /etc/hosts is mounted read-only on a real Cloudflare Container. The first implementation appended alias 127.0.0.1 straight into /etc/hosts — this works perfectly in a local Docker test (where /etc/hosts is an ordinary writable bind-mounted file), and fails in production:

$ echo "1.2.3.4 foo" >> /etc/hosts
/tmp/run-script.sh: line 1: can't create /etc/hosts: Read-only file system

$ cat /proc/mounts | grep -E "hosts|resolv"
overlay /etc/hosts       overlay ro,relatime,... 0 0
overlay /etc/resolv.conf overlay rw,relatime,... 0 0

Cloudflare mounts /etc/hosts as its own dedicated overlay, separate from the rest of /etc — but /etc/resolv.conf stays writable. Alias resolution now goes through a local dnsmasq, started the first time a service is declared, answering for known aliases and forwarding everything else to the real upstream resolvers captured before resolv.conf gets rewritten:

# setsid dnsmasq --no-daemon --addn-hosts=/tmp/service-hosts --server=<upstream1> --server=<upstream2>
echo "nameserver 127.0.0.1" > /etc/resolv.conf

2. A failed prepare_exec gets retried up to 3 times by GitLab Runner, against the same container instance. A service already started by an earlier attempt (because a different service in the same job had failed) was still running and still holding its port:

185:M ... # Warning: Could not create server TCP listening socket *:6379: bind: Address in use
185:M ... # Failed listening on port 6379 (tcp), aborting.

A false negative that pointed at the wrong culprit entirely. Each service’s PID is now tracked in its own file, and any leftover instance is killed before a new one starts:

if [ -f "$PID_FILE" ] && kill -0 "$(cat "$PID_FILE")" 2>/dev/null; then
  kill "$(cat "$PID_FILE")" 2>/dev/null || true
  sleep 1
fi

3. The bundled gitlab-runner binary’s version has to track the registered runner’s, not just any recent release. archive_cache invokes gitlab-runner cache-archiver with flags that change between versions; a version mismatch (17.9 bundled vs. 19.2 registered, in this case) fails the call on an unrecognized flag:

Incorrect Usage: flag provided but not defined: -alternate-file
FATAL: flag provided but not defined: -alternate-file

Silently, too: GitLab Runner treats cache failures as non-fatal and still reports the job as succeeded. A green job can be hiding a cache that never actually got created — this only surfaced by reading archive_cache’s own stage log, not the job’s overall status.

All three make the same point as the wrangler dev limitation further down: it looks like Cloudflare, but it isn’t one.

Securing the control-plane API

The Worker was deployed on the public *.workers.dev subdomain, no custom route or domain — and its HTTP API (/jobs/:jobId/{prepare,run,cleanup}) had no authentication whatsoever. Anyone who found the URL could provision and drive containers.

Two ways to fix that: Cloudflare Access (Zero Trust) service tokens, the more “native” Cloudflare-side option, or a plain shared-secret Authorization: Bearer token. Access would have needed a custom domain and zone — which this Worker doesn’t have — plus an Access application configured outside wrangler.toml. The shared secret needs no extra Cloudflare infrastructure at all, just code.

// worker/src/handlers.ts
export function isAuthorized(request: Request, sharedSecret: string | undefined): boolean {
  if (!sharedSecret) return false; // fails closed if the secret isn't configured
  const header = request.headers.get("Authorization") ?? "";
  if (!header.startsWith("Bearer ")) return false;
  return timingSafeEqual(header.slice(7), sharedSecret);
}

Checked before the route is even parsed, so an unauthenticated caller can’t tell an existing route from a 404. The constant-time comparison is hand-rolled rather than crypto.subtle.timingSafeEqual — that method is a Cloudflare-only Web Crypto extension, missing from Node’s SubtleCrypto, and this file is deliberately kept testable under plain vitest (not @cloudflare/vitest-pool-workers).

On the executor/ side, GITLAB_CF_EXECUTOR_WORKER_TOKEN (same value as the Worker’s SHARED_SECRET, set via wrangler secret put, never committed) rides on every request. And like the three bugs in the previous section, the real proof came from a real deployment: the first demo job retried after wiring this up failed with 401 unauthorized — not a false negative, but proof that the gitlab-cf-executor binary already running on the registered runner predated the fix and was sending no token at all. Rebuilt, the job went green again.

Current limitations / what’s left

This is a POC, not a finished product. What’s still unresolved:

No arm64 lane: Cloudflare Containers is amd64-only. The provider choice for the arm64 side (AWS Graviton, Oracle Ampere, Hetzner) hasn’t been made, and the resulting docker_autoscaler/fleeting integration isn’t built yet — see ADR-0002 and ADR-0003.
No private registry auth for dynamic image pulls: skopeo copy supports --src-creds, but it isn’t wired up yet.
No cross-job layer cache: each job’s container is destroyed at cleanup, so every job re-pulls its image from scratch. An R2-backed cache is a candidate if pull latency becomes a real problem in practice.
cache: persistence across jobs is still the runner operator’s responsibility: restore_cache/archive_cache now run correctly, but without [runners.cache] configured in config.toml (an S3-compatible backend, e.g. R2), there’s nowhere for them to persist to — that’s infrastructure configuration, not something this project can provide from inside the container.
Services get only a single default alias, derived from the image name (postgres:14 → postgres), not GitLab’s full multi-alias scheme — an explicit alias: covers the more complex cases. They also start sequentially rather than in parallel, and with no readiness protocol: a job script has to poll the service itself (matching GitLab’s own general guidance).
Build ≠ run within the same job: Kaniko can build and push an image, but there’s no mechanism yet to run that freshly built image as part of the same job.
No direct SSH/debug access into a running Cloudflare Container instance for local troubleshooting.
wrangler dev is unreliable on long-running requests (Kaniko builds, cold starts) — confirmed local-dev-only, with no impact on a real deployment, and tolerated rather than fixed in the E2E tests.

Each of these is tracked with its sources in docs/TODO.md.

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.

Gitlab 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) ↩︎