clayburn commented on code in PR #29480:
URL: https://github.com/apache/beam/pull/29480#discussion_r1402703296
##########
.github/workflows/java_tests.yml:
##########
@@ -89,7 +89,7 @@ jobs:
run: rm ~/.m2/settings.xml
# :sdks:java:core:test
- name: Run :sdks:java:core:test
- uses: ./.github/actions/gradle-command-action
+ uses: gradle/gradle-build-action@v2
Review Comment:
> With that said, is there any advantage of using this instead of the
current composite workflow with gradle-command-self-hosted-action? I like that
because (a) it gives us a single place to apply some arguments we always want
on in CI, (b) we can do any other setup there like removing settings.xml, and
(c) its what the rest of our workflows are already standardized on
Thanks for this feedback. I didn't realize this is really the only place
that `gradle-build-action` is called directly. I was going for minimal change,
but I'll edit the PR to use `gradle-command-self-hosted-action`. We could even
have the composite workflow use `gradle-build-action` to benefit from the job
summaries. It may even help with making some of the cache credential secrets
parameters to the workflow so they aren't accidentally omitted.
I'll update the PR to use the composite workflow and explore the rest
separately. It'll likely be next week with the upcoming holiday.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
