<@U0152P3VB5J> thanks a lot for your feedback! jus...
# github-workflows-kt
p
@Vampire thanks a lot for your feedback! just noticed the issues you've created. Are you working on introducing the DSL in your project, or just playing around for fun?
v
Both. I'm playing around and want to migrate to your DSL, I really like the idea. I have a pre-processing step currently already anyway as I use YAML anchors and then pre-process the workflow to flatten out their usage. I also have the wrapper definition to contribute for my action ready, just wanted to test it first before I open a PR.
🆒 1
Thanks for your work in this project
I'll most probably will find some more things to report for sure 😄
All things I reported so far I hit when trying to start migrating my action to your DSL. If you are interested, it is https://github.com/Vampire/setup-wsl/blob/master/.github/workflows/template/test.yml / https://github.com/Vampire/setup-wsl/blob/master/.github/workflows/test.yml
p
Wow, that's a pretty complicated workflow! :) thanks a lot for reporting these missing features. We don't have much processing power but we'll tackle them one by one
Since you're an action owner, let's add a wrapper for your action - tracked in https://github.com/krzema12/github-actions-kotlin-dsl/issues/299
v
Wow, that's a pretty complicated workflow! :)
Indeed, that's why I hoped I could replace it by code. :-) It is the systemtests for my action, running daily. And they are necessary, GitHub already broke it a few times suddenly.
Since you're an action owner, let's add a wrapper for your action
As I said, I have the code for a PR for that ready already. I just wanted to test it first. :-) I tried to test it with my test workflow, but it seems correct limitations are probably too limiting for now, unless I go different ways, like multiplying-out the matrices in Kotlin code instead of using matrices.
👍 1
Btw. is there a reason you are using plain String building for building the YAML, instead of building it for example using
kotlinx-serialization
or similar? If you want to change that, 1.5 years ago I wrote DAOs for
kotlinx-serialization
with KAML for GitHub Action files and GitHub Workflow files. They support the whole syntax, including things like
on:
that can be a scalar if only one simple value is contained, a list if only simple values are contained, or a full map, both for serializing and deserializing. I didn't touch them since then, but I guess GitHub did not change much, if at all. You could copy those, or I could drag them out into a library and publish them if you prefer.
p
is there a reason you are using plain String building for building the YAML, instead of building it for example using
kotlinx-serialization
or similar?
Good question! At the very beginning I was using kotlinx.serialization and kaml, but decided to move away from it (see this commit) because of kaml's quirks which needed some weird workarounds and YAML post-processing. Back then in the specific circumstances I felt it was a good decision, but now whenever I touch this piece of code that creates YAML, I keep thinking of bringing back the previous approach (see this issue). Especially that a similar library and your solution do use kaml. For now it's not the most painful issue in the project, but I'd be happy if we do some refactoring around this topic one day. Thanks for the DAOs, I wouldn't like to blindly copy them because they look fairly complicated - I'd like to understand them first and understand why such custom code is needed.
v
I wouldn't like to blindly copy them because they look fairly complicated - I'd like to understand them first and understand why such custom code is needed.
I actually invented them to parse my action file for having a
run
task that can run my action locally with automatically setting the default values defined in the action file, and for the workflow file to be able to parse my template with YAML anchors and then write it out flattened-out like GitHub needs it. But I also used it to get a bit more familiar with
kotlinx-serialization
so I wrote them fully-equipped so that they can parse any valid syntax. As the full valid syntax is polymorphic, it needed a bit of custom serializers. For example
runs
in the action file looks differently between JavaScript, Docker, and Composite actions. Or
output
looks differently if it is a composite action than if it is a normal action. And for the workflow file it is things like
on
being able to have a simple string as value, a string list, or a full map and similar things. Feel free to ask me anything you want to know about it or if you prefer a lib from it.
p
Thanks, one day I'll give it a shot :)
v
Having an object structure would maybe also open the possibility to give the constructed object tree to the script for further post-processing before finally creating the YAML. 🙂