[GH-ISSUE #1714] Deployment Environments support #841

Open
opened 2026-03-01 21:46:50 +03:00 by kerem · 3 comments
Owner

Originally created by @giulianozor on GitHub (Apr 4, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/1714

Act version

0.2.44

Feature description

In GitHub action it is possible to specify an “environment” key to discriminate between divergent secrets set.
In my case I have two sets of credentials called “dev” and “prod”.

In the yml action file i then have a deploy job that uses a matrix to deploy to each environment (prod requires a manual review by an authorized use, but it is not the point here).
Because the environment value is ignored, act runs the two jobs un the matrix using the same test secrets.
That could be fine if the only difference in the environments are the credentials, but it could be annoying if there are different build params (like log levels, debug symbols and so on)

It would be great if it could be possible to map different env files to different environments. Or maybe load all .env files and use the extension as the environment name (.env.dev maps to dev, etc)

thanks!

Originally created by @giulianozor on GitHub (Apr 4, 2023). Original GitHub issue: https://github.com/nektos/act/issues/1714 ### Act version 0.2.44 ### Feature description In GitHub action it is possible to specify an “environment” key to discriminate between divergent secrets set. In my case I have two sets of credentials called “dev” and “prod”. In the yml action file i then have a deploy job that uses a matrix to deploy to each environment (prod requires a manual review by an authorized use, but it is not the point here). Because the environment value is ignored, act runs the two jobs un the matrix using the same test secrets. That could be fine if the only difference in the environments are the credentials, but it could be annoying if there are different build params (like log levels, debug symbols and so on) It would be great if it could be possible to map different env files to different environments. Or maybe load all .env files and use the extension as the environment name (.env.dev maps to dev, etc) thanks!
Author
Owner

@enricojonas commented on GitHub (Sep 23, 2024):

That would really help. It doesn't need to be too advanced. I think it would be enough to support environments and just have a parameter (e.g. review_required_environments=xxx) where you could specify which environments will stop the pipeline and wait for some kind of approval. If there is not interaction with the user possible it would also be enough to just stop at this point and treat it as not-approved.

Sometimes it's hard to test reusable workflows. Currently I need to disable the potentially destructive steps during my tests as act will just run regardless of approval.

<!-- gh-comment-id:2368311791 --> @enricojonas commented on GitHub (Sep 23, 2024): That would really help. It doesn't need to be too advanced. I think it would be enough to support environments and just have a parameter (e.g. review_required_environments=xxx) where you could specify which environments will stop the pipeline and wait for some kind of approval. If there is not interaction with the user possible it would also be enough to just stop at this point and treat it as not-approved. Sometimes it's hard to test reusable workflows. Currently I need to disable the potentially destructive steps during my tests as act will just run regardless of approval.
Author
Owner

@itpropro commented on GitHub (Feb 22, 2025):

This would really help debugging, any plans for this?

<!-- gh-comment-id:2676323763 --> @itpropro commented on GitHub (Feb 22, 2025): This would really help debugging, any plans for this?
Author
Owner

@jj-triff-kr commented on GitHub (Aug 22, 2025):

Unsupported solution for the "Wait for approval" need:
Put this as the first step on that one that you want to approve manually:

- name: Local approval gate (only when running with act)
  if: env.ACT == 'true'
  shell: bash
  run: |
    rm -f /tmp/approved
    echo "Waiting for local approval..."
    echo "In another terminal: find act container and 'docker exec' to touch /tmp/approved"
    cid=$(docker ps --format '{{.ID}}\t{{.Names}}' | awk '$2 ~ /^act-/ {print $1; exit}')
    echo "Example:"
    echo "docker exec -it \"$cid\" bash -lc 'touch /tmp/approved'"
    while [ ! -f /tmp/approved ]; do sleep 2; done


# Your sensitive steps
- name: Deploy to X (runs after approval)
  run: ./deploy.sh

If the step fails bc of line 4 (maybe bc that docker image does not have docker in it? 🤔 Is that even possible🤷??) comment out that line and use it as a reference.

Credits to gpt-5 that inspired this.

<!-- gh-comment-id:3215692540 --> @jj-triff-kr commented on GitHub (Aug 22, 2025): Unsupported solution for the "Wait for approval" need: Put this as the first step on that one that you want to approve manually: ```yml - name: Local approval gate (only when running with act) if: env.ACT == 'true' shell: bash run: | rm -f /tmp/approved echo "Waiting for local approval..." echo "In another terminal: find act container and 'docker exec' to touch /tmp/approved" cid=$(docker ps --format '{{.ID}}\t{{.Names}}' | awk '$2 ~ /^act-/ {print $1; exit}') echo "Example:" echo "docker exec -it \"$cid\" bash -lc 'touch /tmp/approved'" while [ ! -f /tmp/approved ]; do sleep 2; done # Your sensitive steps - name: Deploy to X (runs after approval) run: ./deploy.sh ``` If the step fails bc of line 4 (maybe bc that docker image does not have docker in it? 🤔 Is that even possible🤷??) comment out that line and use it as a reference. Credits to gpt-5 that inspired this.
Sign in to join this conversation.
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#841
No description provided.