Publish job fails if artefacts are not built against Java 1.8 about sbt-github-actions HOT 5 CLOSED

One of my projects just can't be built without Java 14 since it uses JEP-370 API.

@djspiewak can you please explain the point of pinning of publish job to [email protected]? I just can't figure it out, seems like I'm missing something.

from sbt-github-actions.

There probably isn't a good reason for it. :-) I think the right thing to do is probably pin the publish job to the head of the JVMs list. I'll PR that quickly.

from sbt-github-actions.

Fixed in 0.6.2!

from sbt-github-actions.

There probably isn't a good reason for it. :-) I think the right thing to do is probably pin the publish job to the head of the JVMs list. I'll PR that quickly.

But won't the download step fail if the publish job doesn't use the exact same version as the build job?

As per my screenshots, the publish job and the build job use the java version for the URLs they fetch/save assets to (respectively), thus if they differ, the publish job will fail.

the right thing to do is probably pin the publish job to the head of the JVMs list

Isn't the right thing to make the publish job use the same version as the build job instead?

Having said this, I can see my publish job is now using the same version as what I've specified for the build, so seems to work 🤷‍♂️ 😄

Thanks!

from sbt-github-actions.

Isn't the right thing to make the publish job use the same version as the build job instead?

Well, the problem is that you can build with multiple JVMs (easy example: JDK 8 and JDK 11, but Graal also qualifies). You only want the publish job to run once, so we have to pick a JVM to use. The good news is that, as long as all of the build JVMs uploaded their artifacts, the publish job can use any one of them and it's fine. The only exception would be if you build different artifacts on different JVM versions and need them all to publish under some sort of version classifier scheme. I'm not aware of anyone who is actually doing something like that though (it would be really hard to correctly resolve such artifacts in downstream projects), so I feel pretty comfy declaring it "out of scope". :-)

from sbt-github-actions.