@Piotr Krzemiński , have you tried asking GitHub to add type information to action.yml schema? Information like type (string, numeric, enum) is helpful anyway. It might be that json schema would work nice there. I guess the repo for the issue would be https://github.com/actions/runner

I asked indirectly here: https://github.com/orgs/community/discussions/32054 I've never heard back from the "product team". If you think creating an issue in the runner repo can help, I'd be grateful if you could express this idea there. I don't want to spam too much as the library author

The idea is pretty much the same: integrate type information into

action.yml

, so action authors can specify types of arguments and the encoding options (e.g. list delimited by

,

) I see you’ve invented your own

action-types.yml

in github-actions-typing. However, I would like to stick with https://json-schema.org/ instead. For instance, there’s JSON schema for

action.yml

itself, so IDEs (e.g. IntelliJ IDEA) can autocomplete

action.yml

values: https://github.com/SchemaStore/schemastore/blob/35f210a155273520e48fdb48fa64c1fb5df2c5ae/src/schemas/json/github-workflow.json So I am inclined that adopting json schema for

action-types.yml

(and for placing types in

action.yml

for GitHub-native) would be superior than a custom

action-types.yml

If GitHub wanted to introduce this feature, I agree they should do it in

action.yml

. However, since the typing solution a third-party tool, I don’t want to “extend” the original manifest. See a discussion here: https://github.com/krzema12/github-workflows-kt/issues/302#issuecomment-1162752831 - it was a driver for creating

action-types.yml

I think we don’t understand each other. What I mean is to use JSON schema instead of

type: string

In other words, currently

action-types.yml

uses its own language for declaring types. However, it would be better if

type:

attribute contained JSON schema value. for instance,

type: array, items: …

(JSON schema) instead of

type: list

(github-actions-typing custom dsl)

ah, I see!

inputs:
    distribution:
        type: enum
        allowed-values:
            - Alpine
            - Debian
            - kali-linux
            - openSUSE-Leap-15.2
            - Ubuntu-22.04
            - Ubuntu-20.04
            - Ubuntu-18.04
            - Ubuntu-16.04

=>

inputs:
    distribution:
        enum:
            - Alpine
            - Debian
            - kali-linux
            - openSUSE-Leap-15.2
            - Ubuntu-22.04
            - Ubuntu-20.04
            - Ubuntu-18.04
            - Ubuntu-16.04

What would be the benefit of such approach?

The benefit is to avoid reinventing the wheel. People already invested time in json schema and polished it. There are answers on StackOverflow. What is the benefit of creating a new dsl that effectively duplicates json schema?

IMO it's not the right use case for a schema. It's not like we get a YAML and we need to validate it against the schema - then JSON schema would be the answer. The use case is about generating code and we need some more information than the schema provides like the separator you mentioned or hints regarding naming entities in the code. Do you mean that the custom DSL could mimic JSON Schema and extend it where necessary?

The purpose of the schema is to describe the schema of the data. Validation is one of the tasks where schema might help, however schema does not require that you validate. At the same time, schema can help with code generation. JSON schema was designed for extensibility: https://json-schema.org/draft/2019-09/json-schema-core.html#rfc.section.6.5

ok, I see - it’s stating to make more sense to me. It would be cool to e.g. be able to limit the value of an integer and enforce it in the generated code, or have union types