Deciding where custom logic should live

I use this mental model when deciding how far to go with custom actions:

1. Can you use a marketplace action? Prefer a well-maintained third-party action when it fits.
2. Is a small shell snippet enough? Embed it directly in your workflow or move it to a Makefile/Taskfile for reuse.
3. Sticking with shell but want reuse? Wrap it in a composite action or reusable workflow depending on how much structure you need.
4. Need richer logic or dependencies?
   • No external dependencies → consider a script checked into your repo and called from the workflow.
   • Need packaging/dependencies → choose between a JavaScript/TypeScript action (best GitHub integration) or a container action (maximum language/runtime flexibility).
5. Building a long-lived tool? Invest the time to create, test, and version a dedicated action.

Publishing and sharing your action

• Marketplace: If your repository is public and contains an action.yaml at the root, the GitHub Releases UI will offer to publish it to the Marketplace. Complete the checklist (metadata, README, categories) and publish like a normal release.
• Private sharing: Keep the source in the same repository or configure Settings → Actions → Access on the source repo to allow other private repositories in your organization to consume it. Private actions cannot be used from public repositories.
• Referencing: Whether public or private, pin actions by tag or commit SHA (owner/repo/path@<sha>) to ensure deterministic builds.