Skip to content
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

fix(core): handle boolean input values from yaml #362

Closed
wants to merge 1 commit into from
Closed

fix(core): handle boolean input values from yaml #362

wants to merge 1 commit into from

Conversation

andrewdhazlett
Copy link

Fixes #361

@andrewdhazlett andrewdhazlett requested review from bryanmacfarlane and jclem and removed request for bryanmacfarlane February 24, 2020 16:46
@ericsciple
Copy link
Contributor

Workflow uses yaml 1.2, so all the yaml 1.1 boolean values should be strings not booleans

getInput always returns a string by design.

@andrewdhazlett
Copy link
Author

andrewdhazlett commented Feb 24, 2020

@ericsciple I'm not really sure what you mean about yaml 1.1 vs 1.2 values. From reading the spec it seems like 1.2 supports the same set of scalar and collection values as 1.1, which makes sense as they all map cleanly onto JSON types.

Regardless, can we at least map booleans to their canonical representations so I can just handle "true" and "false" in the consuming code?

Is there anywhere that this is documented? I've had issues in the past determining what subset of yaml GitHub supports, and even a link to the relevant source would be super helpful.

Thanks!

@bryanmacfarlane
Copy link
Member

@andrewdhazlett - see actions/checkout and actions/go for examples of handling booleans.

I think we should add a core.getBooleanInput method since the action author knows what's expected.

Inputs are set over envvars so that's why the marshalling is a string.

@andrewdhazlett
Copy link
Author

@bryanmacfarlane thanks for the reference. After some more digging, it seems that only the failsafe schema is supported. It would be nice to reference this in the documentation. Happy to submit a PR for that as well.

Looking at #336 it looks like the design around this is still a bit up in the air, can you give me any insight into where these API improvements lie on the roadmap?

@ericsciple
Copy link
Contributor

ericsciple commented Feb 24, 2020

@andrewdhazlett sorry i forgot about the different schemas... The yaml 1.2 core schema is implemented, let me know if a specific form isnt working. Good point about docs, i'll skim and see if it's mentioned anywhere.

@jclem jclem removed their request for review February 26, 2020 14:01
@jclem
Copy link
Contributor

jclem commented Feb 26, 2020

👋 I'm not a Toolkit reviewer at this time, I'll leave it to those who are! cc @ericsciple

@ericsciple
Copy link
Contributor

ericsciple commented Feb 28, 2020

@rachmari @chrispat is there a good place in the docs we can clarify we use YAML 1.2 "core schema" for tag resolution.

YAML 1.1 supported boolean values like "off" but YAML 1.2 dropped support.

YAML 1.2 has three different tag resolution schemas. Whoever implements a YAML 1.2 parser may choose not to implement the full "core schema" tag resolution. "Core schema" > "JSON schema" > "failsafe schema"

For example, in YAML 1.2 "core schema":

my-key-1: true    # value interpreted as a boolean
my-key-2: TRUE    # value interpreted as a boolean

But for YAML 1.2 parsers that only implement "JSON schema" or "failsafe schema":

my-key-1: true    # value interpreted as a boolean
my-key-2: TRUE    # value interpreted as a string

It doesnt come up often, so I wouldnt necessarily lead with it. But feels like we should have a note about it somewhere in the docs.

@ericsciple
Copy link
Contributor

also @lucascosti regarding the ^ comment

@lucascosti
Copy link

Is there a good place in the docs we can clarify we use YAML 1.2 "core schema" for tag resolution.

👋 @ericsciple If you'd like, we could insert more information about the YAML version/schema in the workflow syntax article: https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#about-yaml-syntax-for-workflows

Open an issue in the docs repo with the details and we'll take care of it 👍 🙂

@ericsciple
Copy link
Contributor

@lucascosti thanks! will do

@WilliamMichelMSFT
Copy link

@lucascosti @ericsciple Any updates on this?

@thboop
Copy link
Collaborator

thboop commented Apr 27, 2021

Thanks for the contribution, but I'm closing in favor of a dedicated getBooleanInput function #723

@thboop thboop closed this Apr 27, 2021
@andrewdhazlett andrewdhazlett deleted the fix/handle-boolean-input-values branch May 10, 2021 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

core.getInput treats YAML booleans as strings
7 participants