Prefer reusable build snippets

[Ignasi Marimon-Clos]

Short description

Adopt TravisCI's import feature like the scala org (usage) to reduce maintenance burden.

Details

We have multiple smaller decision:

1. don't reinvent the wheel and use scala's template VS use an akka-org specific
2. location (I think the akka-meta repo could be a good place)
3. migrate to sdkman (given the scala-org's adoption and current issues with Jabba)
4. ...?

[Johannes Rudolph]

We should at least specify a specific revision if we do this. Otherwise, that sounds like a common build plugin (rf. play) but even more likely to break your builds without you even doing anything.

[Ignasi Marimon-Clos]

We should at least specify a specific revision if we do this. Otherwise, that sounds like a common build plugin (rf. play) but even more likely to break your builds without you even doing anything.

Sure we must be careful not relying open-range upstream dependencies. I think even the minimal approach that installs sdkman and manages caches (like in the scala example) would be an improvement.

[Ignasi Marimon-Clos]

Another +1 in favor of sdkman (over jabba) is that it spans beyond installing JDK's (see for example akka/akka-guide#213 (review) where we needed maven)

[Salar Rahmanian]

Should migrating to GitHub Actions be considered?

[Patrik Nordwall]

Should migrating to GitHub Actions be considered?

That is what we will try, but it will not be a big bang migration.

[Ignasi Marimon-Clos]

Unrelated to the CI engine (TravisCI, GitHub Actions, Circle CI, etc...), the spirit of this issue is to try to reuse work.

[Patrik Nordwall]

the spirit of this issue is to try to reuse work.

@ennru mentioned that it might be easier to define things for reuse at the org level with GitHub Actions

[Johannes Rudolph]

In general, I'm against reusing snippets in builds or providing "super-builds" or just anonymous defaults that fix the structure of builds for existing or new builds.

I'm all for unifying builds through guidelines, best practices, well-thought-out abstractions where useful and possible but simple code reuse or ad-hoc abstractions (snippets, third-party scripts like jabba) are the wrong way to go.

Good abstractions are:

• not internal but can or could be public because of their general usability (e.g. sbt plugins)
• referenced by a fixed id (checksum, version, etc)
  • in particular don't use internal or external scripts loaded from links that can be pulled out and replaced

In all other cases, I'd prefer copy and paste to anything else. That ensures

• that every build is self-contained and can be debugged on the spot
• every build can be fixed without needing access to other parts of internal infrastructure
• builds (especially half-dormant ones) continue to work and are not disrupted by more general changes in the infrastructure