Fix Broken Booleans Only in workflow_call Conditional Cheecks
#1236
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aj-stein-nist
added
bug
Scope: CI/CD
This fix will resolve the issue noticed in the runs post release prep. https://github.com/usnistgov/OSCAL/runs/6311164174 https://github.com/usnistgov/OSCAL/runs/6311163976 This is a workaround report in this thread. community/community#9343 (comment) It pertains to this issue, which has yet to be fixed in GitHub Actions runners that exhibit a difference in behavior for the same boolean input being treated as a string in a `workflow_dispatch` `inputs` (i.e. `github.event.inputs.*`) even if `type: boolean` is set but behaves properly as intended for `workflow_call` `inputs` (`inputs.*` which are different in the object graph) and treated as bools through and through. This is reported in actions/runner#1483. To resolve this, the buggy `workflow_dispatch` `github.event.inputs.*` will be left with the workaround as-is, conditional checking the values as strings, but we revert the changes for `workflow_call` `inputs.*` and leave them like before until actions/runner#1483 is resolved.
aj-stein-nist
force-pushed
the
issue-1231-bug-fix-workaround-actions-boolean-handling
branch
from
140f482
to
b53f152
Compare
|
@david-waltermire-nist here is an example of this working. Since I can quickly review all https://github.com/aj-stein-nist/OSCAL/runs/6315918090?check_suite_focus=true Sorry, I had to read the docs a few times to realize my error when quickly and ham-fistedly changing all of them during our pairing last night. Not sure you want an issue to remove the kludge for |
david-waltermire
approved these changes
May 9, 2022
david-waltermire
pushed a commit
that referenced
this pull request
May 9, 2022
…g. (#1236) This fix will resolve the issue noticed in the runs post release prep. https://github.com/usnistgov/OSCAL/runs/6311164174 https://github.com/usnistgov/OSCAL/runs/6311163976 This is a workaround report in this thread. community/community#9343 (comment) It pertains to this issue, which has yet to be fixed in GitHub Actions runners that exhibit a difference in behavior for the same boolean input being treated as a string in a `workflow_dispatch` `inputs` (i.e. `github.event.inputs.*`) even if `type: boolean` is set but behaves properly as intended for `workflow_call` `inputs` (`inputs.*` which are different in the object graph) and treated as bools through and through. This is reported in actions/runner#1483. To resolve this, the buggy `workflow_dispatch` `github.event.inputs.*` will be left with the workaround as-is, conditional checking the values as strings, but we revert the changes for `workflow_call` `inputs.*` and leave them like before until actions/runner#1483 is resolved.
Rene2mt
pushed a commit
to Rene2mt/OSCAL
that referenced
this pull request
May 17, 2022
…g. (usnistgov#1236) This fix will resolve the issue noticed in the runs post release prep. https://github.com/usnistgov/OSCAL/runs/6311164174 https://github.com/usnistgov/OSCAL/runs/6311163976 This is a workaround report in this thread. community/community#9343 (comment) It pertains to this issue, which has yet to be fixed in GitHub Actions runners that exhibit a difference in behavior for the same boolean input being treated as a string in a `workflow_dispatch` `inputs` (i.e. `github.event.inputs.*`) even if `type: boolean` is set but behaves properly as intended for `workflow_call` `inputs` (`inputs.*` which are different in the object graph) and treated as bools through and through. This is reported in actions/runner#1483. To resolve this, the buggy `workflow_dispatch` `github.event.inputs.*` will be left with the workaround as-is, conditional checking the values as strings, but we revert the changes for `workflow_call` `inputs.*` and leave them like before until actions/runner#1483 is resolved.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Committer Notes
Fix logical bug missed in #1231 to fix for final release. This really closes #1208.
All Submissions:
"?
Changes to Core Features:
Have you written new tests for your core changes, as applicable?Have you included examples of how to use your new feature(s)?Have you updated all OSCAL website and readme documentation affected by the changes you made? Changes to the OSCAL website can be made in the docs/content directory of your branch.