@jmfayard do you know if it's possible to create references in MkDocs to e.g. Kotlin classes or functions? Example: https://github.com/typesafegithub/github-workflows-kt/blob/34247325b7033305a11db8d48862c7c11dbdee2b/docs/user-guide/job-outputs.md?plain=1#L6 and I'd expect these 3 references to be intelligent enough to always lead to a proper place in code, and fail docs build if it's no longer there

Do I? Not really more than what I did here to get it running what we wanted to have. 😄

I looked at the snippets mechanism and it's rather simple. What I have in mind would have to be language-aware

Exactly, that's part of where my doubt stems from 🙂

As a MkDocs user (a person writing the docs and then using them), how would you expect such code reference to work and look? I may be crazy enough to implement it one day. I have my ideas, but I don't want to bias you

Maybe similar to links? Something like this:

[`outputs`](verify-symbol:io.github.typesafegithub.workflows.dsl.WorkflowBuilder#job(java.lang.String, java.lang.String, io.github.typesafegithub.workflows.domain.RunnerType, java.util.List<? extends io.github.typesafegithub.workflows.domain.Job<?>>, java.lang.String, java.util.LinkedHashMap<java.lang.String,java.lang.String>, java.util.Map<java.lang.String,? extends java.util.List<java.lang.String>>, java.util.Map<java.lang.String,? extends java.lang.Object>, java.lang.Integer, io.github.typesafegithub.workflows.domain.Concurrency, OUTPUT, kotlin.jvm.functions.Function1<? super io.github.typesafegithub.workflows.dsl.JobBuilder<OUTPUT>,kotlin.Unit>)#outputs)

Not sure if we'd have to go through

WorkflowBuilder

here, unless your intent was to ensure that the given

job

method indeed returns something that has

outputs

. If we just wanted to check if the

outputs

field is in

Job

, maybe it would be enough to find a match in the API dump from Kotlin binary compatibility plugin: https://github.com/typesafegithub/github-workflows-kt/blob/34247325b7033305a11db8d48862c7c11dbdee2b/library/api/library.api#L102. It's not a property there but a regular JVM getter, but still better than nothing (thinking aloud)

You talk about the parameter there, not about the field. So checking for the field would not really be correct, would it?

True, sorry! So these are two kinds of references, yes