[GH-ISSUE #2047] Unable to use expressions for default values in workflow_call inputs

kerem commented

2026-03-01 21:47:55 +03:00

Owner

Originally created by @mconigliaro on GitHub (Oct 12, 2023).
Original GitHub issue: https://github.com/nektos/act/issues/2047

Bug report info

act version:            0.2.52
GOOS:                   darwin
GOARCH:                 amd64
NumCPU:                 12
Docker host:            DOCKER_HOST environment variable is not set
Sockets found:
	$HOME/.docker/run/docker.sock
Config files:
	/Users/mike-conigliaro/.actrc:
		-P ubuntu-latest=catthehacker/ubuntu:act-latest
		-P ubuntu-20.04=catthehacker/ubuntu:act-20.04
		-P ubuntu-18.04=catthehacker/ubuntu:act-18.04
		-P ubuntu-16.04=catthehacker/ubuntu:act-16.04
		-P self-hosted=catthehacker/ubuntu:act-latest
		-P cypress=cypress/included:cypress-12.6.0-node-16.18.1-chrome-110.0.5481.96-1-ff-109.0-edge-110.0.1587.41-1

		--env-file /Users/mike-conigliaro/.actenv
		--secret-file /Users/mike-conigliaro/.actsecret
		--input-file /Users/mike-conigliaro/.actinput
Build info:
	Go version:            go1.21.1
	Module path:           command-line-arguments
	Main version:
	Main path:
	Main checksum:
	Build settings:
		-buildmode:           exe
		-compiler:            gc
		-ldflags:             -X main.version=0.2.52
		DefaultGODEBUG:       panicnil=1
		CGO_ENABLED:          1
		CGO_CFLAGS:
		CGO_CPPFLAGS:
		CGO_CXXFLAGS:
		CGO_LDFLAGS:
		GOARCH:               amd64
		GOOS:                 darwin
		GOAMD64:              v1

Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

Command used with act

act -W .github/workflows/test.yml

Describe issue

Expressions are not evaluated in on.workflow_call.inputs.*.default.

Link to GitHub repository

No response

Workflow content

name: test

on:
  workflow_call:
    inputs:
      repository:
        type: string
        default: ${{ github.repository }}

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - run: echo ${{ inputs.repository }}

Relevant log output

[test/test] 🚀  Start image=catthehacker/ubuntu:act-latest
[test/test]   🐳  docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true
[test/test]   🐳  docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
[test/test]   🐳  docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[]
[test/test] ⭐ Run Main echo ${{ github.repository }}
[test/test]   🐳  docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/0] user= workdir=
| /var/run/act/workflow/0: line 2: ${{ github.repository }}: bad substitution
[test/test]   ❌  Failure - Main echo ${{ github.repository }}
[test/test] exitcode '1': failure
[test/test] 🏁  Job failed
Error: Job 'test' failed

Additional information

No response

Originally created by @mconigliaro on GitHub (Oct 12, 2023). Original GitHub issue: https://github.com/nektos/act/issues/2047 ### Bug report info ```plain text act version: 0.2.52 GOOS: darwin GOARCH: amd64 NumCPU: 12 Docker host: DOCKER_HOST environment variable is not set Sockets found: $HOME/.docker/run/docker.sock Config files: /Users/mike-conigliaro/.actrc: -P ubuntu-latest=catthehacker/ubuntu:act-latest -P ubuntu-20.04=catthehacker/ubuntu:act-20.04 -P ubuntu-18.04=catthehacker/ubuntu:act-18.04 -P ubuntu-16.04=catthehacker/ubuntu:act-16.04 -P self-hosted=catthehacker/ubuntu:act-latest -P cypress=cypress/included:cypress-12.6.0-node-16.18.1-chrome-110.0.5481.96-1-ff-109.0-edge-110.0.1587.41-1 --env-file /Users/mike-conigliaro/.actenv --secret-file /Users/mike-conigliaro/.actsecret --input-file /Users/mike-conigliaro/.actinput Build info: Go version: go1.21.1 Module path: command-line-arguments Main version: Main path: Main checksum: Build settings: -buildmode: exe -compiler: gc -ldflags: -X main.version=0.2.52 DefaultGODEBUG: panicnil=1 CGO_ENABLED: 1 CGO_CFLAGS: CGO_CPPFLAGS: CGO_CXXFLAGS: CGO_LDFLAGS: GOARCH: amd64 GOOS: darwin GOAMD64: v1 Error: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ``` ### Command used with act ```sh act -W .github/workflows/test.yml ``` ### Describe issue Expressions are not evaluated in `on.workflow_call.inputs.*.default`. ### Link to GitHub repository _No response_ ### Workflow content ```yml name: test on: workflow_call: inputs: repository: type: string default: ${{ github.repository }} jobs: test: runs-on: ubuntu-latest steps: - run: echo ${{ inputs.repository }} ``` ### Relevant log output ```sh [test/test] 🚀 Start image=catthehacker/ubuntu:act-latest [test/test] 🐳 docker pull image=catthehacker/ubuntu:act-latest platform= username= forcePull=true [test/test] 🐳 docker create image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] [test/test] 🐳 docker run image=catthehacker/ubuntu:act-latest platform= entrypoint=["tail" "-f" "/dev/null"] cmd=[] [test/test] ⭐ Run Main echo ${{ github.repository }} [test/test] 🐳 docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/0] user= workdir= | /var/run/act/workflow/0: line 2: ${{ github.repository }}: bad substitution [test/test] ❌ Failure - Main echo ${{ github.repository }} [test/test] exitcode '1': failure [test/test] 🏁 Job failed Error: Job 'test' failed ``` ### Additional information _No response_

kerem added the

kind/bug

review/not-planned

labels

2026-03-01 21:47:55 +03:00

kerem commented

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

Author

Owner

@TWiStErRob commented on GitHub (Nov 27, 2023):

Note: as far as I understood, this only affects direct workflow_calls from act. If the uses: ./.github/workflows/test.yml is in another workflow file, and act runs that one, it might "just work".

@TWiStErRob commented on GitHub (Nov 27, 2023): Note: as far as I understood, this only affects direct `workflow_call`s from `act`. If the `uses: ./.github/workflows/test.yml` is in another workflow file, and `act` runs that one, it might "just work".

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (May 26, 2024):

Issue is stale and will be closed in 14 days unless there is new activity

@github-actions[bot] commented on GitHub (May 26, 2024): Issue is stale and will be closed in 14 days unless there is new activity

kerem commented

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

Author

Owner

@TWiStErRob commented on GitHub (May 26, 2024):

It's never stale, it's a bug that needs to be fixed.

@TWiStErRob commented on GitHub (May 26, 2024): It's never stale, it's a bug that needs to be fixed.

kerem commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Mar 26, 2025):

Issue is stale and will be closed in 14 days unless there is new activity

@github-actions[bot] commented on GitHub (Mar 26, 2025): Issue is stale and will be closed in 14 days unless there is new activity

kerem commented

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

Author

Owner

@TWiStErRob commented on GitHub (Mar 26, 2025):

@ChristopherHX isn't this a standard feature of GHA, or am I missing something? Would you mind elaborating why it's in the not-planned bucket?

@TWiStErRob commented on GitHub (Mar 26, 2025): @ChristopherHX isn't this a standard feature of GHA, or am I missing something? Would you mind elaborating why it's in the not-planned bucket?

kerem commented

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

Author

Owner

@ChristopherHX commented on GitHub (Mar 26, 2025):

I assign my own projects more attention, including a "hard-fork" of act (different package name, includes PRs from me that has been dropped due to missing reviews) and a "replicated" act commandline interface (in c# targets actions/runner).

I had struggle with my planned part last Winter as well, we don't have good communication about the roadmap of act.

Would you mind elaborating why it's in the not-planned bucket?

I'm not actively working on workflow_call in act
- github-act-runner does not use this feature at all
  - this part is done by the GitHub Actions Service and is indentical to a workflow_dispatch job
- even if someone would sponsor this project this does not reach me at all
Calling act using event workflow_call is broken by design
- github.event would be set to workflow_call, that is incorrect
- GitHub does not allow to trigger a reusable workflow without writing a workflow using it
- This "feature" adds workarounds everywhere
  - If the defaults work on one place, everything has to be duplicated or refactored to share the logic
- It's a broken clone of workflow_dispatch trigger
- What about integer types?
  - Can you even pass them?
The review part of the label means, I never tried to reproduce this locally. (confirmed would come after the review part)
The not-planned part means this is not something I would work on soon, if someone opens a PR then I would review the change.

@ChristopherHX commented on GitHub (Mar 26, 2025): I assign my own projects more attention, including a "hard-fork" of act (different package name, includes PRs from me that has been dropped due to missing reviews) and a "replicated" act commandline interface (in c# targets actions/runner). I had struggle with my planned part last Winter as well, we don't have good communication about the roadmap of act. > Would you mind elaborating why it's in the not-planned bucket? - I'm not actively working on workflow_call in act - github-act-runner does not use this feature at all - this part is done by the GitHub Actions Service and is indentical to a workflow_dispatch job - even if someone would sponsor this project this does not reach me at all - Calling act using event workflow_call is broken by design - github.event would be set to workflow_call, that is incorrect - GitHub does not allow to trigger a reusable workflow without writing a workflow using it - This "feature" adds workarounds everywhere - If the defaults work on one place, everything has to be duplicated or refactored to share the logic - It's a broken clone of workflow_dispatch trigger - What about integer types? - Can you even pass them? - The `review` part of the label means, I never tried to reproduce this locally. (`confirmed` would come after the `review` part) - The `not-planned` part means this is not something **`I`** would work on soon, if someone opens a PR then I would review the change.

kerem commented

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

Author

Owner

@mcascone commented on GitHub (Apr 24, 2025):

so... workflow_call just doesn't work if you need inputs, and there are no plans to fix it?

@mcascone commented on GitHub (Apr 24, 2025): so... `workflow_call` just doesn't work if you need inputs, and there are no plans to fix it?

kerem commented

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

Author

Owner

@ChristopherHX commented on GitHub (Apr 24, 2025):

@mcascone No, you are supposed to use such a yaml to bootstrap your reusable workflow

on: push
jobs:
  _:
    uses: ./.github/workflows/<reusable>.yml

Now act push.

This should work correctly

IMHO this is not a big deal to do.

@ChristopherHX commented on GitHub (Apr 24, 2025): @mcascone No, you are supposed to use such a yaml to bootstrap your reusable workflow ```yaml on: push jobs: _: uses: ./.github/workflows/<reusable>.yml ``` Now `act push`. This should work correctly IMHO this is not a big deal to do.

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@TWiStErRob commented on GitHub (Apr 24, 2025):

IMHO this is not a big deal to do.

Yes and no, for example, we have many workflow_calls with 10+ inputs and use act to integration test them. So to parameterize those from tests one either has to create many many of these bootstraps (each test) or duplicate all the inputs in the test fixture yml. That said, having an explicit and correct trigger / event context (push in the above example) is a good thing!

@TWiStErRob commented on GitHub (Apr 24, 2025): > IMHO this is not a big deal to do. Yes and no, for example, we have many `workflow_call`s with 10+ inputs and use `act` to integration test them. So to parameterize those from tests one either has to create many many of these bootstraps (each test) or duplicate all the inputs in the test fixture yml. That said, having an explicit and correct trigger / event context (`push` in the above example) is a good thing!

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@mcascone commented on GitHub (Apr 25, 2025):

@mcascone No, you are supposed to use such a yaml to bootstrap your reusable workflow

on: push
jobs:
_:
uses: ./.github/workflows/.yml
Now act push.

This should work correctly

IMHO this is not a big deal to do.

ok, so if we use a push trigger it will pass with: inputs from the caller to the called workflow? Because right now, with workflow_call, I'm seeing it not do that at all. Which really hampers its usability.

Is the _: job name specifically required? What does it do?

Is this documented anywhere?

@TWiStErRob how are you using act to integration test your reusable workflows with this functionality gap in play?

@mcascone commented on GitHub (Apr 25, 2025): > [@mcascone](https://github.com/mcascone) No, you are supposed to use such a yaml to bootstrap your reusable workflow > > on: push > jobs: > _: > uses: ./.github/workflows/<reusable>.yml > Now `act push`. > > This should work correctly > > IMHO this is not a big deal to do. ok, so if we use a `push` trigger it will pass `with:` inputs from the caller to the called workflow? Because right now, with `workflow_call`, I'm seeing it not do that at all. Which really hampers its usability. Is the `_:` job name specifically required? What does it do? Is this documented anywhere? @TWiStErRob how are you using `act` to integration test your reusable workflows with this functionality gap in play?

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@TWiStErRob commented on GitHub (Apr 25, 2025):

it will pass with: inputs from the caller to the called workflow

https://github.com/nektos/act/issues/2047#issuecomment-1827671287
So I think that's the case, but not 100% sure.

Is the _: job name specifically required? What does it do?

A job name is required there, I like the idea that _ is used, as the name doesn't matter, I usually used job: in these cases.

how are you using act to integration test your reusable workflows with this functionality gap in play?

Don't test defaults: 1. Try to avoid expressions, 2. pass it in explicitly from test, or 3. manually handle expressions:

// Instead of `default: ${{ github.workspace }}` have `default: ''` + below logic in a github-script step:
// Workaround for https://github.com/nektos/act/issues/2047.
    core.setOutput(
      "working-directory",
      process.env.INPUT_WORKING_DIRECTORY === ''
        ? process.env.GITHUB_WORKSPACE
        : process.env.INPUT_WORKING_DIRECTORY
    );

@TWiStErRob commented on GitHub (Apr 25, 2025): > it will pass with: inputs from the caller to the called workflow https://github.com/nektos/act/issues/2047#issuecomment-1827671287 So I think that's the case, but not 100% sure. > Is the _: job name specifically required? What does it do? A job name is required there, I like the idea that _ is used, as the name doesn't matter, I usually used `job:` in these cases. > how are you using act to integration test your reusable workflows with this functionality gap in play? Don't test defaults: 1. Try to avoid expressions, 2. pass it in explicitly from test, or 3. manually handle expressions: ```js // Instead of `default: ${{ github.workspace }}` have `default: ''` + below logic in a github-script step: // Workaround for https://github.com/nektos/act/issues/2047. core.setOutput( "working-directory", process.env.INPUT_WORKING_DIRECTORY === '' ? process.env.GITHUB_WORKSPACE : process.env.INPUT_WORKING_DIRECTORY ); ```

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@mcascone commented on GitHub (Apr 25, 2025):

I'm not sure I completely understand your mechanism, but that's ok. I'm focusing on getting reusable workflows to work with act/act-js.

Perhaps the issue is that I'm starting off the run with a workflow that is itself a reusable workflow? Meaning, an application's repo contains a workflow triggered by push, pull_request, etc. That workflow calls the "master" pipeline, which is what I'm trying to unit/integration test with act-js.

Is it possible that if I kick off the unit-test run with a workflow that uses push, the reusable workflows called by it will get their inputs properly passed on?

@mcascone commented on GitHub (Apr 25, 2025): I'm not sure I completely understand your mechanism, but that's ok. I'm focusing on getting reusable workflows to work with `act`/`act-js`. Perhaps the issue is that I'm starting off the run with a workflow that is itself a reusable workflow? Meaning, an application's repo contains a workflow triggered by `push`, `pull_request`, etc. That workflow calls the "master" pipeline, which is what I'm trying to unit/integration test with `act-js`. Is it possible that if I kick off the unit-test run with a workflow that uses `push`, the reusable workflows called by it will get their inputs properly passed on?

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@ChristopherHX commented on GitHub (Apr 25, 2025):

tldr in https://github.com/actions-oss/act-cli/actions/runs/14670440643 is "act-cli" creating the workflow I mentioned above itself.

Still this isn't a supported mode of operation.

@ChristopherHX commented on GitHub (Apr 25, 2025): tldr in https://github.com/actions-oss/act-cli/actions/runs/14670440643 is "act-cli" creating the workflow I mentioned above itself. Still this isn't a supported mode of operation.

kerem commented

2026-03-01 21:47:57 +03:00

Author

Owner

@mcascone commented on GitHub (Apr 25, 2025):

OK, I created a test-kicker-offer that mimics our calling workflows:

name: test-kickoff.yml

on:
  push:
    branches:
      - '*'
  
  workflow_dispatch:
    inputs:
      run-type:
        description: "Only Build-And-Deploy is supported right now"
        type: choice
        default: build-and-deploy
        options:
          - build-and-deploy

permissions:
  contents: read

jobs:
  my-pipeline:
    uses: ./.github/workflows/my-pipeline.yml
    secrets: inherit
    with:
      appId: 13234
      jiraKey: EMTN
      appName: e-exp-api
      liveTests: false
      performanceTests: false
      prod: true

This calls my-pipeline successfully, with the inputs passed properly through! Win!

I also checked that the downstream workflow_call 'flows are called properly, and all of the ${{ fromJSON(<a passed-in JSON string>).<object>.<object-key> }} expressions work - even with workflow_call inputs that are defined in the downstream workflows! Big Win!

Thanks all!

@mcascone commented on GitHub (Apr 25, 2025): OK, I created a test-kicker-offer that mimics our calling workflows: ```yaml name: test-kickoff.yml on: push: branches: - '*' workflow_dispatch: inputs: run-type: description: "Only Build-And-Deploy is supported right now" type: choice default: build-and-deploy options: - build-and-deploy permissions: contents: read jobs: my-pipeline: uses: ./.github/workflows/my-pipeline.yml secrets: inherit with: appId: 13234 jiraKey: EMTN appName: e-exp-api liveTests: false performanceTests: false prod: true ``` This calls `my-pipeline` successfully, with the inputs passed properly through! Win! I also checked that the downstream `workflow_call` 'flows are called properly, and all of the `${{ fromJSON(<a passed-in JSON string>).<object>.<object-key> }}` expressions work - even with `workflow_call` inputs that are defined in the downstream workflows! Big Win! Thanks all!

kerem referenced this issue

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

[PR #984] [MERGED] refactor: extract RunContext Executor in JobExecutor #1714

Rows
Columns

[GH-ISSUE #2047] Unable to use expressions for default values in workflow_call inputs #984

Bug report info

Command used with act

Describe issue

Link to GitHub repository

Workflow content

Relevant log output

Additional information