Create a tool for providing typings for action inputs and outputs

Problem statement

Currently it’s challenging to add support for multiple new actions. Each new action requires checking its inputs and inferring their types which then land in WrappersToGenerate.kt. Sometimes they are provided by the authors in README, sometimes they are inferred from input’s description or type of default value. It doesn’t scale well, introduces a risk of human error and adds operational load for actions already supported if they get new inputs.

Proposed solution

We should encourage action owners to proactively provide types for their actions’ APIs in a standardized manner. The proposed approach is to have a GitHub action that would read action’s manifest (action.y(a)ml) and would validate an extra type attribute for each input and output. This DSL library currently generates type-safe API only for inputs, but in the future the outputs can be type-safe as well.

Once such approach becomes popular, an automated job could proactively scan GitHub for actions using the typing validation action mentioned above, and add it to the list of requested wrappers. In the future, once Kotlin compiler plugins are easier to use from Kotlin scripting, I can imagine generating necessary wrapper code using such plugin, which would remove the need to maintain wrappers code in the library.

[jmfayard]

I thought https://github.com/krzema12/github-actions-kotlin-dsl/pull/308 would make it easy to submit pull requests 😃

[krzema12]

@Vampire great feedback, thanks! Yeah, I get your concern, I also thought about it. The major reason why I decided to put type info in existing action.yml is that this is the source of truth for action inputs and outputs. Now we have a trade-off: for now the schema validators will report type-related fields as incorrect, but in return the action manifest is self-contained and you don’t have to jump between two files to read full information about a given input/output. My hope is that this kind of spec will lead GitHub to introducing something similar (that’s why I wrote “for now”), but it may happen or not - no hard assumptions here.

Now when I think of it, what you propose is a reasonable compromise. Additionally I’d implement a piece of logic that ensures all inputs and outputs defined in action.yml are also present in action-types.yml.

@jmfayard how does it sound to you?

More action owners’ feedback greatly welcome here!