-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Dynamic CI jobs for examples #2677
Conversation
.github/workflows/ci-dind.yml
Outdated
@@ -1,4 +1,4 @@ | |||
name: in-container | |||
name: CI-DinD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we're not running "Docker-in-Docker", but mount the socket, hence "in-container" :) Maybe we can use "wormhole" or similar...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point
Co-authored-by: Sergei Egorov <bsideup@gmail.com>
@@ -13,6 +13,25 @@ buildscript { | |||
apply plugin: 'ch.myniva.s3-build-cache' | |||
apply plugin: 'com.gradle.enterprise' | |||
|
|||
rootProject.name = 'testcontainers-java' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to be sure - you just moved these lines without changing them, right? Or was it done by accident and we should probably revert it? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved deliberately; I'm not sure why but it feels right to have these elements near the top of the file, and leave the cache/buildscan related parts at the bottom.
Intended to apply our dynamic approach for GitHub Actions jobs to the examples. This includes use of the remote Gradle cache so that we only run an optimal subset of the example jobs.
Two things irk me about this PR:
Extensive duplication between
ci.yml
andci-examples.yml
. I considered trying to set up a matrix arrangement to avoid this, but I suspect it would become an even more complicated arrangement. We've probably already used up all our 'cleverness budget' with the existing dynamic job discovery. I think that on balance duplicating lots of the workflow file may be inelegant but is at least much clearer.I could not find a way to share the Gradle cache configuration between the
./settings.gradle
and./examples/settings.gradle
. Extracting this to a custom script plugin failed: even a working setup would break when--scan
was enabled, and I've not yet had the energy to investigate why.I think that, unless I've missed something very obvious, I'd like to proceed with the PR despite both of these annoyances. Happy to hear feedback to the contrary though :)