Do we really want to run CI on all those JDKs?
Opened this issue · 3 comments
Now that the repos are being schismed, all those extra jobs mean that http4s org CI will be pulverized whenever any wide-reaching update goes out ... such as a new sbt-http4s-org :)
JEP 247 speaks to the API the artifact compiles against, but says nothing about the runtime. The only thing the JDK stores in support of the release flag are signatures. The -release flag only insulates us from linker errors. So dropping the older JDKs is not without risk. In practical terms, I think it testing across JVMs has only uncovered TLS changes.
I'd rather prove it's a problem before dropping the safety net, but I won't dig my heels in.
Right, I should have clarified: this issue is more about whether this makes sense as an org default. Many of the new repos aren't testing stuff related to TLS for example. For sure, http4s proper and the backend integrations may very well want to be more strategic about which JDKs and OSes they test on.
However, as safety nets go, you probably want them enabled by default 😆
Also, I think it is difficult to "prove" this is a problem. It just means when org-wide updates roll out, CI will be backlogged for x% more time than it would have been had we dropped these extra jobs.
There's more overhead in the polyrepo world, but most of those new repos are quick builds. We already scaled back to all the JVMs on one Scala instead of all the JVMs on all the Scalas. I think we should keep this in mind if we get annoyed, but leave it alone until we do.