fix: allow mapping into env variable INPUT_N from ${{ inputs.n }}

mfenniak commented

2025-10-10 16:35:53 +00:00

Owner

When using a reusable workflow such as:

name: "use-inputs-impl"

on:
  workflow_call:
    inputs:
      image:
        description: "Image to be used in job"
        type: string
        required: false
        default: "docker.io/alpine:3.22"
      condition:
        description: "Only run a job if this is true"
        type: string
        required: false
        default: false

jobs:
  works:
    runs-on: docker
    container:
      image: alpine:3.22
    env:
      INPUT_IMAGE: ${{ inputs.image }}
      INPUT_CONDITION: ${{ inputs.condition }}
    steps:
      - run: echo "Hello world from Alpine"
      - run: cat /etc/alpine-release
      - run: echo "INPUT_IMAGE=$INPUT_IMAGE"
      - run: echo "INPUT_CONDITION=$INPUT_CONDITION"

The runner will currently output un-evaluated expressions:

INPUT_IMAGE=${{ inputs.image }}
INPUT_CONDITION=${{ inputs.condition }}

Internally, the workflow is using INPUT_... environment variables to transfer data into local reusable workflows, and the order of evaluation in getEvaluatorInputs was preferring to use the un-evaluated value, over the evaluated value.

bug fixes
- PR: fix: allow mapping into env variable INPUT_N from ${{ inputs.n }}

When using a reusable workflow such as: ```yaml name: "use-inputs-impl" on: workflow_call: inputs: image: description: "Image to be used in job" type: string required: false default: "docker.io/alpine:3.22" condition: description: "Only run a job if this is true" type: string required: false default: false jobs: works: runs-on: docker container: image: alpine:3.22 env: INPUT_IMAGE: ${{ inputs.image }} INPUT_CONDITION: ${{ inputs.condition }} steps: - run: echo "Hello world from Alpine" - run: cat /etc/alpine-release - run: echo "INPUT_IMAGE=$INPUT_IMAGE" - run: echo "INPUT_CONDITION=$INPUT_CONDITION" ``` The runner will currently output un-evaluated expressions: ``` INPUT_IMAGE=${{ inputs.image }} INPUT_CONDITION=${{ inputs.condition }} ``` Internally, the workflow is using `INPUT_...` environment variables to transfer data into local reusable workflows, and the order of evaluation in `getEvaluatorInputs` was preferring to use the un-evaluated value, over the evaluated value.   - bug fixes - [PR](https://code.forgejo.org/forgejo/runner/pulls/1080): fix: allow mapping into env variable INPUT_N from ${{ inputs.n }}

mfenniak commented

2025-10-10 16:36:28 +00:00

Author

Owner

I can't see any reason why environment variables starting with INPUT_* are considered to be inputs, so I'm removing this and running the full test suite to see if anything pops up. If nothing comes up, I'll add test automation covering the expected working case.

I can't see any reason why environment variables starting with `INPUT_*` are considered to be inputs, so I'm removing this and running the full test suite to see if anything pops up. If nothing comes up, I'll add test automation covering the expected working case.

proton-ab commented

2025-10-10 19:16:17 +00:00

First-time contributor

This workflow looks invalid. Have you tested it how GitHub reacts? Per documentation it says that INPUT_ environment variable is created for each input. Manually creating environment variable that would overwrite what input sets sounds like invalid case. This workflow should work without env being declared.

GitHub seems to allow re-declaration of INPUT_ environment variables but evaluates inputs before assigning them properly, so this PR would make it align with how it behaves.

~~This workflow looks invalid. Have you tested it how GitHub reacts? Per [documentation](https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax#inputs) it says that `INPUT_` environment variable is created for each input. Manually creating environment variable that would overwrite what `input` sets sounds like invalid case. This workflow should work without `env` being declared.~~ GitHub seems to allow re-declaration of `INPUT_` environment variables but evaluates `inputs` before assigning them properly, so this PR would make it align with how it behaves.

mfenniak force-pushed input_env-fix from 617be783d1

issue-labels / release-notes (pull_request_target) Successful in 7s

Details

checks / validate pre-commit-hooks file (pull_request) Successful in 58s

Details

checks / validate mocks (pull_request) Successful in 1m33s

Details

checks / build and test (pull_request) Successful in 4m27s

Details

checks / runner exec tests (pull_request) Successful in 39s

Details

Integration tests for the release process / release-simulation (pull_request) Successful in 6m39s

Details

checks / runner integration tests (pull_request) Successful in 6m42s

Details

checks / integration tests (pull_request) Failing after 14m44s

Details

to fe409b162c

checks / validate pre-commit-hooks file (pull_request) Successful in 1m1s

Details

checks / validate mocks (pull_request) Successful in 1m21s

Details

checks / build and test (pull_request) Successful in 1m36s

Details

checks / runner exec tests (pull_request) Successful in 46s

Details

Integration tests for the release process / release-simulation (pull_request) Successful in 6m28s

Details

checks / runner integration tests (pull_request) Successful in 7m12s

Details

checks / integration tests (pull_request) Successful in 17m19s

Details

issue-labels / release-notes (pull_request_target) Successful in 7s

Details

cascade / debug (pull_request_target) Has been skipped

Details

cascade / forgejo (pull_request_target) Successful in 55s

Details

cascade / end-to-end (pull_request_target) Successful in 6s

Details

2025-10-10 19:18:55 +00:00

Compare

mfenniak changed title from ~~WIP: fix: don't map env variables INPUT_... into ${{ inputs.... }}~~ to fix: allow mapping into env variable INPUT_N from ${{ inputs.n }}

2025-10-10 19:21:08 +00:00

mfenniak commented

2025-10-10 19:27:30 +00:00

Author

Owner

@proton-ab This is a composite workflow, which if following the documentation you've linked, would fall into "... then it will not automatically get INPUT_<VARIABLE_NAME>".

I think the workflow intent is easily understood, regardless? This doesn't seem extra-ordinary to me:

    env:
      INPUT_IMAGE: ${{ inputs.image }}
      INPUT_CONDITION: ${{ inputs.condition }}

@proton-ab This is a composite workflow, which if following the documentation you've linked, would fall into "... then it will not automatically get INPUT_<VARIABLE_NAME>". I think the workflow intent is easily understood, regardless? This doesn't seem extra-ordinary to me: ``` env: INPUT_IMAGE: ${{ inputs.image }} INPUT_CONDITION: ${{ inputs.condition }} ```

proton-ab commented

2025-10-10 19:29:24 +00:00

First-time contributor

Yeah, sorry for confusion. Here's related GitHub issue https://github.com/actions/runner/issues/665 that documents this method as workaround too, so we very much want to have this sorted.

👍 1