starred/act

Fork 0

mirror of https://github.com/nektos/act.git synced 2026-04-26 09:25:54 +03:00

[GH-ISSUE #2663] Globally available environment variables #1207

New issue

Closed

opened 2026-03-01 21:49:41 +03:00 by kerem · 2 comments

kerem commented

2026-03-01 21:49:41 +03:00

Owner

Originally created by @Makeshift on GitHub (Feb 11, 2025).
Original GitHub issue: https://github.com/nektos/act/issues/2663

Act version

0.2.74

Feature description

Currently, act only makes variables (defined with --var) available to workflows that explicitly reference the vars context.

Given the command act --workflows build.yml --job build --var SOME_VAR=foo, the following step will not output foo:

- run: echo $SOME_VAR

But this one will:

- env:
    SOME_VAR: "${{ vars.SOME_VAR }}"
  run: echo $SOME_VAR

We have self-hosted GitHub Actions runners that run in Kubernetes and are automatically provided with AWS credentials from their environment, without needing to specify any credential-related actions or interacting with GitHub context in any way.

This is difficult to replicate locally with act, because vars like AWS_ACCESS_KEY_ID cannot be made available to the underlying AWS SDK running in the action within act unless you specifically set the env: key in the workflow. Problematically, that then means that if we commit the workflow with the env: key, then when the self-hosted runner picks up the workflow, the environment variables set in the self-hosted runner environment are overwritten.

This means that for local testing, we need to either heavily modify our workflows, provide a pre-generated .env file to act (which does get injected globally, I think) or it's possible to use .env files, since they're injected globally, but I wanted to be able to use the new act vscode extension and was trying to avoid having to manually run a bunch of commands before invoking it.

You can use secrets, this monstrosity in .actrc sort-of works:

--secret GHA_PASSTHROUGH=true
--secret AWS_REGION=eu-west-1
--secret AWS_DEFAULT_REGION=eu-west-1
--secret LOGIN_TO_SHARED_ECR=$(aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin x.dkr.ecr.eu-west-1.amazonaws.com)
--secret LOGIN_TO_EMAIL_ECR=$(aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin y.dkr.ecr.eu-west-1.amazonaws.com)
--secret AWS_ACCESS_KEY_ID=$( (yawsso -p email-service -e | yawsso decrypt >/tmp/env) && . /tmp/env && echo $AWS_ACCESS_KEY_ID)
--secret AWS_SECRET_ACCESS_KEY=$( (until [ -f /tmp/env ]; do sleep 1; done) && . /tmp/env && echo $AWS_SECRET_ACCESS_KEY)
--secret AWS_SESSION_TOKEN=$( (until [ -f /tmp/env ]; do sleep 1; done) && . /tmp/env && echo $AWS_SESSION_TOKEN)

but unfortunately secrets are not exposed to child actions as env vars, so none of the child actions that rely on these globally-available variables work.

My terrible workaround to this: as part of another action we happen to have that runs at the start of each workflow to enable extra debugging info if debug mode is enabled, I added an additional step that re-exports the passed-in secrets to put them into the job env scope.

# step in job in workflow.yml
- uses: ebx/actions/action-bash-debug@dev
  with:
    secrets: ${{ toJSON(secrets) }}

# step in ebx/actions/action-bash-debug
- name: Inject local run vars
  # If we're running in a local dev env using act, we need to pass through some vars to simulate the EKS environment
  # These secrets are set in .actrc in the root of the repo and/or your home directory
  # Secrets are usually available to workflow jobs via the environment, but they are not available to child actions, so this step
  #  re-exports them so they become 'job'-scoped.
  if: env.ACT == 'true' && inputs.secrets
  shell: bash
  run: echo '${{ inputs.secrets }}' | jq -r 'to_entries | map("\(.key)=\(.value)") | .[]' >> $GITHUB_ENV

This is uh, horrid, but works! Alternative suggestions very welcome.

Originally created by @Makeshift on GitHub (Feb 11, 2025). Original GitHub issue: https://github.com/nektos/act/issues/2663 ### Act version 0.2.74 ### Feature description Currently, act only makes variables (defined with `--var`) available to workflows that explicitly reference the `vars` context. Given the command `act --workflows build.yml --job build --var SOME_VAR=foo`, the following step will not output `foo`: ```yaml - run: echo $SOME_VAR ``` But this one will: ```yaml - env: SOME_VAR: "${{ vars.SOME_VAR }}" run: echo $SOME_VAR ``` We have self-hosted GitHub Actions runners that run in Kubernetes and are automatically provided with AWS credentials from their environment, without needing to specify any credential-related actions or interacting with GitHub context in any way. This is difficult to replicate locally with act, because vars like `AWS_ACCESS_KEY_ID` cannot be made available to the underlying AWS SDK running in the action within act unless you specifically set the `env:` key in the workflow. Problematically, that then means that if we commit the workflow with the `env:` key, then when the self-hosted runner picks up the workflow, the environment variables set in the self-hosted runner environment are overwritten. This means that for local testing, we need to either heavily modify our workflows, provide a pre-generated `.env` file to act (which does get injected globally, I think) or it's possible to use `.env` files, since they're injected globally, but I wanted to be able to use the new act vscode extension and was trying to avoid having to manually run a bunch of commands before invoking it. You _can_ use secrets, this monstrosity in `.actrc` sort-of works: ``` --secret GHA_PASSTHROUGH=true --secret AWS_REGION=eu-west-1 --secret AWS_DEFAULT_REGION=eu-west-1 --secret LOGIN_TO_SHARED_ECR=$(aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin x.dkr.ecr.eu-west-1.amazonaws.com) --secret LOGIN_TO_EMAIL_ECR=$(aws ecr get-login-password --region eu-west-1 | docker login --username AWS --password-stdin y.dkr.ecr.eu-west-1.amazonaws.com) --secret AWS_ACCESS_KEY_ID=$( (yawsso -p email-service -e | yawsso decrypt >/tmp/env) && . /tmp/env && echo $AWS_ACCESS_KEY_ID) --secret AWS_SECRET_ACCESS_KEY=$( (until [ -f /tmp/env ]; do sleep 1; done) && . /tmp/env && echo $AWS_SECRET_ACCESS_KEY) --secret AWS_SESSION_TOKEN=$( (until [ -f /tmp/env ]; do sleep 1; done) && . /tmp/env && echo $AWS_SESSION_TOKEN) ``` but unfortunately secrets are not exposed to child actions as env vars, so none of the child actions that rely on these globally-available variables work. My terrible workaround to this: as part of another action we happen to have that runs at the start of each workflow to enable extra debugging info if debug mode is enabled, I added an additional step that re-exports the passed-in secrets to put them into the job env scope. ```yaml # step in job in workflow.yml - uses: ebx/actions/action-bash-debug@dev with: secrets: ${{ toJSON(secrets) }} # step in ebx/actions/action-bash-debug - name: Inject local run vars # If we're running in a local dev env using act, we need to pass through some vars to simulate the EKS environment # These secrets are set in .actrc in the root of the repo and/or your home directory # Secrets are usually available to workflow jobs via the environment, but they are not available to child actions, so this step # re-exports them so they become 'job'-scoped. if: env.ACT == 'true' && inputs.secrets shell: bash run: echo '${{ inputs.secrets }}' | jq -r 'to_entries | map("\(.key)=\(.value)") | .[]' >> $GITHUB_ENV ``` This is uh, horrid, but works! Alternative suggestions very welcome.

kerem

2026-03-01 21:49:41 +03:00

closed this issue
added the
kind/feature-request
label

kerem commented

2026-03-01 21:49:42 +03:00

Author

Owner

@ChristopherHX commented on GitHub (Feb 11, 2025):

Is there a problem with --env ? (--var is a much newer concept of Actions)

@ChristopherHX commented on GitHub (Feb 11, 2025): Is there a problem with `--env` ? (`--var` is a much newer concept of Actions)

kerem commented

2026-03-01 21:49:42 +03:00

Author

Owner

@Makeshift commented on GitHub (Feb 11, 2025):

Is there a problem with --env ? (--var is a much newer concept of Actions)

Oh wow, I'm an idiot. Somehow I completely glossed --env in the help 🤦. Thanks.

@Makeshift commented on GitHub (Feb 11, 2025): > Is there a problem with `--env` ? (`--var` is a much newer concept of Actions) Oh wow, I'm an idiot. Somehow I completely glossed `--env` in the help 🤦. Thanks.

kerem referenced this issue

2026-03-01 21:52:54 +03:00

[PR #1207] [CLOSED] Added support for chunked uploads. #1839

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/act#1207

No description provided.

Rows
Columns