-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rewrite version update GHA to commit and push #7442
Rewrite version update GHA to commit and push #7442
Conversation
This change alters the version workflow to create a new issue, then create several commits linked back to that issue and finally close the issue when all commits are completed for tracability of version updates. Background As version updates have different propigation speeds depending on pull request reviews, consistant CI in many branches, and an careful order of execution this would cause failures outside the scope of changes that would block changes into main and other branches. This change removes the use of pull requests and the standard ci gates. To ensure that the changes operate consistantly created a GitHub Action to manage the file modification peternied/opensearch-core-version-updater See an example of this workflows results with #66 Related issues - Resolves opensearch-project#7411 - Related Discussion opensearch-project#7398 - Resolves opensearch-project#7396 Signed-off-by: Peter Nied <petern@amazon.com>
Gradle Check (Jenkins) Run Completed with:
|
@kotwanikunal @reta @dblock @saratvemulapalli @bbarani do you have recommendations for those that would be good to seek feedback for this change to directly push to the repository? |
I like this idea of (meta) issue + per affected branch pull request. The direct push is also an option, the drawback I see that if push for some branches failed (as you noticed, Github could be very unstable for a long time), the failure won't be noticed. With meta issue + pull requests it is easier to spot the problem, just my opinion. Thanks @peternied for taking care of this. |
I am a bit wary of a direct push because it hides the change from humans, but maybe I'm just exercising my right to FUD? It means making a code change and not passing CI. Technically, are there any branch protection rules that would prevent us from doing it? Can this script be rerun on failure half way? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you @peternied !
repo: context.repo.repo, | ||
issue_number: "${{steps.create-issue.outputs.result}}", | ||
state: "closed" | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: new line
- name: Create Pull Request | ||
uses: peter-evans/create-pull-request@v3 | ||
- name: Increment Patch Version on Major.Minor branch | ||
uses: peternied/opensearch-core-version-updater@main |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this script be rerun on failure half way?
I haven't checked in on failure cases that would be re-runnable. I feel this would be important to cover before getting this merged. When I get a chance to circle back this seems like the most important area of focus to prevent any hiccups from jamming up the build and resorting to direct pushes against main.
This PR is stalled because it has been open for 30 days with no activity. Remove stalled label or comment or this will be closed in 7 days. |
This PR was closed because it has been stalled for 7 days with no activity. |
Description
This change alters the version workflow to create a new issue, then create several commits linked back to that issue and finally close the issue when all commits have been pushed for traceability of version updates.
Background
As version updates have different propagation speeds depending on pull request reviews, consistent CI in many branches, and an careful order of execution this would cause failures outside the scope of changes that would block changes into main and other branches.
This change removes the use of pull requests and the standard ci gates. To ensure that the changes operate consistently created a GitHub Action to manage the file modification peternied/opensearch-core-version-updater
See an example of this workflows results with peternied#66
Related issues
Open Items to leave draft
Check List
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.