Conversation
These were missed in the period that branch protection prevented the workflow from copying allowlists from the dummy workflow to `actions.yml`. (apache#689 added them to `approved_patterns.yml`, but once the automated jobs were running again they were removed again because they didn't show up in `actions.yml`)
erisu
left a comment
erisu
left a comment
There was a problem hiding this comment.
It appears that the new tag version for erisu/license-checker-action has been written incorrectly.
Co-authored-by: エリス <erisu@users.noreply.github.com> Signed-off-by: Jarek Potiuk <jarek@potiuk.com>
| tag: v2.4 | ||
| expires_at: 2026-07-05 | ||
| 363572b2714d25a059fceb2fa332a98e7ea3baff: | ||
| tag: v2.4 |
There was a problem hiding this comment.
Ah - I missed that @raboof modified the dummy-workflow.yml.
So I copied the output from the last failed "Handle Dependabot Upgrade" https://github.com/apache/infrastructure-actions/actions/runs/24309558948/job/70976723553
The "actions.yml" and "approved-actions.yml" files are generated automatically from dependabot.yml -> this is why I have not generated it in the first place (so @raboof @dave2wave.
So really this one here was not "missing entries" - the updates were just not pushed by the "Handle Dependabot Update" workflow - because we did not have branch protection removed yet) - until
In #689 I only added "approved actions" to unblock people but I wanted to let the "Handle Dependabot Upgrade" do the job and update "actions.yml" automatically - yes, it was lazy likely.
There was a problem hiding this comment.
In #689 I only added "approved actions" to unblock people but I wanted to let the "Handle Dependabot Upgrade" do the job and update "actions.yml" automatically - yes, it was lazy likely.
Not sure if 'lazy' is the word, you were quite correct that ideally actions.yml would have been automatically updated based on dummy.yml - but since that wasn't triggered back when branch protection was still enabled I figured I'd 'help it along' with this PR.
### What changes were proposed in this pull request? This PR adds `gradle/actions/setup-gradle` to GitHub Actions workflows (`build_and_test.yml`, `publish_snapshot_chart.yml`) and removes the `cache: 'gradle'` option from `actions/setup-java` and `Java Tool Chain caching` step since `setup-gradle` handles Gradle caching. ### Why are the changes needed? The `gradle/actions/setup-gradle` action is the officially recommended way to set up Gradle in GitHub Actions, offering several advantages over the `cache: 'gradle'` option in `actions/setup-java`: - actions/setup-java#588 - apache/infrastructure-actions#681 - apache/infrastructure-actions#696 Advantages: - **More efficient caching**: Provides more sophisticated and optimized caching of Gradle User Home between invocations, with detailed reporting of cache usage and configuration options. - **Dependency Graph support**: Can generate and submit a GitHub Dependency Graph for the project, enabling Dependabot security alerts. - **Build Scan link capture**: Automatically captures Build Scan links from the build, making them easier to locate in workflow runs. - **Separation of concerns**: `actions/setup-java` is a general-purpose Java setup tool. Delegating Gradle-specific setup to the dedicated first-party action avoids sub-optimal caching strategies (`actions/setup-java#588`). ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? CI should pass with the updated workflows. ### Was this patch authored or co-authored using generative AI tooling? Generated-by: Claude Code (claude-opus-4-6) Closes #621 from dongjoon-hyun/SPARK-56401. Authored-by: Dongjoon Hyun <dongjoon@apache.org> Signed-off-by: Dongjoon Hyun <dongjoon@apache.org>
4 participants
These were missed in the period that branch protection prevented the workflow from copying allowlists from the dummy workflow to
actions.yml.(#689 added them to
approved_patterns.yml, but once the automated jobs were running again they were removed again because they didn't show up inactions.yml)