Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Project verification job #93

Open
rossabaker opened this issue Jan 23, 2022 · 3 comments
Open

Project verification job #93

rossabaker opened this issue Jan 23, 2022 · 3 comments

Comments

@rossabaker
Copy link
Member

Half-baked idea:

*githubWorkflowCheck runs everywhere, but doesn't vary by JVM or Scala version

  • This is also true of scalafmtSbtCheck.
  • It would also be true of prospective validation of scala-steward.conf

Should there be a project job for the project-level verifications, so they're run only once? They aren't that slow, so it's not a priority, but getting these wrong fails lots of jobs right now.

@armanbilge
Copy link
Member

armanbilge commented Jan 23, 2022

Oh, I see. I was thinking about this too wrt the scalafmtSbt check. I'd feel funny skipping the githubWorkflowCheck since it's sort of a self-consistency thing.

To take this a step further: what I have seen some projects do is put all their formatting/linting into a separate job from tests. MiMa could be separate too maybe. It buys some additional parallelism and shaves a slice off the primary job matrix. Worth considering?

It's also worth noting that a significant slow down comes from the changes in #65. Starting sbt from scratch for each step tacks on quite a bit of overhead. I'd love to use sbt's server/client mode here and spent some time looking into it, but it has various issues e.g. sbt/sbt-github-actions#74. No good ideas for this.

@rossabaker
Copy link
Member Author

Yeah, I remembered that SBT startup being faster, but the http4s build with its 80000 keys or whatever takes like 30 seconds to reload on GHA. Those separate steps may have been a mistake.

I think of the scalafmt and header checks as per-crossbuild. Those need to run across the Scala and Platform (but probably not Java) matrix. Those don't require compilation, so they might do well as a single job.

I don't think we'd want to move MiMa (or for builds that use them, semantic scalafixes), because those require compilation. Those steps could probably be reduced to a primary Java, but probably part of the main compilation and test flow.

@armanbilge
Copy link
Member

Those separate steps may have been a mistake.

I still think the trade-off is worth it, in terms of compositionality.

Regarding MiMa and scalafixes, they do require compilation, but they don't require fastOptJS or a rather large test suite. So there is sort of a balance here. We could also change the order in which they run.

That's a good point about the Java axis though. We can make these steps conditional so that they run only on the primary Java. It's a small win for now, but an easy one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants