Vars context not accessible in composite action

[SoaAlex]

Select Topic Area

Question

Body

Hello,

I have a job calling a composite action made by myself

  build-docker:
    runs-on: [self-hosted, Linux, standard]
    environment:
      name: staging
    steps:
      - name: 🏗️📤 Build Docker Image
        uses: XX/XX/workflows/.github/actions/build/docker@main

The composite action cannot access the vars context that should be provided by setting an environment in the job.
Is this expected ?
The following action will make the workflow fail:

  - name: 🐋⬆️ Push Docker images
    if: ${{ vars.push == 'true' }}
    shell: bash
    run: |
      docker push XXXXX

[jge162]

If you want to use a variable in a composite action, you need to pass it as an input parameter.

[o-alexandrov]

vars context is not meant for secret values.
It is a UX bug, isn't it?

Please expose vars context for shareable actions, including composite, as it would help both: actions authors and users.
Related GitHub Issue actions/runner#2551

[htekdev]

I had to do the following:

...
inputs:
  vars-as-json:
    description: 'Vars as JSON. Recommended to be ${{ toJSON(vars) }}'
    required: true
...

uses: action@v1
with:
   vars-as-json: ${{ toJson(vars) }}
   ...

It sucks since now I have this required parameter that is expected to be the same no matter what. Makes no sense.

[Crisfole]

This is particularly obnoxious since secrets are accessible. Also because shared workflows do inherit vars and secrets. Forcing the use of input instead of allowing the use of vars makes this less powerful without any clear explanation of why the decision was made.

[leog]

Bumped into this too, I would really appreciate some detailed explanation of the rationale behind this strange current behavior or perhaps a plan to remediate it by allowing vars and secrets access from composite actions 🙏

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬

[Malix-Labs]

Nope, this is not outdated

[AndresPinerosZen]

The reason behind this is quite straightforward: security. People generally avoid sharing their workflows publicly. Instead, what is commonly shared are GitHub Actions. If third-party GitHub Actions had access to repository variables, it could pose significant security risks. Companies could inadvertently expose sensitive data through these variables—data that might not be sensitive within the organization but is not intended for external exposure.

GitHub Actions are versioned (e.g., v4, v7), which means they are susceptible to supply chain attacks due to the lack of lock files for dependencies. Therefore, it's crucial to prevent third-party GitHub Actions from accessing repository variables by default to mitigate these risks.

[NicoForce]

I believe you missed the point with your comment.

For starters, most organizations looking to automate their CI/CD host their composite actions in a private repository, and there is no need to share externally. This is already possible with the current Github offering.

Also, I don't think there's an specific need for a composite action to have access to the variables in the repository it is being hosted. Instead, giving access to the variables of the remote repository that's calling them is ideal, the only catch is composite actions will need workarounds or error messages for when its missing certain variables, and documentation must explain which variables are needed.

[CasperWSchmidt]

@NicoForce, I believe you misunderstood what @AndresPinerosZen wrote. The security thing is not about the composite action having access to the variables in the repository it is being hosted in, but in fact the opposite. Let me give you an example:
A random GitHub user A exposes a composite action that's supposed to do something smart. Org B needs said feature and decides to use A's action instead of rolling their own. The action runs smoothly for some time, but without anyone noticing, A decides to alter the script so that it scrapes the values and sends them to a 3rd party. Now B's variable values are scraped without them knowing it. Although variables are not supposed to contain secrets, they may still contain URLs and other semi-sensitive data that you do not want everyone to know about.

That said, I have the exact same issue now. I've made a composite action that will replace placeholders with actual values in config files. This is pretty damn hard/impossible without a dynamic way to access all variables as my composite action have no idea what placeholders to replace when I build it.

I guess my best option is to require vars as JSON using ${{ toJSON(vars) }}

[NicoForce]

@CasperWSchmidt The example is valid, and you could say it's true for all opensource and FOSS tools we incorporate into our respective systems.

One has to validate and trust what we are using when it comes to third party tools/workflows and anything else, otherwise, we would have to build our own (which is also a possibility and happens all the time, thus why there's so many in-house tools).

The main use for composite actions is not third parties though, they are mainly used within the same organization, or within the same corporation, to the very least. For sharing actions with third parties, there's already a different system for building actions, see this one for an easy example: https://github.com/actions-ecosystem/action-slack-notifier.