-
Notifications
You must be signed in to change notification settings - Fork 23
Prefer reusable build snippets #141
Comments
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. |
Another +1 in favor of sdkman (over jabba) is that it spans beyond installing JDK's (see for example https://github.com/akka/akka-platform-guide/pull/213#pullrequestreview-504852391 where we needed maven) |
Should migrating to GitHub Actions be considered? |
That is what we will try, but it will not be a big bang migration. |
Unrelated to the CI engine (TravisCI, GitHub Actions, Circle CI, etc...), 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 |
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:
In all other cases, I'd prefer copy and paste to anything else. That ensures
|
Short description
Adopt TravisCI's
import
feature like the scala org (usage) to reduce maintenance burden.Details
We have multiple smaller decision:
The text was updated successfully, but these errors were encountered: