starred/act

Fork 0

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

[GH-ISSUE #2709] act detects wrong event for workflow #1226

New issue

Open

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

kerem commented

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

Owner

Originally created by @chibidev on GitHub (Mar 24, 2025).
Original GitHub issue: https://github.com/nektos/act/issues/2709

Bug report info

act version:            0.2.74
GOOS:                   darwin
GOARCH:                 arm64
NumCPU:                 16
Docker host:            DOCKER_HOST environment variable is not set
Sockets found:
	/var/run/docker.sock
Config files:           
	/Users/chibidev/Library/Application Support/act/actrc:
		-P ubuntu-latest=catthehacker/ubuntu:act-latest
		-P ubuntu-22.04=catthehacker/ubuntu:act-22.04
		-P ubuntu-20.04=catthehacker/ubuntu:act-20.04
		-P ubuntu-18.04=catthehacker/ubuntu:act-18.04
Build info:
	Go version:            go1.23.6
	Module path:           github.com/nektos/act
	Main version:          (devel)
	Main path:             github.com/nektos/act
	Main checksum:         
	Build settings:
		-buildmode:           exe
		-compiler:            gc
		-trimpath:            true
		CGO_ENABLED:          1
		GOARCH:               arm64
		GOOS:                 darwin
		GOARM64:              v8.0
Docker Engine:
	Engine version:        27.5.1
	Engine runtime:        runc
	Cgroup version:        2
	Cgroup driver:         cgroupfs
	Storage driver:        overlay2
	Registry URI:          https://index.docker.io/v1/
	OS:                    OrbStack
	OS type:               linux
	OS version:            
	OS arch:               aarch64
	OS kernel:             6.12.15-orbstack-00304-gd0ddcf70447d
	OS CPU:                16
	OS memory:             16031 MB
	Security options:
		name=seccomp,profile=builtin
		name=cgroupns

Command used with act

act -v -j a --detect-event --input var2=test

Describe issue

When not specifying the triggering event and relying on act to detect, even though the job is specified via -j, act may end up choosing the wrong event for the workflow (e.g. when one workflow uses workflow_dispatch and the other uses workflow_call). Unfortunately, having the wrong event also prevents correctly substituting input variables.

As far as I can tell this stems from the planner not taking the specified workflow into consideration when collecting relevant event names.

I'd be happy to send a PR, but first I wanted to ask whether this is intentional or not.

Link to GitHub repository

No response

Workflow content

name: A
on:
  workflow_dispatch:
    inputs:
        var2:
          type: string

jobs:
  a:
    runs-on: ubuntu-latest
    steps:
    - run: "[[ ! -z \"${{ inputs.var2 }}\" ]]"

Relevant log output

time="2025-03-24T19:11:31+01:00" level=debug msg="Using first detected workflow event for filtering: workflow_call"
...
time="2025-03-24T19:11:31+01:00" level=debug msg="Using first detected workflow event: workflow_call"
time="2025-03-24T19:11:31+01:00" level=debug msg="Planning job: a"
...
[A/a]   🐳  docker exec cmd=[bash -e /var/run/act/workflow/0] user= workdir=
[A/a] [DEBUG] Exec command '[bash -e /var/run/act/workflow/0]'
[A/a] [DEBUG] Working directory '/private/var/folders/5c/jzcd2zp96hs_bwp2z07xv78w0000gp/T/tmp.wcpyhGNxVU'
[A/a]   ❌  Failure - Main [[ ! -z "" ]]
[A/a] exitcode '1': failure
[A/a] [DEBUG] expression '[[ ! -z "${{ inputs.var2 }}" ]]' rewritten to 'format('[[ ! -z "{0}" ]]', inputs.var2)'
[A/a] [DEBUG] evaluating expression 'format('[[ ! -z "{0}" ]]', inputs.var2)'
[A/a] [DEBUG] expression 'format('[[ ! -z "{0}" ]]', inputs.var2)' evaluated to '%!t(string=[[ ! -z "" ]])'
...
[A/a] 🏁  Job failed
Error: Job 'a' failed

Additional information

Second workflow file:

name: B
on:
  workflow_call:
    inputs:
      var1:
        type: string

jobs:
  b:
    runs-on: ubuntu-latest
    steps:
    - run: echo ${{ inputs.var1 }}

Originally created by @chibidev on GitHub (Mar 24, 2025). Original GitHub issue: https://github.com/nektos/act/issues/2709 ### Bug report info ```plain text act version: 0.2.74 GOOS: darwin GOARCH: arm64 NumCPU: 16 Docker host: DOCKER_HOST environment variable is not set Sockets found: /var/run/docker.sock Config files: /Users/chibidev/Library/Application Support/act/actrc: -P ubuntu-latest=catthehacker/ubuntu:act-latest -P ubuntu-22.04=catthehacker/ubuntu:act-22.04 -P ubuntu-20.04=catthehacker/ubuntu:act-20.04 -P ubuntu-18.04=catthehacker/ubuntu:act-18.04 Build info: Go version: go1.23.6 Module path: github.com/nektos/act Main version: (devel) Main path: github.com/nektos/act Main checksum: Build settings: -buildmode: exe -compiler: gc -trimpath: true CGO_ENABLED: 1 GOARCH: arm64 GOOS: darwin GOARM64: v8.0 Docker Engine: Engine version: 27.5.1 Engine runtime: runc Cgroup version: 2 Cgroup driver: cgroupfs Storage driver: overlay2 Registry URI: https://index.docker.io/v1/ OS: OrbStack OS type: linux OS version: OS arch: aarch64 OS kernel: 6.12.15-orbstack-00304-gd0ddcf70447d OS CPU: 16 OS memory: 16031 MB Security options: name=seccomp,profile=builtin name=cgroupns ``` ### Command used with act ```sh act -v -j a --detect-event --input var2=test ``` ### Describe issue When not specifying the triggering event and relying on `act` to detect, even though the job is specified via `-j`, `act` may end up choosing the wrong event for the workflow (e.g. when one workflow uses `workflow_dispatch` and the other uses `workflow_call`). Unfortunately, having the wrong event also prevents correctly substituting input variables. As far as I can tell this stems from the [planner not taking the specified workflow into consideration when collecting relevant event names](https://github.com/nektos/act/blob/189f16fb969f91bc2a82471fe47b65f60318b212/pkg/model/planner.go#L274). I'd be happy to send a PR, but first I wanted to ask whether this is intentional or not. ### Link to GitHub repository _No response_ ### Workflow content ```yml name: A on: workflow_dispatch: inputs: var2: type: string jobs: a: runs-on: ubuntu-latest steps: - run: "[[ ! -z \"${{ inputs.var2 }}\" ]]" ``` ### Relevant log output ```sh time="2025-03-24T19:11:31+01:00" level=debug msg="Using first detected workflow event for filtering: workflow_call" ... time="2025-03-24T19:11:31+01:00" level=debug msg="Using first detected workflow event: workflow_call" time="2025-03-24T19:11:31+01:00" level=debug msg="Planning job: a" ... [A/a] 🐳 docker exec cmd=[bash -e /var/run/act/workflow/0] user= workdir= [A/a] [DEBUG] Exec command '[bash -e /var/run/act/workflow/0]' [A/a] [DEBUG] Working directory '/private/var/folders/5c/jzcd2zp96hs_bwp2z07xv78w0000gp/T/tmp.wcpyhGNxVU' [A/a] ❌ Failure - Main [[ ! -z "" ]] [A/a] exitcode '1': failure [A/a] [DEBUG] expression '[[ ! -z "${{ inputs.var2 }}" ]]' rewritten to 'format('[[ ! -z "{0}" ]]', inputs.var2)' [A/a] [DEBUG] evaluating expression 'format('[[ ! -z "{0}" ]]', inputs.var2)' [A/a] [DEBUG] expression 'format('[[ ! -z "{0}" ]]', inputs.var2)' evaluated to '%!t(string=[[ ! -z "" ]])' ... [A/a] 🏁 Job failed Error: Job 'a' failed ``` ### Additional information Second workflow file: ``` name: B on: workflow_call: inputs: var1: type: string jobs: b: runs-on: ubuntu-latest steps: - run: echo ${{ inputs.var1 }} ```

kerem added the

kind/bug

label

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

kerem commented

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

Author

Owner

@Andne commented on GitHub (Apr 4, 2025):

I ran into this myself recently, it was working on one computer but not another. Finally found there is an interaction with the -W flag. One computer happened to have some cruft from earlier exploration on it so I had a conflicting job name and had to specify -W in order for that job name to resolve. When going to the other computer I left -W off and couldn't get my input arguments to make sense. Once I added the -W flag back in, the inputs were picked up correctly.

So, sounds like a bug probably, but as a workaround -W seems to keep it happier?

@Andne commented on GitHub (Apr 4, 2025): I ran into this myself recently, it was working on one computer but not another. Finally found there is an interaction with the -W flag. One computer happened to have some cruft from earlier exploration on it so I had a conflicting job name and had to specify -W <filepath> in order for that job name to resolve. When going to the other computer I left -W off and couldn't get my input arguments to make sense. Once I added the -W flag back in, the inputs were picked up correctly. So, sounds like a bug probably, but as a workaround -W <filepath> seems to keep it happier?

kerem commented

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

Author

Owner

@chibidev commented on GitHub (Apr 5, 2025):

Obviously, if the set of workflows is constrained properly, this issue might not occur. So yes, specifying a workflow with -W is a possible workaround, as well as specifying the event name, re-arranging workflows into other directories, etc.

@chibidev commented on GitHub (Apr 5, 2025): Obviously, if the set of workflows is constrained properly, this issue might not occur. So yes, specifying a workflow with `-W` is a possible workaround, as well as specifying the event name, re-arranging workflows into other directories, etc.

kerem referenced this issue

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

[PR #1226] [MERGED] fix: checkout container path should always use / #1850

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#1226

No description provided.

Rows
Columns