-
-
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
Generate GitHub Actions CI Jobs automatically #2520
Conversation
d04e514
to
e645c2c
Compare
|
||
generate_preface | ||
generate_job compile "build -x test" | ||
generate_job core "testcontainers:check" compile |
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.
I wonder if shared compile
(1 busy worker) actually helps. Have you done some measurements yet?
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.
It does not, so I removed it 😄
Indicative timings: A fully cached (S3 remote build cache) build: 6m25s A completely uncached build (with For the uncached build, the longest job, and therefore bottleneck is Therefore I think we could reduce the max build time to ~14mins by splitting up the JDBC testing for each DB into the relevant modules, to take advantage of parallelisation. Further performance gains could be possible by splitting up the |
e3ca0bc
to
12bb3bd
Compare
Co-Authored-By: Richard North <rich.north@gmail.com>
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.
The up-to-date awareness makes this vastly better!
Let's 🚢 !
Co-Authored-By: Richard North <rich.north@gmail.com>
Co-Authored-By: Sergei Egorov <bsideup@gmail.com> Co-Authored-By: Richard North <rich.north@gmail.com>
Generate GitHub Actions CI jobs for modules
Refs #2177, #1836
PR 1 of 2: this PR includes a script for generating the CI job configuration, but the script has to be manually run
A future PR should run the generation script automatically as a separate Action and commit changes, so that no manual updates are needed