-
Notifications
You must be signed in to change notification settings - Fork 921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Boolean inputs are not actually booleans in composite actions #2238
Comments
Would be nice to have non string inputs in composite actions, especially the object type would be great in my opinion inputs:
...
myobjinput:
description: ...
required: false
type: object
runs:
using: composite
steps:
- run: |
echo '${{ tojson(inputs.myobjinput) }}' Fun fact this composite action will also use the type string for myobjinput, because the
|
I bumped on this also today. I am calling my composite action from a workflow with a boolean input as follows: ...
on:
workflow_dispatch:
inputs:
realRun:
description: Really run?
default: false
type: boolean
...
jobs:
run-tests:
- uses: my-org/test-run@main
with:
realRun: ${{ inputs.realRun == true }} And this is how my composite action ...
inputs:
realRun:
description: Really run?
default: false
type: boolean
...
runs:
using: composite
steps:
- name: Check realRun input value
shell: bash
run: echo "realRun==${{ inputs.realRun == true }}"
- name: Run tests
if: ${{ inputs.realRun == true }}
shell: bash
run: ${{ github.action_path }}/bin/run_tests.sh That will always echo |
I was hoping to do something similiar with the output of a composite action, but there doesn't seem to be any way to force it to be a boolean either. I'm using:
This shouldn't be surprising given that it is documented but it's still frustrating and you end up with the same "always evaluates to false" problem. |
Agree with @veleek - this is very frustrating to have conditions like the following:
It would be nicer if the outputs were boolean, so the condition looks like this:
The outputs in the composite actions look like this:
|
+1 to this. Just recently ran into this exact issue, with the only reasonable workaround being to use string semantics as detailed in the original post. |
This appears to be true for docker based actions as well. |
+1 |
Just ran into this issue as well. There doesn't seem to be any related information on the official documentation, and it is very non-intuitive to have |
I just spend several hours trying to pass a true value... The way to do it is: Job:
Composite:
This makes no sense at all and is not documented. |
This avoids failures when running on PRs from forks. We do it in this convoluted way because you can't access secrets directly from `if` blocks: actions/runner#520
Writes to a cache from a pull request are not visible elsewhere, so * Build the caches in postsubmit so that they will be available eventually * While we're at it, run all tests as a postsubmit in case of rebase issues. * Don't save caches in the PR so that they won't spam persistence. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache While we're at it, switch to environments for better security since secrets could otherwise be available to pull requests before review, and add the patrol cache. Fun fact: actions/runner#2238
Writes to a cache from a pull request are not visible elsewhere, so * Build the caches in postsubmit so that they will be available eventually * While we're at it, run all tests as a postsubmit in case of rebase issues. * Don't save caches in the PR so that they won't spam persistence. * Also don't bother generating an emulator image for caching on PR workflows. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache While we're at it, switch to environments for better security since secrets could otherwise be available to pull requests before review, and add the patrol cache. Fun fact: actions/runner#2238
Writes to a cache from a pull request are not visible elsewhere, so * Build the caches in postsubmit so that they will be available eventually * While we're at it, run all tests as a postsubmit in case of rebase issues. * Don't save caches in the PR so that they won't spam persistence. * Also don't bother generating an emulator image for caching on PR workflows. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache While we're at it, switch to environments for better security since secrets could otherwise be available to pull requests before review, and add the patrol cache. Fun fact: actions/runner#2238
Writes to a cache from a pull request are not visible elsewhere, so * Build the caches in postsubmit so that they will be available eventually * While we're at it, run all tests as a postsubmit in case of rebase issues. * Don't save caches in the PR so that they won't spam persistence. * Also don't bother generating an emulator image for caching on PR workflows. https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#restrictions-for-accessing-a-cache While we're at it, switch to environments for better security since secrets could otherwise be available to pull requests before review, and add the patrol cache. Fun fact: actions/runner#2238
Also worth nothing that if expressions are always evaluated to strings https://docs.github.com/en/actions/learn-github-actions/expressions#about-expressions Then it seems unclear how this will ever work for passing variables from workflow call/dispatch. E.g.
|
We are seeing provider's merge without review or release. I believe it is because `automerge` is set to `"false"`, which is truthy. GitHub Actions don't mention a `type` field for composite action's inputs, which makes me afraid this is just a string. This is substantiated by actions/runner#2238.
I am also running into this and trying to sort out how to work around this. I would suggest not doing a workaround that involves using |
I have been thinking about this more lately and I'm starting to think that this is not a bug and instead is us using yaml syntax that is not actually supported or documented by GitHub. workflow_call and workflow_dispatch have inputs sections documented that include the However, the inputs documentation for composite actions doesn't document the |
@grossag, while I think that you're correct in that this is simply not a supported feature of GHActions, I think the rest of this thread makes it very clear that people would REALLY like if it we're supported. The fact that it's nearly identical to other mechanisms for declaring inputs except that it's missing |
This bug just cost me half of a work day. Why isn't anyone addressing this? |
Boolean are not booleans in composite actions, cf actions/runner#2238
Boolean are not booleans in composite actions, cf actions/runner#2238
it 2024 and GH actions doesn't treat booleans as booleans in any other software... that's a shame. |
Yeah, I just came across this scenario too, which led me here. The docs are pretty explicit in defining the inputs for composite actions and workflow dispatch inputs. However, I still found myself asking the question, 'Is the boolean input I am using in my workflow going to be passed in as a boolean or string when calling my composite action?'. At minimum, there should be a Note block added to the docs to explicitly call this out. Until this actually gets implemented (Original issue was opened in 21 so it doesn't seem likely), the note block will eliminate any confusion people have. |
Describe the bug
I'm not sure if closed issues are monitored, as there was no reaction from official side at all. This is a new issue related to #1483.
For composite actions boolean inputs are not actually booleans.
To Reproduce
Caller:
This line always evaluates to
false
:The explicit syntax does incorrectly evaluate to
false
as well:Correct behavior is only observed when using string semantics:
Expected behavior
Evaluates to
true
.Runner Version and Platform
GitHub managed runners (latest version). All platforms.
The text was updated successfully, but these errors were encountered: