mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #1714] Deployment Environments support #841
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#841
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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!
@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.
@itpropro commented on GitHub (Feb 22, 2025):
This would really help debugging, any plans for this?
@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:
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.