I am investigating how to make generated YAML more...

# github-workflows-kt

[Damien O'Hara]

I am investigating how to make generated YAML more idiomatic per standard Github Actions conventions. could there be a future where snakeyaml-engine is replaced by a dedicated YAML builder in the library module in pursuit of this? happy to fully prototype and test a replacement for the snakeyaml emitter

[Damien O'Hara]

I know that YAML is complex and so a third party dependency seems like a foregone conclusion, but I note that:

1. the needs of the library module are restricted to serializing model objects to a subset of YAML. this is a simpler case than full YAML representation or parsing
2. snakeyaml-engine isn't successfully shielding the library from much complexity by deferring e.g. quote rules to caller
3. serialization is already handled in-house with .toYamlInternal

[Vampire]

There was a built-in serialization before that caused many unnecessary problems. So it was recently replaced by a proper YAML implementation. I doubt it will be changed back.

[Vampire]

Also what do you think is "non-idiomatic"?

[Damien O'Hara]

I did have a look at the pre-snakeyaml serialization before I asked + the associated PR and issues. I don't think it is fair to attribute the issues with the old implementation to built-in serialization in general. the old implementation was ad hoc and relied heavily on string interpolation. taking a more structured approach to generation won't have the same issues

[Damien O'Hara]

I found quite few style differences porting handwritten YAML to generated. some of them are unrelated to serialization (step ids), some of them exist between serialization and emission (e.g. emitting field: {} instead of implicit field:) and some of them are at the emission layer only (- isn't indented in output). the last one I could not find any way to fix in snakeyaml but it's possible I've overlooked a configuration value somewhere

[Piotr Krzemiński]

Is it only about YAML style? If yes, I wouldn't like to change anything here, at least now. The serialization problem has already consumed too much time, and given my limited bandwidth for the project, I'd prefer us to focus on more crucial things. Even if you contribute a tailor-made solution, it will add a piece of complexity that will have to be maintained (primarily by me) and it creates a risk of regressions. I also don't want the YAML to be particularly pretty - snakeyaml-engine is not perfect but does the job

[Piotr Krzemiński]

The primary problem with the lib now is insufficient feature coverage, I'd gladly accept some help here if you'd like to contribute

[Damien O'Hara]

understood - no need to create work that can't be prioritized