Do we want statically typed CI workflows?

[EliahKagan]

There is a Kotlin DSL for writing GitHub Actions workflows in a fully statically type-checked manner. It compiles to YAML and there are also automated mechanisms for checking that the compiled workflow is current with edits to the Kotlin file.

What would be even nicer, in a Rust project like this one, would be a Rust DSL, which I expect may be possible to create, but as far as I have been able to find, there is not one.

Should we use github-workflows-kt? This would address some of the headaches of writing workflows in YAML. It should also allow pieces of workflows to be written once and reused, even without writing a composite action or reusable workflow.

Rust programmers are likely to value the benefits of being statically typed. But Rust programmers are also more likely to know YAML than Kotlin. I'm not sure how much that matters, because the DSL seems rather intuitive--here's an example of it in use--and the subtleties of YAML syntax, especially with respect to strings, are substantial enough that merely knowing YAML is not always sufficient to protect one from them. I say this as someone who does not know Kotlin.

I think the biggest reasons why maybe this should not be done, which are inapplicable for projects that are otherwise making significant use of Kotlin but applicable here, are:

• More tooling is required. To get the benefit of using a Kotlin DSL, one needs to have the ability to compile Kotlin. To get the full benefit, one needs Kotlin support in one's editor. These are readily available, but could still be experienced as an inconvenience.
• It could be intimidating. That is, even if the practical effect is that editing the workflows is easier and even requires less knowledge and experience with YAML and GitHub Actions--which I expect to be the case, since one will have much stronger tooling support when writing the files!--the added layer of indirection may still cause newcomers who are familiar with GitHub Actions but not Kotlin or this DSL, and who are interested in contributing improvements to the workflow files, to be less immediately able or willing to do so.

[Byron]

Thanks for bringing this up, it's a very interesting find.

If it was any other language, I'd probably be OK trying it, but as someone who looses the will to live even when seeing these import statements, I am afraid I'd never touch these workflows again if they were using this DSL.

I was thinking that maybe a YAML or JSON schema would work - JSON parses as valid YAML, and maybe that could be used along with a JSON schema validator to produce YAML files from JSON files in a type-checked way. All that could go into the just file for automation.

JSON isn't quite as nice to look at, but it might be worth it.

It's also notable that my IDE, RustRover, does have support for schema-checking GitHub workflows built-in already, maybe that's a solved problem by now also in VSCode or other editors?

[EliahKagan]

I think the imports themselves can be written with wildcards, so:

-import io.github.typesafegithub.workflows.actions.actions.CheckoutV3
-import io.github.typesafegithub.workflows.actions.gradle.WrapperValidationActionV1
-import io.github.typesafegithub.workflows.domain.RunnerType.UbuntuLatest
-import io.github.typesafegithub.workflows.domain.triggers.PullRequest
-import io.github.typesafegithub.workflows.domain.triggers.Push
+import io.github.typesafegithub.workflows.actions.*
+import io.github.typesafegithub.workflows.domain.*

I suspect, however, that this might not be enough to cause you to want to have and work with such workflows. Any change along these lines should make them more enjoyable to work on for everyone who will be modifying them, reviewing modifications to them, considering bug reports about them, etc. So it sounds like this DSL is not the way to go. But if the highly repetitious imports were the only issue, you can let me know.

It's also notable that my IDE, RustRover, does have support for schema-checking GitHub workflows built-in already, maybe that's a solved problem by now also in VSCode or other editors?

The GitHub Actions extension for VS Code does attempt this, yes. I don't know if it's as good as in the JetBrains editors. I have RustRover installed but I only use it occasionally.

However, I think RustRover can be used as a GitHub Codespaces client, and I had planned to test the changes from #1502 with it. Currently the dev container configuration does not cause the GitHub Actions extension for VS Code to be installed automatically, nor the Bash IDE extension that can be useful when editing fixture shell scripts. (It does cause CodeLLDB and Even Better TOML to be installed automatically, even though not listed, I believe because the Rust image it uses requests them; it would thus technically not have to explicitly list the rust-analyzer extension either.) So I may look at all this stuff together, and when I do, I should get a sense of how the VS Code and RustRover experiences compared for editing GitHub Actions workflows.

[Byron]

Yes, indeed I'd still prefer to focus on leveraging the existing IDE support to the fullest to make the YAML experience better.

[EliahKagan]

Sounds good.

I'll let you know what I find when I compare the experiences in VS Code and RustRover.