Properly JSON-decode outputs #4927
Conversation
MelvinBot
requested review from
stitesExpensify
and removed request for
a team
|
Because this is part of the effort to resolve a deploy fire, I did not spend any time refactoring existing workflows to follow the new best-practice of relying on |
|
|
There was a problem hiding this comment.
Going forward, we should all recognize that any output in a GitHub workflow is a JSON string, and must be treated as such.
I think we should also create a PR (or follow-up issue) to update incorrect usages in other workflows once deploys are fixed, just so we don't have inconsistent usages.
Other than that, I agree with having more strict checks for these and making that the standard.
|
Yep, I agree we should handle that refactoring in a follow-up. Follow-up issue created for myself here. |
|
Going to go ahead and merge to speed up the feedback loop and hopefully fix deploys. |
|
🚀 Deployed to staging by @roryabraham in version: 1.0.89-0 🚀
|
|
🚀 Deployed to production by @roryabraham in version: 1.0.90-2 🚀
|
Details
After a fair deal of discussion and experimentation in
Public-Test-Repo, I learned that, even after this PR, not all json values were being properly decoded.Going forward, I think we should establish the explicit use of
fromJSONas a best-practice over doing string comparisons as we have in the past. UsingfromJSONis a more explicit way of handling this data, and using it demonstrates a better understanding of the problem, and might be easier to remember to look for when writing GH Workflows and reviewing PRs.Going forward, we should all recognize that any output in a GitHub workflow is a JSON string, and must be treated as such.
Fixed Issues
$ n/a
Tests
Same as #4796
QA Steps
None.