Piotr Krzemiński

We should consider going back to kotlinx.serialization + kaml or equivalent, for the sake of delegating the problem of YAML synthesis. It's getting more and more tedious to generate YAML...

After thinking a little, kaml doesn't seem to be the optimal choice for now. Here's why: * it includes the `type` field to handle polymorphism which we don't actually need,...

Thanks! FTR, here are the DAO classes with custom serializers: https://github.com/Vampire/setup-wsl/tree/master/buildSrc/src/main/kotlin/net/kautler/dao I have to finally find time to wrap my head around it :smile: Regarding supporting custom arguments, I'd like...

@jmfayard feel free to share it on a branch. ---- Regarding the idea of using snakeyaml, I prepared such PoC depicting what I mean by being able to define `_customArguments`:...

@LeoColman Do you have capacity to prepare a short PoC like mine?

@jmfayard **Json**Element - typo? I don't quite get it, PoC please 🙏 😄 I'm also curious how it would differ from the snakeyaml-like approach.

I'm gonna go the snakeyaml approach for now since - it fulfills the current API's needs - is simple to understand - requires no extra dependencies - will address several...

Working on https://github.com/krzema12/github-actions-kotlin-dsl/issues/87 first, to better catch regressions that may result from changing the YAML emitting method.

> For dependencies, [refreshVersions](https://github.com/jmfayard/refreshVersions) can take care of both generating the versions catalog and finding available updates instead of dependabot, but I don't know what @krzema12 thinks @jmfayard to be...

Side-note: due to my chronical lack of time, such refactoring would be much easier for me to review if it tackled a smaller bit at once. E. g. extracting publishing...