fix(core): handle boolean input values from yaml

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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

[andrewdhazlett]

Fixes#361

[ericsciple]

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]

@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]

@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]

@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]

@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]

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

[ericsciple]

@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 booleanmy-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 booleanmy-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]

also @lucascosti regarding the ^ comment

[lucascosti]

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]

@lucascosti thanks! will do

[WilliamMichelMSFT]

@lucascosti@ericsciple Any updates on this?

[thboop]

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