DEV Community: Romain Lespinasse

Pin GitHub Actions Skill: Automating SHA Pinning with AI Assistants

Romain Lespinasse — Sun, 15 Mar 2026 13:00:00 +0000

SHA pinning GitHub Actions is a well-understood security practice.
Replacing actions/checkout@v4 with a full commit SHA prevents a compromised tag from silently changing the code your CI runs.

The problem is not understanding why to do it.
The problem is doing it.

A typical migration means: enumerate every uses: reference across all workflow files, look up the latest release for each action, resolve the commit SHA (handling annotated tags that need dereferencing), replace every reference, add version comments, and then configure Dependabot so the SHAs stay current.
For a repository with three workflows and six different actions, this is already tedious.
For an organisation with dozens of repositories, it does not scale without automation.

What the skill does

The pin-github-actions skill is part of the agent-skills collection.
It guides AI coding assistants through the full migration, step by step:

Discover — scan .github/workflows/ for all uses: references and report which are already pinned
Resolve — look up the latest release for each action, resolve the commit SHA via the GitHub API, and dereference annotated tags
Pin — replace tag references with SHA # vX.Y.Z format using exact release versions
Configure Dependabot — set up or update .github/dependabot.yml with grouped updates for all discovered ecosystems
Confirm — present every change for review before applying

The assistant handles the API calls, the tag-versus-commit disambiguation, and the file edits.
You review the result.

Major version detection

Not every upgrade is safe.
If your workflow uses actions/checkout@v3 and the latest release is v4.2.2, that is a major version jump with potential breaking changes.

The skill instructs the assistant to flag these jumps explicitly, link to the changelog, and ask whether to upgrade or stay on the latest patch of the current major version.
No silent upgrades across major boundaries.

This matters because a migration tool that blindly pins to the latest version can break workflows in ways that are harder to debug than the security issue it was trying to solve.

Dependabot with grouped updates

Pinning to SHAs without Dependabot creates a maintenance burden — you lose the automatic update notifications that tag-based references provide.
The skill addresses this by configuring Dependabot as part of the migration.

Two design choices are built into the skill:

Grouped updates.
By default, Dependabot opens one PR per dependency update.
For a repository with six actions, that means six PRs every time updates are available.
The skill configures grouped updates so all action updates land in a single PR:

version: 2
updates:
  - package-ecosystem: 'github-actions'
    directory: '/'
    schedule:
      interval: 'weekly'
    groups:
      dependencies:
        patterns:
          - '*'

Multi-ecosystem discovery.
The skill does not stop at github-actions.
It scans the repository for other dependency sources — .gitmodules, package.json, go.mod, Gemfile, Cargo.toml, Dockerfile, Terraform files — and adds each discovered ecosystem to the Dependabot configuration with the same grouped update pattern.

If a dependabot.yml already exists, the skill merges with it rather than overwriting it, preserving any existing labels, reviewers, or ignore rules.

Evaluation with 7 scenarios

The skill includes seven evaluation scenarios that cover the main decision paths:

Pinning all actions in a repository from scratch
Detecting and handling major version jumps
Setting up Dependabot for a new repository
Merging with an existing Dependabot configuration
Auditing already-pinned actions for correctness
Enforcing exact version comments (never major tags)
End-to-end migration combining all steps

These scenarios define the expected behavior so the skill produces consistent results regardless of which AI assistant runs it.

Installing the skill

npx skills add https://github.com/rlespinasse/agent-skills --skill pin-github-actions

Once installed, ask the assistant to pin your GitHub Actions or migrate your workflows to SHA-pinned versions.
The skill activates on keywords like "pin actions", "SHA pinning", "pinned versions", or "supply-chain security".

If you have already installed other skills from the collection — like conventional-commit or diataxis — the process is the same.

From blog post to automation

The earlier post on SHA pinning explained why pinning matters and how to do it manually.
This skill turns that knowledge into something an AI assistant can execute on your behalf.

The tedious parts — API lookups, tag dereferencing, file editing, Dependabot configuration — are handled by the assistant.
The important parts — reviewing changes, deciding on major version upgrades, approving the final result — stay with you.

npx skills add https://github.com/rlespinasse/agent-skills --skill pin-github-actions

Explore the full collection at github.com/rlespinasse/agent-skills.

GitHub Actions Toolbox: A CLI Companion for Your Workflows

Romain Lespinasse — Wed, 11 Mar 2026 10:00:00 +0000

Over the years I have published and maintained a handful of GitHub Actions — github-slug-action, drawio-export-action, release-that, and a few others — many of which are now part of the actions-able organisation.
Once an action gets some traction, a recurring question pops up:
how many repositories actually depend on it?
GitHub surfaces that number on each repository page,
but clicking through every project one by one gets old fast when you have half a dozen actions to keep an eye on.

That itch led me to build github-actions-toolbox — a small Go CLI called ghat designed to gather the kind of information an action maintainer regularly needs, without leaving the terminal.

The problem ghat solves

GitHub's dependency graph is a fantastic feature. It tells you which repositories reference yours in their workflows. The catch is that there is no convenient API to pull those numbers in bulk. You either scrape the web UI or write throwaway scripts every time you want a snapshot.

ghat wraps that scraping into a single, repeatable command so you can fold it into your own dashboards, CI jobs, or just run it from your laptop on a quiet Monday morning to see how things are going.

Using the dependents command

The first — and currently the main — subcommand is dependents. At its simplest, you point it at one repository and it returns the dependent count:

ghat dependents rlespinasse/github-slug-action

When you maintain more than one action, you can pass several repositories in a single invocation. This saves time and avoids rate-limit headaches compared to scripting individual calls:

ghat dependents rlespinasse/github-slug-action rlespinasse/drawio-export-action

For larger inventories, piping from a file or another command keeps things clean. Imagine a repos.txt that lists every action you own — one owner/repo per line — and you get a full report in seconds:

cat repos.txt | ghat dependents

This composability is intentional. Unix pipes are still the best glue between tools, and ghat is designed to play nicely with the rest of your toolkit.

Getting ghat on your machine

The quickest route on macOS or Linux is through my custom Homebrew tap. A single command gets you the latest release, and brew upgrade keeps it current from there:

brew install rlespinasse/tap/ghat

You can browse everything the tap offers with brew search rlespinasse/tap.

If you already have a Go toolchain, installing from source works just as well — and it is handy when you want to pin a specific version or hack on the code yourself:

go install github.com/rlespinasse/github-actions-toolbox@latest

For environments where neither Homebrew nor Go are available — CI runners, Docker images, Windows workstations — pre-built archives are published for Linux, macOS, and Windows across amd64 and arm64. Grab the one that matches your platform from the releases page and drop the binary somewhere on your PATH.

The Homebrew tap behind the scenes

The homebrew-tap repository deserves a quick mention of its own. It is a standard custom Homebrew tap — a Git repository that Homebrew clones locally so it can discover cask and formula definitions beyond the core taps.

Right now it hosts the cask for ghat, but the structure is ready to accommodate any future command-line tools I release. The whole release pipeline leans on goreleaser: when I tag a new version of github-actions-toolbox, goreleaser cross-compiles the binary, packages the archives, computes checksums, and pushes an updated cask definition to the tap repository. This means the Homebrew formula is always in sync with the latest release, with zero manual intervention on my side.

If you maintain your own Go-based CLI and want a frictionless distribution story, I highly recommend pairing goreleaser with a personal Homebrew tap. The setup cost is low and the convenience for your users is significant.

What comes next

The dependents command addresses the most immediate pain point I had, but a toolbox with a single tool is not much of a toolbox yet. There are other pieces of information that are tedious to gather as a GitHub Actions maintainer — marketplace listing details, workflow usage patterns, version adoption curves — and some of those may find their way into ghat over time.

The architecture is intentionally subcommand-based, so adding new capabilities does not break existing workflows. If you have ideas for commands that would make your life easier as an action maintainer, issues and pull requests are very welcome on the GitHub repository.

In the meantime, if you want to give it a spin:

brew install rlespinasse/tap/ghat
ghat dependents your-org/your-action

It takes about ten seconds to install and even less to get your first result.

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.

Pinning GitHub Actions to Commit SHAs: A Practical Security Step

Romain Lespinasse — Wed, 04 Feb 2026 10:37:00 +0000

How a user issue opened my eyes

I maintain github-slug-action, and one morning I woke up to issue #174 — users were suddenly blocked because their organisation had enabled GitHub's new policy requiring all actions to be pinned to a full-length commit SHA.

I already knew that pinning actions to commit SHAs was the right thing to do. Git tags are mutable — they can be deleted, moved, or recreated pointing to an entirely different commit. A compromised repository, a rogue maintainer, or even an honest mistake could silently swap the code your workflows execute, while the logs still show @v4 as if nothing changed. But when you maintain several open source projects on your own, free time goes to the bugs users are hitting right now — not to preventive security work that can always wait until next week.

That issue, combined with a bit more breathing room in my schedule, gave me the space to finally act on it.

What SHA pinning looks like

Instead of referencing an action by tag:

- uses: actions/checkout@v4

You reference it by its full commit SHA:

- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

The commit hash is immutable.
Once a commit exists in Git, its SHA cannot change without changing its content.
Pinning to a SHA guarantees that your workflow runs exactly the code you expect, every time.

The trailing comment (# v4.2.2) is a convention that keeps the version human-readable.
It has no effect on execution — GitHub Actions resolves the SHA, not the comment.

GitHub's immutable release policy

SHA pinning used to be a best practice that teams adopted voluntarily.
That changed when GitHub introduced an organisation-level policy that lets administrators enforce full commit SHA pinning for all actions used in their repositories.

When this policy is enabled, any workflow that references an action by tag — @v4, @main, or any other mutable reference — will fail with an error:

Error: The actions example/some-action@v1 are not allowed in your-org/your-repo
because all actions must be pinned to a full-length commit SHA.

This is a significant shift.
What was once a recommendation is now something organisations can make mandatory across all their repositories.

The sub-action catch

There is a subtlety to this policy that caught some users off guard: it applies to sub-actions as well, not just the actions you reference directly in your workflow files.

This is exactly what happened with github-slug-action.
The action internally references two sub-actions — rlespinasse/slugify-value and rlespinasse/shortify-git-revision — that were pinned by tag.
Users who enabled the SHA pinning policy in their organisation started seeing failures (#174):

Error: The actions rlespinasse/slugify-value@v1.4.0 and
rlespinasse/shortify-git-revision@v1.6.0 are not allowed in your-org/your-repo
because all actions must be pinned to a full-length commit SHA.

The users' own workflow files were fine — they had pinned github-slug-action itself to a SHA.
But the policy checks the entire action dependency tree, including internal references that action consumers do not control.

This means that action maintainers need to pin their sub-actions too, or they block downstream users from adopting the policy.

The fix in practice

In v5.5.0 (#175), all sub-actions referenced within github-slug-action were pinned to full commit SHAs.

Before:

- uses: rlespinasse/slugify-value@v1.4.0
- uses: rlespinasse/shortify-git-revision@v1.6.0

After:

- uses: rlespinasse/slugify-value@750260b26ed3c8e4db9b4833be0a0768a6508e54 # v1.4.0
- uses: rlespinasse/shortify-git-revision@14c50a2e4c952a5a9d29a4ee4bb39068af4a1e3d # v1.6.0

The workflow behavior is identical.
Organisations with the SHA pinning policy enabled can now use github-slug-action without errors.

Keeping SHA pins up to date

The most common objection to SHA pinning is maintenance: "How do I know when a new version is available if I am not using tags?"

Dependabot handles this.
It understands SHA-pinned GitHub Actions and will open pull requests when new versions are released.
The PR updates the SHA and the version comment together, so you get the same update experience as with tag-based references.

Enable it by adding this to your .github/dependabot.yml:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"

Dependabot will detect your SHA-pinned actions and propose updates with the new commit hash and version comment.

What this means for action maintainers

If you maintain a GitHub Action that references other actions internally, you should pin those references to full commit SHAs.
Your users may have adopted — or may be required to adopt — the organisation-level policy, and tag-based sub-action references will block them.

This is a small change on your side that unblocks an entire security posture for your downstream consumers.

Summary

SHA pinning is moving from a best practice to an enforced policy.
GitHub's immutable release support means organisations can now mandate it across all repositories, and the policy checks the full dependency tree — including sub-actions that individual users cannot control.

If you consume third-party actions, pin them to SHAs and let Dependabot handle updates. You can also use the pin-github-actions-skill to streamline the pinning process.
If you maintain actions, pin your sub-actions too — your users will thank you for it.

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?