Reuse existing pull request in increment plugin workflow

[peternied]

Description

Not all plugins can immediately merge changes from this workflow and need to add changes before the generated pull request can be merged. This update prevents that existing branch from being overridden if the job is re-run while we wait for health builds.

Aspiring issue: opensearch-project/security#2210 (comment)

Issues Resolved

• Related [AUTO] Increment version to 2.5.0-SNAPSHOT security#2210

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.

[peternied]

FYI @DarshitChanpura

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.72%. Comparing base (970646d) to head (55260c5).
⚠️ Report is 2158 commits behind head on main.

❌ Your project status has failed because the head coverage (93.72%) is below the target coverage (98.00%). You can increase the head coverage or adjust the target coverage.

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #2874      +/-   ##
============================================
- Coverage     93.80%   93.72%   -0.08%     
============================================
  Files           213      158      -55     
  Lines          4389     4401      +12     
  Branches         10        0      -10     
============================================
+ Hits           4117     4125       +8     
- Misses          266      276      +10     
+ Partials          6        0       -6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[peternied]

@prudhvigodithi Anything else you'd like to see in this pull request?

[prudhvigodithi]

Hey @peternied thanks, just got pulled out of this, one qq did you test with this change in your local fork, that it creates a PR with version increment and then does not override the changes (made while the a PR is open) upon re-push (with workflow re run) ?

[peternied]

I did not test it, is there documentation for how to do that?

[prudhvigodithi]

I did not test it, is there documentation for how to do that?

Hey @peternied
I mean just the GH workflow test on your fork repo, example something like this prudhvigodithi/job-scheduler#2

[DarshitChanpura]

I sense that this scenario will only come into play when an auto-cut PR branch for version increment is deleted and the bot attempts to looks for it. Am I correct?

[prudhvigodithi]

I sense that this scenario will only come into play when an auto-cut PR branch for version increment is deleted and the bot attempts to looks for it. Am I correct?

Hey @DarshitChanpura this is moreover related to retain the changes pushed to the version increment branch, so if a PR is open for a version increment and a user pushes some new changes, the AUTO version increment should retain those changes and not override the changes pushed by the user. @peternied please add if i'm missing anything.
@gaiksaya @peterzhuamazon @bbarani @zelinh
Thank you

[DarshitChanpura]

Hey @DarshitChanpura this is moreover related to retain the changes pushed to the version increment branch, so if a PR is open for a version increment and a user pushes some new changes, the AUTO version increment should retain those changes and not override the changes pushed by the user. @peternied please add if i'm missing anything. @gaiksaya @peterzhuamazon @bbarani @zelinh Thank you

Ahh.. got it.. thank you @prudhvigodithi !

[peternied]

I did not test it, is there documentation for how to do that?

Hey @peternied I mean just the GH workflow test on your fork repo, example something like this prudhvigodithi/job-scheduler#2

@prudhvigodithi I'm not sure how to setup the secrets in my forked repository, can you help me figure out how to generate the APP_ID?

[prudhvigodithi]

Hey @peternied thanks for waiting just getting back on this, you can generate your own app and use that and should work as you are testing on your forked repo, another way is to use the API Token by adding it to the secrets, this should be easy for testing with only change on the line as follows (token: ${{ secrets.PAT }})

        with:
          token: ${{ secrets.PAT }}
          committer: opensearch-ci-bot <opensearch-infra@amazon.com>
          author: opensearch-ci-bot <opensearch-infra@amazon.com>
          commit-message: |
            Increment version to ${{ env.OPENSEARCH_VERSION }}
            Signed-off-by: opensearch-ci-bot <opensearch-infra@amazon.com>
          delete-branch: true
          branch: create-pull-request/${{ env.OPENSEARCH_VERSION }}
          title: '[AUTO] Increment version to ${{ env.OPENSEARCH_VERSION }}'
          body: |
            - Incremented version to **${{ env.OPENSEARCH_VERSION }}**.

[peternied]

@prudhvigodithi After playing around with this workflow I tested it, and it didn't work because that isn't how the create PR workflow is built. I'm going to abandon this, maybe someone else can look into it at a future point in time