Creating Reusable Workflows in GitHub Actions: Best Practices
In the world of CI/CD, efficiency is key. Reusable workflows in GitHub Actions exist to eliminate redundancy and promote maintainability. By allowing you to define a workflow once and call it from multiple places, you can save time and reduce errors in your automation processes.
Creating a reusable workflow involves a few key components. First, you need to include the workflow_call key in your YAML file. This is essential for making your workflow reusable. You can define inputs to pass data from the calling workflow and secrets for sensitive information. For example, the inputs must match the expected data types in the called workflow, which can be boolean, number, or string. When you call a reusable workflow, use the with keyword to pass named inputs and the secrets keyword for sensitive data. This setup allows for a clean and efficient way to manage your workflows across different repositories.
In production, be aware of some critical nuances. Environment secrets cannot be passed from the caller workflow, as the on.workflow_call does not support the environment keyword. If you choose to inherit secrets using secrets: inherit, you can reference them even if they aren't explicitly defined. Additionally, if you're dealing with nested reusable workflows, ensure that all workflows in the chain are accessible to the caller. Permissions can only be maintained or reduced, not elevated, throughout the chain. These details can make or break your workflow efficiency, so pay close attention to them.
Key takeaways
- →Define inputs and secrets in your reusable workflow using the `inputs` and `secrets` keywords.
- →Use the `with` keyword to pass named inputs and the `secrets` keyword for sensitive data.
- →Be cautious that environment secrets cannot be passed from the caller workflow.
- →Remember that nested reusable workflows require all workflows to be accessible to the caller.
- →Use `secrets: inherit` to reference secrets not explicitly defined in the calling workflow.
Why it matters
Reusable workflows can significantly reduce duplication in your CI/CD pipelines, leading to faster development cycles and fewer errors. This efficiency is crucial in maintaining a robust and scalable automation strategy.
Code examples
on:workflow_call:inputs:config-path:required:true:type:stringsecrets:personal_access_token:required:truejobs:call-workflow-passing-data:uses:octo-org/example-repo/.github/workflows/reusable-workflow.yml@mainwith:config-path:.github/labeler.ymlsecrets:personal_access_token:${{secrets.token}}jobs:workflowA-calls-workflowB:uses:octo-org/example-repo/.github/workflows/B.yml@mainsecrets:inherit# pass all secretsWhen NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsDeploy any app in seconds — no infrastructure config, no DevOps overhead. Instant deployments from GitHub, built-in databases, and automatic scaling.
Start deploying free →Speed Up Your CI/CD with GitHub Actions Caching
Want to shave minutes off your CI/CD pipeline? Caching dependencies in GitHub Actions can drastically reduce build times. Learn how cache hits and misses work to optimize your workflows.
Mastering Deployments with GitHub Actions: What You Need to Know
Deploying with GitHub Actions can streamline your CI/CD pipeline, but it requires a solid understanding of environments and concurrency. Learn how to configure your workflows effectively to avoid common pitfalls.
Mastering Self-Hosted Runners in GitHub Actions
Self-hosted runners can streamline your CI/CD processes by leveraging existing infrastructure. These runners can be physical, virtual, or even in containers, giving you flexibility in job execution. Discover how to effectively implement them in your workflows.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.