Forem: Romain Lespinasse

Open Source Maintenance: Do I Need to Update My License Year?

Romain Lespinasse — Fri, 20 Feb 2026 22:05:18 +0000

If you’ve been maintaining a project since 2019 and have reached a milestone like v5.x, you might wonder if that "2019" in your LICENSE file makes your project look abandoned.

Here is a quick guide on how to handle license dates effectively without overthinking it.

The "First Publication" Rule

In an MIT or Apache license, the year (e.g., Copyright (c) 2019) marks the year of first publication.
It isn't an expiration date. However, as your project evolves through major versions, your code changes significantly.

Using the Copyright Range

Instead of choosing between the start year and the current year, the professional standard is to use a range.

Bad: Copyright (c) 2019 (Looks abandoned)
Better: Copyright (c) 2026 (Wipes out the history of the original work)
Best: Copyright (c) 2019-2026 (Protects the original v1.0 and the current v5.x)

When to Update (The SemVer Strategy)

If you follow Semantic Versioning, you don't need to touch the license for every patch.

Version Type	Update License?	Reason
Major (v5.0.0)	Highly Recommended	Significant refactors or breaking changes are new "works."
Minor (v5.1.0)	Recommended	New features should be covered under the latest year.
Patch (v5.1.1)	Optional	Bug fixes rarely require a copyright update.

Automation: The "Set and Forget" Method

If you find manual updates tedious, you can use a GitHub Action to check your license at the start of every year.

FantasticFiasco/action-update-license-year GitHub Action will handle it for you.

name: Update copyright year(s) in license file

on:
    schedule:
        - cron: '0 3 1 1 *' # 03:00 AM on January 1

jobs:
    update-license-year:
        runs-on: ubuntu-latest
        steps:
            - uses: actions/checkout@v6
              with:
                  fetch-depth: 0
            - uses: FantasticFiasco/action-update-license-year@v3
              with:
                  token: ${{ secrets.GITHUB_TOKEN }}

This action will detect your 2019 start date and automatically transform it into 2019-2026, keeping your project looking active and professional.

Summary

For a project spanning several years, simply update your license header to:

Copyright (c) 2019-2026 [Your Name]

This tells the world your project is established, battle-tested since 2019, and actively maintained in 2026.

💡 Note
This post was originally published on my personal blog.

The Simplest Way to Make Just Interactive: Use --choose

Romain Lespinasse — Fri, 20 Feb 2026 22:02:50 +0000

The "Native" Way

While you can manually pipe just --list into fzf, just has a built-in feature that handles this natively.
If you have fzf installed, you don't need a custom recipe at all.

The One-Liner

Simply run:

just --choose

This command automatically parses your recipes, opens fzf, and executes your selection once you hit Enter.

Level Up with Shell Aliases

If you find yourself running specific types of tasks frequently, you can combine just --choose with a shell alias.
This is perfect for filtering down to specific "namespaces" if you use a prefix naming convention (e.g., docker-build, docker-up).

Add this to your .zshrc or .bashrc:

# General interactive just
alias j='just --choose'

# Interactive just filtered for Docker tasks only
alias jd='just --choose --chooser "fzf --query=docker"'

Customizing the UI

You can customize the look and feel of the chooser globally by setting the JUST_CHOOSER environment variable.
This allows you to add colors or change the layout without touching your justfile.

export JUST_CHOOSER='fzf --header "⚡ Select Task" --height 40% --layout reverse --border'

Why this is better:

Zero Boilerplate: You don't need to pollute your justfile with a "menu" recipe.
Clean Output: It respects docstrings and ignores internal recipes (those starting with an underscore).
Speed: It’s a single binary call rather than a chain of piped commands.

The "One-Touch" Justfile

If you want the interactive menu to appear by default when you just type just in your terminal, add this to the top of your file:

# Run the interactive chooser by default
default:
    @just --choose

Conclusion

Ultimately, using just --choose transforms your justfile from a static list of commands into a dynamic, user-friendly CLI.

By moving away from manual piping and embracing built-in flags and environment variables, you reduce maintenance overhead while significantly improving your daily terminal workflow.

Whether you’re automating a complex Docker environment or just looking for a faster way to trigger local builds, making your tools interactive by default ensures that your productivity stays as high as your command-line efficiency.

💡 Note
This post was originally published on my personal blog.

Batch Resize Images on macOS via CLI (The Native Way)

Romain Lespinasse — Fri, 20 Feb 2026 21:59:38 +0000

If you often need to resize dozens of images tucked away in various subdirectories.
While apps like Photoshop or Lightroom are powerful, they are overkill for a simple task: resizing all png files to a maximum of 200px.

Forget installing heavy dependencies like ImageMagick.
macOS comes with a built-in "secret weapon" called Sips (Scriptable Image Processing System).

The Scenario

You have a project structure like this:

/assets/products/category-a/item1.png
/assets/products/category-b/item2.png

You want to resize these to 200px (max side) and save them as _200px.png in the same folders, keeping the originals intact.

The One-Liner Solution

Open your terminal, navigate to your root folder, and run:

find . -name "*.png" -exec sh -c 'sips -Z 200 "$1" --out "${1%.png}_200px.png"' _ {} \;

Breaking Down the Command

To understand what's happening under the hood, let's look at the components:

Command Part	Purpose
`find .`	Searches the current directory and all subfolders.
`-name "*.png"`	Filters only the files ending with your specific suffix.
`sips -Z 200`	Resizes the image so the largest dimension is 200px (preserving aspect ratio).
`--out ...`	Specifies the output path so we don't overwrite the original.
`${1%.png}_200px.png`	A shell trick to strip the `.png` extension and append our new suffix.

Why Sips?

Sips is remarkably fast because it is optimized for the macOS file system and hardware.
Unlike other tools, it:

Respects Color Profiles: It uses Apple's ColorSync technology.
Zero Install: It has been part of macOS for decades.
Smart Scaling: Using the -Z flag ensures your images never look "stretched" as it maintains the original proportions.

Pro Tip: If you want to overwrite the original files instead of creating new ones, simply use:
find . -name "*.png" -exec sips -Z 200 {} \;

Summary

Next time you're preparing thumbnails for a gallery or optimizing assets for a website, don't reach for a GUI.
The power of the macOS CLI is right at your fingertips.

💡 Note
This post was originally published on my personal blog.

How to Add a Photo to an Existing Page in a PDF Using macOS Preview

Romain Lespinasse — Fri, 20 Feb 2026 21:56:49 +0000

If you have ever tried to paste an image into a PDF using the macOS Preview app, you probably ran into a highly frustrating issue.

Instead of dropping the image onto the page you are currently viewing, Preview insists on pasting the image as a completely new, blank page.

Preview doesn't have a standard "Insert Image" button. However, there is a hidden workaround that lets you paste a photo as a movable, resizable object directly onto an existing PDF page.

The "Paste-Into-Itself" Method

Open the image: Double-click your photo to open it in the Preview app.
Copy the image: Press Command + A (⌘A) to select the entire image, then press Command + C (⌘C) to copy it to your clipboard.
Paste it into itself: Without leaving your image window, press Command + V (⌘V) to paste.

How to know it worked: This creates a duplicate "object" layer directly on top of your original image. The new layer will have a bounding box with little blue dots on the corners.

Select and copy the new object: This is the most crucial step! Make sure you explicitly click on that newly pasted image layer so that those blue corner dots are actively selected.

Once it is selected, press Command + C (⌘C) to copy this specific object.

Open your PDF: Switch over to the PDF document you want to edit (also opened in Preview).
Select the target page: Click directly in the middle of the actual PDF page where you want the image to go.

Warning: Do not click the thumbnail in the sidebar, or Preview will default back to creating a new page.

Paste and adjust: Press Command + V (⌘V).

Your image should now drop successfully onto your PDF page!

From there, you can click and drag it into position and use the blue corner dots to resize it to fit perfectly.

When you are finished, just hit Command + S (⌘S) to save your newly updated PDF.

💡 Note
This post was originally published on my personal blog.

Optimizing Shared GitLab Pipelines: Flexibility and Maintainability

Romain Lespinasse — Fri, 20 Feb 2026 21:45:30 +0000

The Challenge

A colleague seeks to modify the script section of a job in a shared GitLab pipeline, facing hardcoded configuration:

  # https://gitlab.com/rlespinasse/foobar-shared-ci-templates/-/blob/main/pipeline-with-hardcoded-values.yml
  test-branch:
    stage: test
    before_script:
      - ls
    script: # it's for the example, the script can be more complex
      - ls ./wrong-folder

This rigid setup causes pipeline failure in their project:

  # https://gitlab.com/rlespinasse/foobar-project/-/blob/main/.gitlab-ci.yml
  include:
    - project: 'rlespinasse/foobar-shared-ci-templates'
      ref: HEAD
      file:
        - '/pipeline-with-hardcoded-values.yml'

  $ ls ./wrong-folder
  ls: cannot access './wrong-folder': No such file or directory

Ideal Solution

The optimal approach involves implementing variables as configuration points:

  # https://gitlab.com/rlespinasse/foobar-shared-ci-templates/-/blob/main/pipeline-with-variables.yml
  variables:
    FOLDER_TO_TEST: wrong-folder

  test-branch:
    stage: test
    before_script:
      - ls
    script:
      - ls ./${FOLDER_TO_TEST}

This method allows for easy customization:

  # https://gitlab.com/rlespinasse/foobar-project/-/merge_requests/2
  include:
    - project: 'rlespinasse/foobar-shared-ci-templates'
      ref: HEAD
      file:
        - '/pipeline-with-variables.yml'

  variables:
    FOLDER_TO_TEST: folder

  $ ls ./${FOLDER_TO_TEST}
  some-file

Temporary Workaround

In the meantime, one can override only the script part:

  # https://gitlab.com/rlespinasse/foobar-project/-/merge_requests/1
  include:
    - project: 'rlespinasse/foobar-shared-ci-templates'
      ref: HEAD
      file:
        - '/pipeline-with-hardcoded-values.yml'

  test-branch:
    stage: test
    script:
      - ls ./folder

  $ ls ./folder
  some-file

Conclusion

While functional, this temporary solution may lead to divergences and maintenance issues.

It's recommended to contribute to open source or innersource projects (especially during Hacktoberfest) by proposing the addition of variables.
This would allow users to adapt shared pipeline behaviors to their needs while preserving the original intent.

Explore the code

You can explore the code on those repositories:

💡 Note
This post was originally published on my personal blog.

Hacktoberfest 2020: Lessons learned as Maintainer

Romain Lespinasse — Sun, 01 Nov 2020 18:11:06 +0000

In addition of my participation for the 4th time in a row, This year report will focus on my activity as Maintainer.

as Creator

Project ideas come from everywhere, don't limit yourself and create a public repository even when you may be the only user.
Don't be perfect from the start, you can improve your project during its lifetime.
You can choose any name for your project, sometimes a descriptive name, sometimes a play of words.

as Maintainer

Learn to say no as Maintainer or to choose your own way to deal with a situation.
Don't support all releases of your project all the time, you can depreciate version series.
Don't be afraid to archived a project if you unmaintained it.
Don't put yourself under pressure to respond quickly as possible to issues or pull-requests submissions.

This post may be edited overtime with new lessons:

Don't stop learning

Hacktoberfest 2020: github-slug-action Maintainer

Romain Lespinasse — Sun, 01 Nov 2020 17:49:47 +0000

In addition of my participation for the 4th time in a row, This year report will focus on my activity as Maintainer.

Some projects ideas can start from a colleague tweet.

rlespinasse / github-slug-action

GitHub Action to expose slug value of GitHub environment variables inside your GitHub workflow

This idea behind github-slug-action is one of them (tweet in French)

// Detect dark theme var iframe = document.getElementById('tweet-1191827751751299074-278'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1191827751751299074&theme=dark" }

From this SLUG variable need, I start to develop my first GitHub Action. Using docker-based container and some bash script with sed or cut, I create the first version of this action quickly.

master end-of-life

// Detect dark theme var iframe = document.getElementById('tweet-1254456661886066689-635'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1254456661886066689&theme=dark" }

After sometimes, github-slug-action start to be used by multiples projects and some enhancements have been asked.

This lead to a version bump to 2.x due to a breaking change in April 2020. Due to that breaking change, I take the decision to change my branching strategy to adopt a vX.Y branch naming to better manage this type of change.

The master branch have been depreciated

github-slug-action - master branch EOL #15

rlespinasse posted on Apr 26, 2020

Due to changes into the branches management, the master branch is not longer supported and will be removed in few months (EOL: 2020-10-25).

After a search, here is the list of projects who use master branch for this action inside their workflows.

[x] danielr1996/docker-action-multitag#4
[x] doerfli/feedscraper#93
[x] patou/liste-envies#97
[ ] kingkool68/testing-github-actions#1
[x] TardisBank/TardisBank#48
[x] feinoujc/node-app#1
[x] dormdev/dormdev#5
[x] 7mind/izumi-docker#1
[x] elmerfdz/rebuild-dndc#31
[x] VladPodilnyk/d4s-example#2
[x] LuanaFn/avas-denuncia-backend#12
[x] time-machine-project/requests-for-comments#9
[x] chiffre-io/push#44
[x] elmerfdz/docker-traktarr#8
[x] elmerfdz/docker-statping#15
[x] yngwi/requests-for-comments_test#6
[x] jupitermoney/base-images#2
[x] elmerfdz/docker-bind#5
[x] zio/izumi-reflect#21
[x] PlayQ/d4s#48
[x] doerfli/rss-mock-server#8
[x] thecodingmachine/workadventure#58
[ ] voxeet/voxeet-uxkit-react#2
[x] Meemaw/Insight#17
[ ] kingkool68/wordpress-child-themes#25

View on GitHub

A removal of the master branch have been plan 6-months later. This work is complete.
Some repositories still used the master branch and a pull-request to migrate have been created of each of them during October before the master branch deletion.

TIP: Use Dependabot to manage versions of used GitHub Actions in your workflows

Docker-based GitHub Action limitation

Other operating systems support #16

aminya posted on Jun 28, 2020

What dependency this is using that prevents it from running on other operating systems?

View on GitHub

Currently, a docker-based GitHub Action can only run on Linux-based workflows.

In order to manage Windows-based and Macos-based workflows, the action need to be rewrite as Javascript-based action. In September 2020, @Ameausoone have took up the challenge to migrate to Typescript.

Thanks you.

GitHub Action CVE

During the Hacktoberfest, the GitHub Action have been impacted by a CVE on one of the GitHub Action core feature that been in used : GHSA-mfwh-5m23-j46w.

Thanks you @boolooper for the reporting.

On maintained branches, all impacted versions have been updated to fix this CVE and an advisory have been created on the project : GHSA-7f32-hm4h-w77q.

Before Hacktoberfest 2020

Thanks to @Ameausoone, @m4rcs, and @php-coder for yours contributions before this year event.

Hacktoberfest 2020: drawio-cli and drawio-export Maintainer

Romain Lespinasse — Sun, 01 Nov 2020 17:49:31 +0000

In addition of my participation for the 4th time in a row, This year report will focus on my activity as Maintainer.

Earlier this year, I want to be able to automatically export diagrams from a drawio file. This need lead to the creation of 2 new open-sources projects :

rlespinasse / drawio-export

Export Draw.io diagrams using docker

rlespinasse / drawio-cli

CLI for Draw.io

The drawio-cli project is responsible to generate a docker image with a raw cli of drawio (thanks drawio-desktop) for that.

The drawio-export project use the drawio-cli project to enhance initial export capabilities.

Support latest version of Drawio-desktop

At the beginning of Hacktoberfest, @danquash start working of this issue

After an awesome work on debugging the version bump issues, he have create 2 pull-requests (1 on each project)

Support drawio 13.x #5

danquah posted on Oct 02, 2020

As discussed in #4 This pull-requests bumps the drawio-version to 13.7.3 (latest according to https://github.com/jgraph/drawio-desktop/releases/tag/v13.7.3) and installes a required dependency.

Apparently the newer version of drawio requires some arguments to come last, without this last change electron simply quits with a

Error: input file/directory not found

View on GitHub

Support draweio 13.x #29

danquah posted on Oct 02, 2020

This PR moves an argument to the end of the line as seems to be required by newer versions of drawio.

Without this we get a "Error: input file/directory not found" error (tested with version 13.7.3 of jgraph/drawio-desktop)

View on GitHub

Thanks to him.

Enhancements on drawio-export

Some enhancement issues have been available for contribution during this Hacktoberfest 2020.

This new --on-changes option, to improve the speed of diagrams generation, have been develop by @Nico385412.

feat(option): add on-changes-option #34

Nico385412 posted on Oct 11, 2020

resolves #15

I'm not an expert in shell but this pr do the job, i would like to know your opinion on it :D

View on GitHub

Thanks to him.

Before Hacktoberfest 2020

Thanks to @bogaertg and @Decat-SimonA for yours contributions before this year event.

Everybody has a testing environment

Romain Lespinasse — Sun, 20 Sep 2020 18:42:14 +0000

Everybody has a testing environment.
Some people are lucky enough enough to have a totally separate environment to run production in.

From @stahnma

I love this motto, and you?

Keep your draw.io diagrams in sync inside your repository

Romain Lespinasse — Sun, 16 Aug 2020 19:39:22 +0000

My Workflow

You have Draw.io diagram files on your repository? You export them manually to have them as images (png, jpg) or pdf?

You can keep your diagrams as exported images (png, jpg) or pdf and keep them synchronized when the diagram files are updated.

Submission Category:

Maintainer Must-Haves

Yaml File or Link to Code

Example to keep your draw.io files exported as PNG files with associated Asciidoctor pages.

name: Keep draw.io export synchronized
on:
  push:
    branches:
      - master
    paths:
      - "**.drawio"
      - .github/workflows/drawio-export.yml
jobs:
  drawio-export:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout sources
        uses: actions/checkout@v2
        with:
          token: ${{ secrets.GH_TOKEN }}

      - name: Export drawio files to asciidoctor and png files
        uses: docker://rlespinasse/drawio-export:v3.x
        with:
          args: --fileext adoc --folder drawio-assets --transparent --on-changes

      - name: Get author and committer info from HEAD commit
        uses: rlespinasse/git-commit-data-action@v1.x

      - name: Commit changed files
        uses: stefanzweifel/git-auto-commit-action@v4.1.6
        with:
          commit_message: "docs: sync draw.io exported files"
          commit_user_name: "${{ env.GIT_COMMIT_COMMITTER_NAME }}"
          commit_user_email: "${{ env.GIT_COMMIT_COMMITTER_EMAIL }}"
          commit_author: "${{ env.GIT_COMMIT_AUTHOR }}"

Additional Resources / Info

Learn more about the drawio-export docker image.

rlespinasse / drawio-export

Export Draw.io diagrams using docker

Contributions welcome

Access commit info for your release and deployment workflows

Romain Lespinasse — Sun, 16 Aug 2020 19:26:23 +0000

My Workflow

Need to access git commit information in your workflow like this

- name: Get author and committer info from HEAD commit
  uses: rlespinasse/git-commit-data-action@v1.x

- name: Commit changed files
  uses: stefanzweifel/git-auto-commit-action@v4.1.6
  with:
    commit_message: "Automated commit message"
    commit_user_name: "${{ env.GIT_COMMIT_COMMITTER_NAME }}"
    commit_user_email: "${{ env.GIT_COMMIT_COMMITTER_EMAIL }}"
    commit_author: "${{ env.GIT_COMMIT_AUTHOR }}"

Submission Category:

DIY Deployments

Yaml File or Link to Code

This action source code is available on https://github.com/rlespinasse/git-commit-data-action

- name: Expose git commit data
  uses: rlespinasse/git-commit-data-action@v1.x

- name: Print git commit data
  run: |
    echo "Get author info"
    echo " - ${{ env.GIT_COMMIT_AUTHOR }}"
    echo " - ${{ env.GIT_COMMIT_AUTHOR_NAME }}"
    echo " - ${{ env.GIT_COMMIT_AUTHOR_EMAIL }}"
    echo "Get committer info"
    echo " - ${{ env.GIT_COMMIT_COMMITTER }}"
    echo " - ${{ env.GIT_COMMIT_COMMITTER_NAME }}"
    echo " - ${{ env.GIT_COMMIT_COMMITTER_EMAIL }}"

Additional Resources / Info

Currently, use on my client project. If you use it, tell me.

rlespinasse / git-commit-data-action

Action to expose git commit info

Contributions welcome

Use Slug variables for your release and deployment workflows

Romain Lespinasse — Sun, 16 Aug 2020 18:55:44 +0000

My Workflow

Want to use the branch name in an url during a deployment? Want to use a commit hash in a release process?

Slug it.

This action give you access to multiple slug version of some GitHub variables to be use on your release or deployment workflows.

Submission Category:

Maintainer Must-Haves
DIY Deployments

Yaml File or Link to Code

This action source code is available on https://github.com/rlespinasse/github-slug-action

- name: Inject slug/short variables
  uses: rlespinasse/github-slug-action@v2.x

- name: Print slug/short variables
  run: |
    echo "Slug variables"
    echo "   ref        : ${{ env.GITHUB_REF_SLUG }}"
    echo "   head ref   : ${{ env.GITHUB_HEAD_REF_SLUG }}"
    echo "   base ref   : ${{ env.GITHUB_BASE_REF_SLUG }}"
    echo "   event ref  : ${{ env.GITHUB_EVENT_REF_SLUG }}"
    echo "   repository : ${{ env.GITHUB_REPOSITORY_SLUG }}"
    echo "Slug URL variables"
    echo "   ref        : ${{ env.GITHUB_REF_SLUG_URL }}"
    echo "   head ref   : ${{ env.GITHUB_HEAD_REF_SLUG_URL }}"
    echo "   base ref   : ${{ env.GITHUB_BASE_REF_SLUG_URL }}"
    echo "   event ref  : ${{ env.GITHUB_EVENT_REF_SLUG_URL }}"
    echo "   repository : ${{ env.GITHUB_REPOSITORY_SLUG_URL }}"
    echo "Short SHA variables"
    echo "   sha        : ${{ env.GITHUB_SHA_SHORT }}"

Additional Resources / Info

Some repositories already using it like

And more on GitHub search page

rlespinasse / github-slug-action

GitHub Action to expose slug value of GitHub environment variables inside your GitHub workflow

Contributions welcome