ENOSUCHBLOG
Programming, philosophy, pedaling.
Sep 22, 2025 Tags: programming, rant
TL;DR: for a very long time, GitHub Actions lacked support for YAML anchors.
This was a good thing. YAML anchors in GitHub Actions are (1) redundant with existing functionality, (2) introduce a complication to the data model that makes CI/CD human and machine comprehension harder, and (3) are not even uniquely useful because GitHub has chosen not to support the one feature (merge keys) that lacks a semantic equivalent in GitHub Actions.
This step backwards reinforces GitHub Actions’ status as an insecure by default CI/CD platform by making it harder for both humans and machines to analyze action and workflow definitions for vulnerabilities. GitHub should immediately remove support for YAML anchors, before adoption becomes widespread.
GitHub recently announced that YAML anchors are now supported in GitHub Actions. That means that users can write things like this:
1 2 3 4 5 6 7 8 9 10 11 12 jobs : job1 : env : &env_vars # Define the anchor on first use NODE_ENV : production DATABASE_URL : ${{ secrets.DATABASE_URL }} steps : - run : echo "Using production settings" job2 : env : *env_vars # Reuse the environment variables steps : - run : echo "Same environment variables here"
On face value, this seems like a reasonable feature: the job and step abstractions in GitHub Actions lend themselves to duplication, and YAML anchors are one way to reduce that duplication.
Unfortunately, YAML anchors are a terrible tool for this job. Furthermore (as we’ll see) GitHub’s implementation of YAML anchors is incomplete, precluding the actual small subset of use cases where YAML anchors are uniquely useful (but still not a good idea). We’ll see why below.
... continue reading