<@U0152P3VB5J> I have an interesting problem relat...

# github-workflows-kt

[Piotr Krzemiński]

@Vampire I have an interesting problem related to Gradle and Maven packages. I want to switch to action bindings from the server in the library's tests: https://github.com/typesafegithub/github-workflows-kt/pull/1554/files
• in the IDE, I'm getting an error when using AddAndCommit : Type mismatch. Required: Action<TypeVariable(T)> Found: AddAndCommit. When I navigate to the generated class, I cannot enter `RegularAction`'s definition. It's weird because I thought this piece (declaring a dependency on the library) should do the job
• Gradle, as you can see, is failing with Reason: Task ':github-workflows-kt:test' uses this output of task ':github-workflows-kt:jar' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed. . Why does it think this way? It's probably related to the fact that adding a dependency on the action binding adds a transitive dependency on github-workflows-kt in version 2.3.0
I tried adding this dependency also in another module (not gitub-workflows-kt), and only the first error materializes. And for a totally different repo, there's no problem at all.
Do you have an intuition what's wrong here?

[Piotr Krzemiński]

as a workaround, I went with

tasks.test {
    dependsOn(tasks.jar)
}

and agreed to have IDE errors in several files, but I still don't have full understanding what's going on here

[Vampire]

An explicit dependsOn is seldomly the right solution.
An explicit dependsOn where on the left-hand side is not a lifecycle task is almost always a code-smell and not what you should do, even if the bad recommendation by Gradle says it.
But this is usually just symptom treatment instead of properly fixing the problem, just shifting the problem to a later point in time where it is is harder to find, reproduce, and debug.

[Vampire]

That it is red in the IDE is probably more a problem in the KTIJ that you should report.
Especially if it works through Gradle run.
The dependency from the lib on the action is working.
As you can see in ./gradlew github-workflows-kt:dependencies --configuration testRuntimeClasspath, the dependency is there and replaced with a dependency on the main source set as it has the higher version, as expected.
And if you look in the module settings of the test module, you also see it has a dependency on the main module where the RegularAction class is there.

Why it is not seeing the correct type, even though Gradle and thus the Kotlin compiler is fine, as I said, is probably a KTIJ bug you should report. Same for the navigating, which should work. But I guess they might have the same underlying problem.

If you "Decompile to Java", you can actually navigate to the RegularAction class.

Btw. would be nice if the binding server would also provide source artifacts if possible. :-)

[Vampire]

The problem with Task ':github-workflows-kt:test' uses this output of task ':github-workflows-kt:jar' actually is coming from that dependency of add-and-commit to the main artifact.

I would almost tend to call it a Gradle bug you should report.
As add-and-commit is depending on github-workflows-kt, and the main source set produces this artifact in a newer version, it is used as dependency instead.

The test source set already depends on the main source sets compile output as directories.

This dependency now additionally adds the Jar to the classpath.

This has multiple problems:
• it is unnesseary and unused, as the classes will be taken from the directories that come first in the classpath
• somehow it misses the task dependency and thus produces this error
So I think you should report that as Gradle bug.
It should not include the jar when it already has the directories, but if it adds the jar, it should also add the necessary task dependency.


In your situation, I would either exclude github-workflows-kt or do isTransitive = false as you know it will be the only dependency (the exclude is a µ cleaner of course) when you declare the dependency on add-and-commit, then this problem goes away without spurious dependsOn declarations.

[Piotr Krzemiński]

thanks a lot for the explanation! I'll parse it soon with a fresh mind, and for now, I decided to make debugging of this problem a bit more pleasant:

Btw. would be nice if the binding server would also provide source artifacts if possible. 🙂

feat(server): host source JARs for generated bindings - will auto-deploy on Sunday