mirror of
https://github.com/nektos/act.git
synced 2026-04-26 09:25:54 +03:00
[GH-ISSUE #1926] Change of behavior to pass inputs to manually triggered workflows #925
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#925
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 @christinawongseequent on GitHub (Jul 25, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/1926
Act version
0.2.48
Feature description
Since GitHub Action has an update of inputs context for both workflow_dispatch and workflow_call. Would you consider adopting the up-to-date GitHub Actions Context in ACT too?
GitHub ref: https://github.blog/changelog/2022-06-10-github-actions-inputs-unified-across-manual-and-reusable-workflows/
Currently, we have to use if condition for all steps and jobs we run locally in ACT, which doesn't seems to serve the purpose of consistence (i.e. we cannot really test the real workflow with if condition only for ACT).
ACT ref: https://github.com/nektos/act#pass-inputs-to-manually-triggered-workflows
@GuessWhoSamFoo commented on GitHub (Jul 30, 2023):
@christinawongseequent Looking into the testcase https://github.com/nektos/act/blob/master/pkg/runner/testdata/workflow_dispatch/workflow_dispatch.yml, this is already supported unless I misunderstood the issue.
e.g. using a modified example from the readme
gets as expected without the event payload:
@bvanderlugt commented on GitHub (Oct 12, 2023):
I just want to chime in here @GuessWhoSamFoo and add that I think this bug/feature-request is specifically on the workflow_call event. I am working with one right now and I have to switch my workflow to use the workflow_dispatch event to get the inputs to show up (as in your example).