Ignore backport / autocut / dependabot branches for gradle checks on push

[peterzhuamazon]

Signed-off-by: Peter Zhu [email protected]

Description

Ignore backport / autocut / dependentbot branches for gradle checks.
These branches come and go and are not long-lived, thus no reason to even run gradle check on push.
They can run gradle check on pull_request_target event.

Issues Resolved

opensearch-project/opensearch-build#851

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

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.

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/293/
• CommitID: 07f51a3

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/298/
• CommitID: 07f51a3

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/302/
• CommitID: 07f51a3

[andrross]

This looks good to me, but I have a related question...

We run the gradle check workflow when a PR is created against one of the mainstream branches, but we also run the check again when the merge is made? Is that right?

[peterzhuamazon]

This looks good to me, but I have a related question...

We run the gradle check workflow when a PR is created against one of the mainstream branches, but we also run the check again when the merge is made? Is that right?

Hi @andrross,

Exactly.

1. PR created/updated/reopened will trigger gradle check against the HEAD commit as part of pull_request_target event.
2. PR merged will trigger gradle check against the branch merged to as part of push event.

That is the point of this change so backport/depandabot/autocut will still trigger 1 and 2, while ignore the trigger towards those temp branches used to just create the PR.

Thanks.

[andrross]

Thanks @peterzhuamazon!

PR merged will trigger gradle check against the branch merged to as part of push event.

I know this is a bit off topic, but I'm curious about exactly how this works. Does it happen before or after the push? What happens if it fails? If there's any documentation please let me know and I can RTFM :)

[github-actions]

Gradle Check (Jenkins) Run Completed with:

• RESULT: FAILURE ❌
• URL: https://build.ci.opensearch.org/job/gradle-check/323/
• CommitID: 07f51a3

[peterzhuamazon]

Thanks @peterzhuamazon!

PR merged will trigger gradle check against the branch merged to as part of push event.

I know this is a bit off topic, but I'm curious about exactly how this works. Does it happen before or after the push? What happens if it fails? If there's any documentation please let me know and I can RTFM :)

Hi @andrross,

if people creating a PR from their fork, due to the branch used to open PR is on fork, only PR event trigger gradle check, push wont.
Once PR merged due to the branch they merge to have a push happens, push event trigger.

if people creating a PR with a branch directly in this repo (aka dependabot, backport), due to those branches are created fresh, their 1st creation is considered a fresh push, thus trigger push. And since they also have PR thus trigger PR event. This means 2 gradle check and the push one is unnecessary.

There is literally a workflow in this repo to remove backport branches periodically therefore no need to even run those push events on these backport/dependabot branches.

Thanks.

[andrross]

I'm curious about the gradle check workflow that happens upon merge into main once the PR is approved. I see that the gradle check failed for the workflow that ran after this PR was merged. How are these failures supposed to be handled? In this case it seems to be an existing flaky test (#3579) but if it was a problem caused by the merge is there any mechanism to handle it?