act detects wrong event for workflow

[chibidev]

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 }}

[Andne]

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?

[chibidev]

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.