<@UQX3ZNU12> , have you tried asking GitHub to add...

# github-workflows-kt

[vladimirsitnikov]

@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

[Piotr Krzemiński]

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

[vladimirsitnikov]

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

[Piotr Krzemiński]

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

[Piotr Krzemiński]

I’ve been thinking about creating a JSON schema for action-types.yml files: https://github.com/krzema12/github-actions-typing/issues/82, so that it’s easier to edit these

[vladimirsitnikov]

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)

[Piotr Krzemiński]

ah, I see!

[Piotr Krzemiński]

do you mean transplanting a part of JSON schema to action.yml ? action.yml is not a valid JSON schema file, so from what I understand, it would only get inspiration of how types are defined in JSON schema, not being a functional schema, right?

[Piotr Krzemiński]

if I stil l don’t get something, I’d be grateful for a concrete example

[Piotr Krzemiński]

a comprehensive feature parity analysis would have to be done to ensure JSON schema allows what’s already possible with the custom solution

[Piotr Krzemiński]

https://github.com/Vampire/setup-wsl/blob/master/action-types.yml can be our working example, it uses various kinds of typings available now

[vladimirsitnikov]

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

[vladimirsitnikov]

additional-packages:
        type: list
        separator: ' '
        list-item:
            type: string

=>

additional-packages:
        type: array
        separator: ' ' # this is extension to json schema, so I'm not sure here to put it
        items:
            type: string

[Piotr Krzemiński]

What would be the benefit of such approach?

[vladimirsitnikov]

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?

[Piotr Krzemiński]

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?

[vladimirsitnikov]

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

[Piotr Krzemiński]

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

[Piotr Krzemiński]

feel free to create an issue in https://github.com/krzema12/github-actions-typing, and I’ll get back to it one day - right now I have no capacity to make such major change, it would be pretty costly to adjust the code generator and we’re just after releasing v1 (stable)

[Piotr Krzemiński]

just one more thing: JSON Schema has lots of features, and the code generator for sure won’t implement all of them at once. So the typing solution would have to be explicit about what features are supported, to avoid a situation where the action developer uses some schema feature and it causes the code generation to not work as intended