I started to feel the pain of GitHub Actions the day I had more than two repositories.
Every repo had its own ci.yml, slightly different, slightly broken, and every tiny change (new Node version, new linter, new rule) meant opening the same file again and again.

So I did what any lazy engineer does: I tried to do less by centralizing everything.

One place for the “real” CI

Today, most of my CI logic lives in a single repo: repo-config/shared-actions.

Each project is now just a thin wrapper:

• it declares when to run (push, PR…),
• passes a few inputs (test command, package manager),
• and then calls a reusable workflow from shared-actions.

If I want to change something (for example, the Node version), I change it once in shared-actions, and all the repos following that workflow get the update next run.

Reusable workflows instead of copy‑paste

The key feature I rely on is workflow_call: reusable workflows.

In shared-actions, I keep generic workflows for things like:

• running tests and linters,
• building or packaging,
• a few security / hygiene checks.

They take inputs, and each repo just plugs in its own commands.
No more copy‑pasting 80 lines of YAML for every new project.

Why this works for me

This setup gives me:

• Consistency: all repos share the same base CI.
• Speed: new repos get a decent pipeline in minutes.
• Less mental load: when something is wrong, I know where the source of truth is.

Conclusion

“How I configure GitHub Actions at scale?”
By being lazy on purpose: I put my CI brain in repo-config/shared-actions, and let each repository call it with just a few lines of YAML.

It’s not perfect, but it’s simple enough that I actually use it — and that’s usually the most important part.