PECOBLR-1504 Update Github actions for multi module maven.#1180
PECOBLR-1504 Update Github actions for multi module maven.#1180tejassp-db wants to merge 41 commits intoPECOBLR-1121/arrow-patch/stack-5from
Conversation
Update Github action workflows to run for multi module maven projects.
tejassp-db
requested review from
gopalldb,
jayantsing-db,
jprakash-db,
madhav-db,
msrathore-db,
sreekanth-db and
vikrantpuppala
and removed request for
samikshya-db
tejassp-db
had a problem deploying
to
azure-prod
GitHub Actions
Failure
tejassp-db
had a problem deploying
to
azure-prod
GitHub Actions
Failure
tejassp-db
had a problem deploying
to
azure-prod
GitHub Actions
Failure
This reverts commit 271c406.
Streamline uber and thin release to be similar.
|
|
||
| - name: Check Unit Tests | ||
| shell: bash | ||
| run: mvn test -Dtest='!**/integration/**,!**/DatabricksDriverExamples.java,!**/ProxyTest.java,!**/LoggingTest.java,!**/SSLTest.java' |
There was a problem hiding this comment.
why are we removing all these from here?
There was a problem hiding this comment.
The exclusions from the mvn test command were redundant — they're already excluded in the maven-surefire-plugin section in jdbc-core/pom.xml (which was copied over from the original pom.xml)
| MAVEN_CENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }} | ||
| MAVEN_CENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_PASSWORD }} | ||
|
|
||
| - name: Get tag name from commit |
There was a problem hiding this comment.
It won't be triggered by new tag now?
There was a problem hiding this comment.
The new push: tags: 'v*' trigger does fire on new tags — so yes, it will still be triggered automatically. The difference is that the old workflow chained off the "Release" (uber JAR) workflow via workflow_run, meaning the thin JAR release only ran after the uber JAR release completed. Now both release workflows trigger independently on the same tag push. Since the multi-module setup builds the thin JAR from assembly-thin which depends on jdbc-core (built locally in Step 1), there's no dependency on the uber JAR release anymore — each workflow is self-contained.
There was a problem hiding this comment.
Reverted to manual trigger.
madhav-db
left a comment
madhav-db
left a comment
There was a problem hiding this comment.
Looks good, just a couple of small questions. Thanks!
| uses: actions/checkout@v4 | ||
| with: | ||
| # If manual trigger: use input tag, else use the SHA from the completed workflow run | ||
| ref: ${{ github.event_name == 'workflow_dispatch' && format('refs/tags/{0}', inputs.tag) || github.event.workflow_run.head_sha }} |
There was a problem hiding this comment.
Why did we remove this? Does github.ref point to a tag that can be selected during a manual trigger?
There was a problem hiding this comment.
I made it an automated trigger.
|
|
||
| jobs: | ||
| publish-thin: | ||
| # Only run if main JAR workflow succeeded or manual trigger |
There was a problem hiding this comment.
Since we removed this, this means that the thin jar release doesn't depend on the main jar workflow success, right? This means, it's possible that the main workflow fails, and the thin jar one succeeds, effectively publishing just a thin jar on maven without publishing the main one. Is that something we're okay with?
There was a problem hiding this comment.
Valid point, let me revert it to the earlier trigger mechanism.
There was a problem hiding this comment.
Fixed. Reverted to manual trigger.
| key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }} | ||
| restore-keys: ${{ runner.os }}-m2 | ||
|
|
||
| - name: Set up Maven Toolchains |
There was a problem hiding this comment.
This step is already done above, duplicated
There was a problem hiding this comment.
Nevermind, I see that we probably need it again. Can we abstract this? Otherwise looks good.
gopalldb
left a comment
gopalldb
left a comment
There was a problem hiding this comment.
Let's monitor this for few releases
## Description <!-- Provide a brief summary of the changes made and the issue they aim to address.--> Replace Log4j2 dependencies with the SLF4J-to-JUL bridge (slf4j-jdk14) so that the fat jar can emit SDK and Apache HTTP client logs via Java Util Logging (JUL) without requiring users to supply additional logging libraries. - Simplify JulLogger implementation to delegate directly to java.util.logging - Remove log4j-core, log4j-api, and log4j-slf4j2-impl test dependencies - Remove Log4j2 shade plugin transformers from pom.xml - Restructure docs/LOGGING.md with a fat jar vs thin jar quick-reference table, JUL configuration examples, and SLF4J/Log4j2/Logback integration guides - Simplify logging section in README.md to point to detailed docs ## Testing <!-- Describe how the changes have been tested--> - Unit tests - E2e tests ## Additional Notes to the Reviewer <!-- Share any additional context or insights that may help the reviewer understand the changes better. This could include challenges faced, limitations, or compromises made during the development process. Also, mention any areas of the code that you would like the reviewer to focus on specifically. -->
4 participants
Update Github action workflows to run for multi module maven projects.