Attempt to fix Github workflow for Gradle Check job

[reta]

Signed-off-by: Andriy Redko andriy.redko@aiven.io

Description

Attempt to fix Github workflow for Gradle Check job

Issues Resolved

N/A

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff
• Commit changes are listed out in CHANGELOG.md file (See: Changelog)

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[reta]

@saratvemulapalli fyi

[saratvemulapalli]

@saratvemulapalli fyi

Thanks @reta, I just started debugging and you are ⚡ fast!

[reta]

@saratvemulapalli fyi

Thanks @reta, I just started debugging and you are zap fast!

Hope it fixes the issue, no way to verify before the commit :(

[saratvemulapalli]

I think it would. Atleast from looking at stackoverflow[1]
Lets see 🤞🏻

[1] https://stackoverflow.com/questions/62750603/github-actions-trigger-another-action-after-one-action-is-completed

[reta]

@saratvemulapalli let's give it a try? need your approval please

[saratvemulapalli]

Looks like its not kicking off the workflow.

[saratvemulapalli]

@saratvemulapalli let's give it a try? need your approval please

Do you want to get this changed merged, I see no harm.

[reta]

Looks like its not kicking off the workflow.

It won't unless merged :(

[saratvemulapalli]

Looks like its not kicking off the workflow.

It won't unless merged :(

Unfortunately this was merged #4677.
I will rebase changes on my PR #4676 lets see how it goes.

[dbwiddis]

Hey @reta and @saratvemulapalli,

I tried to implement this functionality over on SDK and in the process learned more about it. I'm not sure this is behaving as expected.

• by including more options than just workflow_run it's running anyway so we aren't gaining any benefit from the workflow_run
• by removing the check for success it's running anyway even if precommit fails

Further even if we got it working, my experience on SDK is that:

• the run doesn't show up in the PR checks so it may look like everything is passing until the check comes back with a comment. (You can validate this by looking in the "Actions" pane and seeing quite a few gradle checks running without being attached to a PR.

@owaiskazi19 figured out that GHA has a needs keyword where you can keep all the same workflows in the same yml file and have them depend on each other internally. see opensearch-project/opensearch-sdk-java#198

I think we can rework this to remove the precommit from its separate GHA, and run it in a separate job here.

[kotwanikunal]

Hey @reta and @saratvemulapalli,

I tried to implement this functionality over on SDK and in the process learned more about it. I'm not sure this is behaving as expected.

• by including more options than just workflow_run it's running anyway so we aren't gaining any benefit from the workflow_run
• by removing the check for success it's running anyway even if precommit fails

Further even if we got it working, my experience on SDK is that:

• the run doesn't show up in the PR checks so it may look like everything is passing until the check comes back with a comment. (You can validate this by looking in the "Actions" pane and seeing quite a few gradle checks running without being attached to a PR.

@owaiskazi19 figured out that GHA has a needs keyword where you can keep all the same workflows in the same yml file and have them depend on each other internally. see opensearch-project/opensearch-sdk-java#198

I think we can rework this to remove the precommit from its separate GHA, and run it in a separate job here.

I was just looking into this for changelog verification.

by removing the check for success it's running anyway even if precommit fails

You can still run based on status using if: ${{ github.event.workflow_run.conclusion == 'success' }} Ref: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#running-a-workflow-based-on-the-conclusion-of-another-workflow

The only issue that I see with this is Note: This event will only trigger a workflow run if the workflow file is on the default branch. mentioned here - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run

@reta Given that our use case spans across branches, I think this will not work as expected for backport PRs/branches.

Also, cc @andrross since he brought this issue up for changelog verification.

[reta]

The only issue that I see with this is Note: This event will only trigger a workflow run if the workflow file is on the default branch. mentioned here - https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run

Thanks for finding this out, @kotwanikunal , I think for our model this is a severe limitation.