Add functionality for parsing Action inputs from a workflow file - #1392
henrymercer merged 8 commits into
Conversation
Sorry, something went wrong.
No semantic changes.
This is a common case, so we should handle it.
This better handles cases where customers have a monorepo and have separate jobs for different components.
aeisenberg
left a comment
There was a problem hiding this comment.
OK. This will now throw if we can't determine what the actual input value is. I don't actually see where getting the category is being used. Is that coming in a later PR? We should make sure that the action doesn't fail if it can't find the category (most likely, the action will already have failed for some other reason, so we need to at least make sure that this failure doesn't hide the original failure).
Sorry, something went wrong.
|
This functionality is just for #1393 — ideally we'd minimise the number of places where we need to do this hacky parsing of the workflow. We wrap it in a try-catch block there to avoid hiding the original failure as you mention. I think the tryOrThrow names should make it fairly obvious that these functions should generally be surrounded by try-catch blocks — is there anything else we should do to avoid future consumers creating bugs? |
Sorry, something went wrong.
|
I think that all makes sense. I'll review #1393 later today. Maybe just adding a comment to the function suggesting that it should be wrapped in a try-catch. |
Sorry, something went wrong.
aeisenberg
left a comment
There was a problem hiding this comment.
LGTM. Optionally, add a comment to the tryOrThrow... functions to suggest wrapping in try-catch.
Sorry, something went wrong.
In order to upload SARIF files for code scanning runs where the init step failed, we need to be able to handle the case where the analyze Action did not run. In this case, the post-analyze step will not be run, and therefore we don't know the inputs to analyze. (In particular, we care about category, upload, and checkout_path.)
This PR implements some functionality to make a best effort attempt to work out the value of an input to an Action given the workflow file and information that's available to the init step like matrix variables. I recommend reviewing the first commit separately since it separates out workflow-related code into a separate file workflow.ts.
Merge / deployment checklist