# github-workflows-kt

Damien O'Hara

02/05/2023, 8:58 AM
I am investigating how to make generated YAML more idiomatic per standard Github Actions conventions. could there be a future where
is replaced by a dedicated YAML builder in the
module in pursuit of this? happy to fully prototype and test a replacement for the snakeyaml emitter
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
module are restricted to serializing model objects to a subset of YAML. this is a simpler case than full YAML representation or parsing 2.
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


02/05/2023, 12:48 PM
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.
Also what do you think is "non-idiomatic"?

Damien O'Hara

02/05/2023, 1:22 PM
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
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
) 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

02/05/2023, 1:42 PM
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
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

02/05/2023, 1:52 PM
understood - no need to create work that can't be prioritized