Resuable (called) workflow environment variables, secrets and trigger event access

Reading the threads below did not solve the issue:

Called workflow seems not to have an access to secrets within the repository the called workflow is stored (even if they are organizational secrets). Although a called workflow accepts inputs and secrets, it does not serve a common use case where the called workflow encapsulates the implementation.

As an example, when a called workflow encapsulates the logic of publishing a package to organizational NPM registry, the called workflow needs an NPM token in order to authenticate with NPM (and maybe some other environment variables). The NPM token can be stored as a secrets (in the repository of the called workflow file) and each caller workflow does not need to know neither how the called workflow is publishing a package, nor maintaining its own NPM token.

Rather then passing NPM token from the caller workflow to the called workflow, how do you suggest handling such use case?

Plus, how can the called workflow access the event which triggered the caller workflow. E.g. (passing $GITHUB_EVENT_PATH from caller workflow to the called workflow is problematic since having env.GITHUB_EVENT_PATH in the with expression is not interpolated correctly).

Hi @foolioo. I’m the product manager for reusable workflows.

Secrets was one of the hardest design problems for this feature. There’s a fundamental tension between having them “just work,” and encouraging least privilege. Where we are now is closer to the later, but means its harder to use. It’s something I’m still thinking about.

In the meantime, here’s how it works today:

  • The called workflow only has access to the GitHub secrets that are explicitly passed to it. So if you have an organization secret you want it to use, you’ll need to make that organization secret available to the caller repository, and then pass it in the caller workflow file
  • We have an upcoming feature on our roadmap called Secure Cloud Deployments which will help in some cases. In particular, if the secret is a token to access or duplicated in a cloud platform (AWS, Azure, GCP, Vault), you can probably use this feature. It doesn’t require you to pass the tokens to the called workflow, and comes with a host of other benefits like tokens that are created and expire for each job run, ability to restrict the token to just the jobs that need it (within the cloud platform), and removing duplication of secrets across GitHub and your cloud platform.

You also asked about accessing the event which triggered the caller workflow. This should just work. for example, I have a reusable workflow with this step:

      - name: Dump GitHub context
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"

And when its called by another workflow, I see this in the logs:

This behavior is clear and thus the reason for me posting here, asking how can it be eased.
But it seems that for organization, there is no way to simplify around it.

Rather than having a single repository both reusable\called workflows and relevant organizational secrets are stored, which encapsulates the implementation and ease the pain of managing reusable workflows and organizational secrets; we are back to square one, where organizational secrets needs to be shared across many repositories and the burden of managing it becomes a hassle.

I hope that Github will come up with a better solution to achieve the logical way to enjoy encapsulation, dry paradigm and ease of managing all of this.

Thank you @jenschelkopf

@jenschelkopf: ability to reference environment defined in the same repo as reusable workflow is crucial for our organization - it will allow us to manage secrets in one place instead of distributing them in all repos and building infrastructure to keep them in sync.
From UX point of view it also retains same encapsulation rules as ordinary workflows.

1 Like