https://kotlinlang.org logo
Title
v

vladimirsitnikov

02/06/2023, 5:05 AM
@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
p

Piotr Krzemiński

02/06/2023, 6:17 AM
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
v

vladimirsitnikov

02/06/2023, 9:18 AM
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
p

Piotr Krzemiński

02/06/2023, 9:20 AM
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’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
v

vladimirsitnikov

02/06/2023, 10:33 AM
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)
p

Piotr Krzemiński

02/06/2023, 10:33 AM
ah, I see!
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?
if I stil l don’t get something, I’d be grateful for a concrete example
a comprehensive feature parity analysis would have to be done to ensure JSON schema allows what’s already possible with the custom solution
https://github.com/Vampire/setup-wsl/blob/master/action-types.yml can be our working example, it uses various kinds of typings available now
v

vladimirsitnikov

02/06/2023, 1:12 PM
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
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
p

Piotr Krzemiński

02/06/2023, 8:34 PM
What would be the benefit of such approach?
v

vladimirsitnikov

02/07/2023, 3:44 AM
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?
p

Piotr Krzemiński

02/07/2023, 5:17 AM
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?
v

vladimirsitnikov

02/07/2023, 5:30 AM
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
p

Piotr Krzemiński

02/07/2023, 10:37 AM
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
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)
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