왜 gaji인가? - TS로 안전하게 GitHub Actions 작성하기

https://hackers.pub/@gaebalgom/2026/%EC%99%9C-gaji%EC%9D%B8%EA%B0%80-ts%EB%A1%9C-%EC%95%88%EC%A0%84%ED%95%98%EA%B2%8C-github-actions-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0

Why Your GitHub Actions Secrets Don’t Work in Reusable Workflow Inputs

We recently migrated our Docker build workflows to use a shared reusable workflow. The migration looked straightforward: extract the build steps, parameterize the inputs, and call the shared workflow with `secrets: inherit`. CI immediately broke.

The fix took 20 minutes. Understanding why took longer, and every answer led to another “but wait” question.

The Setup

The calling workflow passed a Rails master key as a build arg:

This fails at parse time. GitHub validates the workflow file before anything runs and rejects `secrets` in that `with:` block.

Job-Level `with:` Is Not Step-Level `with:`

This is where it gets confusing, because `with:` appears in two very different places in a workflow file, and they have different rules.

Step-level `with:` passes inputs to an action. The `secrets` context is available here:

Job-level `with:` passes inputs to a reusable workflow. The `secrets` context is not available here:

The contexts reference documents this in a table. For `jobs..with.`, the allowed contexts are:

> `github, needs, strategy, matrix, inputs, vars`

No `secrets`.

But the Docs Say Secrets Are Available “From Any Step in a Job”

The secrets context documentation says:

> This context is the same for each job in a workflow run. You can access this context from any step in a job.

That’s true, for steps. The job-level `with:` on a reusable workflow call is not a step. It’s a job-level declaration that gets parsed and validated with a restricted set of contexts before any job runs.

But I Have `secrets: inherit`

The reusable workflows docs explain that `secrets: inherit` implicitly passes secrets to the called workflow. And it does. At runtime, the called workflow’s steps can reference `secrets.RAILS_MASTER_KEY` directly.

The problem is that `with:` is evaluated on the caller side. `secrets: inherit` makes secrets available inside the called workflow, not in the caller’s `with:` expression. These are two parallel channels:

• `with:` sends named inputs (restricted contexts, validated at parse time)
• `secrets:` sends secrets (available at runtime in the called workflow’s steps)

But What About Org vs Repo Secrets?

Doesn’t matter for this error. `secrets: inherit` passes both org-level and repo-level secrets to the called workflow. The error is a static validation failure at parse time. GitHub isn’t even looking at which secrets exist or where they’re stored. It’s rejecting the `secrets` context in `with:` regardless.

The Fix

Pass the secret name as a string through `with:`. Resolve it inside the called workflow where `secrets` is available.

In the calling workflow:

In the shared workflow, add an input and resolve it in the build step:

In the build step:

build-args: | ${{ inputs.master_key_secret != ” && format(‘RAILS_MASTER_KEY={0}’, secrets[inputs.master_key_secret]) || ” }}

The `secrets[inputs.master_key_secret]` pattern dynamically looks up a secret by name. It’s the same approach GitHub’s own docs use for parameterized registry credentials. The input defaults to empty, so repos that don’t need it aren’t affected.

The Takeaway

Two things that look the same in YAML, `with:` on a step and `with:` on a reusable workflow call, have fundamentally different context availability. If you’re migrating from inline steps to reusable workflows and your `secrets.*` references break, that’s why. Pass the name, not the value.

References:

• Contexts reference, context availability table
• Reusing workflows, `secrets: inherit` and workflow inputs
• Secrets context, “available from any step in a job”

When working in a #continuousintegration system, here's a bit of advice: It's generally preferable for the output of the testing suite to be full of green checkmarks, with no red x's.

✅ = Good
❌= Bad

#programming #webdev #github #githubactions #development #cicd #devops

*proceeds to flip table again*

🎙️ Automated my podcast publishing workflow! 🚀

New episodes from my RSS feed automatically become formatted posts on my website using GitHub Actions + R + Quarto.

No more manual work. No more copy-paste. Just automatic publishing.

Built with: R, GitHub Actions, Quarto, magick 📦

Pods: https://federicagazzelloni.com/content/podcasts/
Code: https://github.com/Fgazzelloni/fgazzelloni.github.io

#Automation #RStats #DataScience #GitHubActions

Actioneer now supports workflow_dispatch inputs when triggering workflows manually—dynamic fields, less guesswork.
https://flathub.org/en/apps/me.spaceinbox.actioneer

#GitHubActions #CICD #Linux #Flathub #OpenSource #DevTools

With GitHub Actions, our releases have become automated with a single tag push!

#GitHub #GitHubActions #GHActions #csharp #programming #TechNews #TechUpdates #dotnet #release #tech #dev #development

https://officialaptivi.wordpress.com/2026/02/09/a-single-tag-a-new-release/

https://winbuzzer.com/2026/02/06/github-actions-slowly-killing-engineering-teams-circleci-critique-xcxwbn/

GitHub Actions Called 'Internet Explorer of CI' in Scathing Critique

#GitHubActions #GitHub #Microsoft #SoftwareDevelopment #Developers #DeveloperTools #BigTech #Software #Azure #Buildkite

Actioneer update is live on Flathub: https://flathub.org/en/apps/me.spaceinbox.actioneer

What’s new:

- Job logs render ANSI colors
Workflow sections are grouped (less scrolling, easier to follow)
- Aligned timestamps + clearer command/output formatting
- Stronger error highlighting
- Packaging CI refreshed (multi-arch AppImage/Snap/Flatpak) + dependency updates

#Linux #Flathub #OpenSource #DevTools #CICD #GitHubActions #GTK #FOSS

I've been using Eleventy to build this blog for getting close to two years. It works great. I have some idiosyncracies in how I transfer the blog that is more complex than just an SCP so I created a yarn task for it. The template I use already used yarn so I just continued with that. I created a task called "yarn transfer" that does an scp to move the newly rebuilt blog but also preserve some files outside that process that would otherwise get blown away every time. All good.

The one thing that bedeviled me was the Github Actions. Ideally I would be able to build the site from Github actions on every commit and also set this up on a schedule. It's how I have done other static site generated blogs and it works great. However getting the SSH keys set up always failed for me. I tried a number of things and they all failed. Today I felt like giving it another shot.

This time I tried using the Install SSH Key action prior to the yarn transfer. Getting that key set up never worked right, even though I have my private key in secrets and everything seemed like it should. I set it up and I'll be damned if it didn't work the first try.

Once that worked, I did one more commit to set up a daily schedule. This will allow me to schedule posts ahead of time, namely my podcast episodes, and have Github build them and make them live without my realtime interaction.

This post is being written exactly that way. If you see it as the top post on this site, then the scheduled build worked!