Add github action to prepare stable release #24697

unidevel · 2025-03-10T13:57:56Z

Description

The document of stable release process can be found in https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months)

Prior to the coming release, there were 5 steps:

By the suggestion from @ethanyzhang, will merge the steps into 2 github actions:

Action 1 - "Presto Stable Release - Prepare"

Parameters

Action 2 -"Presto Stable Release - Publish"

In the PR #24821

Motivation and Context

Impact

Presto stable release

Test Plan

Tested with my env
- Prepare => https://github.com/unix280/presto/actions/runs/13843832419
Test with new release 0.292 after merged

Contributor checklist

Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
Documented new properties (with its default value), SQL syntax, functions, or other functionality.
If release notes are required, they follow the release notes guidelines.
Adequate tests were added if applicable.
CI passed.

Release Notes

== NO RELEASE NOTE ==

czentgr

Nice job automating this! A few questions.

.github/workflows/presto-release-prepare.yml

.github/workflows/presto-release-publish.yml

.github/workflows/presto-release-prepare.yml

czentgr · 2025-03-17T19:25:43Z

.github/workflows/presto-release-prepare.yml

+          git push origin release-${{ env.PRESTO_RELEASE_VERSION }} --tags
+          echo "Pusing master branch"
+          git log --pretty="format:%ce: %s" -5
+          git checkout master


Why do we need to checkout the master branch and push it?
We pushed the new release branch above but why do we need to do this. It doesn't look like this changes anything.

Why do we need to checkout the master branch and push it? We pushed the new release branch above but why do we need to do this. It doesn't look like this changes anything.

Because mvn release:prepare will create 2 commits on master branch like below and also a tag for each release

2025-01-27 943868a918 (oss-release-bot): [maven-release-plugin] prepare for next development iteration 2025-01-27 3374f1b274 (oss-release-bot): [maven-release-plugin] prepare release 0.291 <tag: 0.291>

Next we will create a release branch based on the tag for the next publish action

To make it easy to revert, I will first push the release branch and tag, then push the master branch.

In case anything failed during release, we just need to delete the branch and tag without reverting any commits on master branch.

My opinion is to stick with maven as much as possible, even it means to revert master branch.

My opinion is to stick with maven as much as possible, even it means to revert master branch.

@wanglinsong I think in most of the cases, it should be fine with both pushing order since they all do the same thing - pushing the release branch & tag, and commits to master branch. For the failed cases, let me explain it in detail.

With the order as you suggested ( push the master branch & tag, then the release branch):

When failed to push to the master branch, just delete the tag and re-run the job

When successfully pushed to master but failed to push the release tag, need reset master branch to remove the commits, then re-run the failed job

When failed to push the release branch, need reset master branch to remove the commits, delete the tag and try again.

With the order I used( push the release branch & tag, then master branch)

When push to release branch & tag failed, just delete the branch & tag(if exists), and re-run the job

When push to master failed, just delete the release branch & tag(since they are newly created, no one is working on it)

Because reset the commits on master branch will have impact on the open PRs which has greater risk than delete the newly created branch and tag, that why I think it's better to keep the pushing order in my PR.

Thanks for explaining. I agree that we wouldn't want to reset the master branch if we can avoid it.

Do we need to generally worry about race conditions if a committer merges a PR while the running. I suspect in that case we would fail the push to master because the master branch base is different and it can't push the maven commits.

Do we need to generally worry about race conditions if a committer merges a PR while the running. I suspect in that case we would fail the push to master because the master branch base is different and it can't push the maven commits.

Because there is a special settings to let the user prestodb-ci by pass the PR rules, this user can push commits directly on master branch. Also about the race conditions, I think it follows the git pushing rules, the worse case is that some PRs merged during the action, which will cause it failed to push the commits to master branch. In this case, we can delete the branch and tag, then try the action again without any impact on all the open PRs.

My opinion is to stick with maven as much as possible, even it means to revert master branch.

@wanglinsong I think in most of the cases, it should be fine with both pushing order since they all do the same thing - pushing the release branch & tag, and commits to master branch. For the failed cases, let me explain it in detail.

With the order as you suggested ( push the master branch & tag, then the release branch):

When failed to push to the master branch, just delete the tag and re-run the job

When successfully pushed to master but failed to push the release tag, need reset master branch to remove the commits, then re-run the failed job

When failed to push the release branch, need reset master branch to remove the commits, delete the tag and try again.

With the order I used( push the release branch & tag, then master branch)

When push to release branch & tag failed, just delete the branch & tag(if exists), and re-run the job

When push to master failed, just delete the release branch & tag(since they are newly created, no one is working on it)

Because reset the commits on master branch will have impact on the open PRs which has greater risk than delete the newly created branch and tag, that why I think it's better to keep the pushing order in my PR.

This is no reason of failing to push the release branch, which is a new branch, no any conflicts possible at all.

This is no reason of failing to push the release branch, which is a new branch, no any conflicts possible at all.±

Yes, but if the release needs to be reverted for some reason, the release branch and tag might be forgotten to be deleted.

.github/workflows/presto-release-prepare.yml

czentgr

Only one nit.

czentgr · 2025-03-18T23:55:25Z

.github/workflows/presto-release-prepare.yml

+          git push origin release-${{ env.PRESTO_RELEASE_VERSION }} --tags
+          echo "Pusing master branch"
+          git log --pretty="format:%ce: %s" -5
+          git checkout master


Thanks for explaining. I agree that we wouldn't want to reset the master branch if we can avoid it.

Do we need to generally worry about race conditions if a committer merges a PR while the running. I suspect in that case we would fail the push to master because the master branch base is different and it can't push the maven commits.

czentgr · 2025-03-18T23:56:36Z

.github/workflows/presto-release-prepare.yml

+          echo "Pushing release branch release-${{ env.PRESTO_RELEASE_VERSION }} and tag ${{ env.PRESTO_RELEASE_VERSION }}"
+
+          echo "commits on release-${{ env.PRESTO_RELEASE_VERSION }} branch"
+          git ls -4


Nit: for consistence use 5 here? Before and after this 5 is used.

@czentgr The reason the number changes between 4 and 5 is that I want to keep the logs containing the last 3 commits that were not generated by the Maven release plugin

Take 0.291 for example, in the branch release-0.291 and tag 0.291, the command git ls -4 will display the 4 commits as follows:

In the master branch, the comand git ls -5 will display the last 5 commits, which has the same 3 commits in the release branch

But it's also fine to keep 5 commits in both situations. We only use the logs to verify that the release branch was created correctly.

unidevel · 2025-03-26T16:59:27Z

Thanks. As for the presentation you had it helps to document what to do if aspects of the pipeline fail. Will this be added to the documentation in the wiki for prestodb? Maybe add this to the description of the PR where to find that documentation in case someone looks in the PR?

Let me know if I can help with any documentation needs!

@steveburnett I'll update the document to https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months) , I'll let you know after it is updated, thanks

unidevel · 2025-03-26T17:23:54Z

@steveburnett I added the document of this new release process to https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months)#for-release-after-0291 under section Release after 0.291, please help to review, thanks.

steveburnett · 2025-03-26T21:21:44Z

@steveburnett I added the document of this new release process to https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months)#for-release-after-0291 under section Release after 0.291, please help to review, thanks.

Looks good, thanks! I have some minor edits to suggest - punctuation and similar nits, nothing affecting the meaning or the sequence of events. Would you like me to tell you these nits, or would you like me to just edit the wiki page myself? I can work either way but I think the second option is faster and simpler.

unidevel · 2025-03-27T10:08:29Z

@steveburnett I added the document of this new release process to https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months)#for-release-after-0291 under section Release after 0.291, please help to review, thanks.

Looks good, thanks! I have some minor edits to suggest - punctuation and similar nits, nothing affecting the meaning or the sequence of events. Would you like me to tell you these nits, or would you like me to just edit the wiki page myself? I can work either way but I think the second option is faster and simpler.

Thanks, please feel free to edit the wiki.

majetideepak · 2025-03-27T10:58:22Z

.github/workflows/presto-release-publish.yml

+        default: true
+        required: false
+      dependency_image:
+        description: 'Dependency image(e.g., prestodb/presto-native-dependency:latest)'


@unidevel The latest is not up to date. Use 0.292-20250204112033-cf8ba84

@majetideepak I think this is fine, because this is only an example in description and it will not only be used for the release 0.292. Ideally we can use prestodb/presto-native-dependency:latest in future releases.

@wanglinsong I think we need either update or remove the latest tag for prestodb/presto-native-dependency docker images.

steveburnett · 2025-03-27T14:21:27Z

@steveburnett I added the document of this new release process to https://github.com/prestodb/presto/wiki/Stable-release-process-(every-2-months)#for-release-after-0291 under section Release after 0.291, please help to review, thanks.

Looks good, thanks! I have some minor edits to suggest - punctuation and similar nits, nothing affecting the meaning or the sequence of events. Would you like me to tell you these nits, or would you like me to just edit the wiki page myself? I can work either way but I think the second option is faster and simpler.

Thanks, please feel free to edit the wiki.

Done!

unidevel · 2025-03-28T08:04:28Z

per discussion with @wanglinsong , will put the publish action to a new PR.

wanglinsong

LGTM

majetideepak · 2025-03-28T09:23:52Z

@wanglinsong, @unidevel Is there any value to publicly releasing the dependency image?

unidevel · 2025-03-28T13:56:09Z

@wanglinsong, @unidevel Is there any value to publicly releasing the dependency image?

Yes, I believe there are values such as:

Accelerating the build time for docker images
Improving CI/CD jobs by making them faster
Speeding up the setup of a local dev env with docker

unidevel · 2025-03-28T13:57:38Z

BTW, I created a new PR for the publish action, this PR only have the prepare release action now.

* Combine github stable release action with add release-notes action * Update action name and messages for failure * Add publish presto release action * Add publishing docs to presto release publish action * Refactor the release actions by review comments * Fix incorrect usage of gpg passphrase * Refactor action based on review comments * Fix the cancel state of publish action * Publish dependency image to dockerhub * Fix action dependency checking * Update descriptions in the release actions * Remove presto-release-publish.yml first

prestodb-ci added the from:IBM PR from IBM label Mar 10, 2025

unidevel changed the title ~~Combine github stable release action with add release-notes action~~ [Draft] Combine github stable release action with add release-notes action Mar 10, 2025

unidevel changed the title ~~[Draft] Combine github stable release action with add release-notes action~~ [Draft] Add action to prepare stable release and generate release notes pull request Mar 12, 2025

unidevel force-pushed the add_prepare_release_action branch from de1c4dc to b4d268a Compare March 12, 2025 10:45

unidevel changed the title ~~[Draft] Add action to prepare stable release and generate release notes pull request~~ [Draft] Add action to prepare and publish presto stable release Mar 12, 2025

unidevel force-pushed the add_prepare_release_action branch 2 times, most recently from 6c6bc1e to d12bbb6 Compare March 13, 2025 20:46

unidevel changed the title ~~[Draft] Add action to prepare and publish presto stable release~~ Add github actions to prepare and publish stable release Mar 13, 2025

unidevel requested review from ethanyzhang and wanglinsong March 13, 2025 21:17

unidevel marked this pull request as ready for review March 13, 2025 21:20

unidevel requested review from a team and czentgr as code owners March 13, 2025 21:20

unidevel requested a review from jaystarshot March 13, 2025 21:20

prestodb-ci requested a review from a team March 13, 2025 21:20

czentgr reviewed Mar 13, 2025

View reviewed changes

unidevel requested a review from czentgr March 14, 2025 19:23

czentgr reviewed Mar 17, 2025

View reviewed changes

unidevel requested a review from czentgr March 18, 2025 21:21

czentgr reviewed Mar 18, 2025

View reviewed changes

unidevel requested a review from czentgr March 19, 2025 14:26

unidevel added 9 commits March 21, 2025 17:15

Combine github stable release action with add release-notes action

df0016d

Update action name and messages for failure

0ac5884

Add publish presto release action

1208fc7

Add publishing docs to presto release publish action

b765487

Refactor the release actions by review comments

7071c51

Fix incorrect usage of gpg passphrase

2e559f1

Refactor action based on review comments

48cd22d

Fix the cancel state of publish action

1af71da

Publish dependency image to dockerhub

8f65087

Update descriptions in the release actions

550a5ce

unidevel requested review from czentgr and majetideepak March 26, 2025 18:39

majetideepak reviewed Mar 27, 2025

View reviewed changes

unidevel requested a review from majetideepak March 27, 2025 18:56

Remove presto-release-publish.yml first

f9a9ded

unidevel changed the title ~~Add github actions to prepare and publish stable release~~ Add github actions to prepare stable release Mar 28, 2025

unidevel changed the title ~~Add github actions to prepare stable release~~ Add github action to prepare stable release Mar 28, 2025

wanglinsong approved these changes Mar 28, 2025

View reviewed changes

unidevel mentioned this pull request Mar 28, 2025

Add github action to publish artifacts for presto stable release #24821

Merged

6 tasks

czentgr approved these changes Mar 28, 2025

View reviewed changes

unidevel merged commit e24a101 into prestodb:master Mar 28, 2025
97 checks passed

prestodb-ci mentioned this pull request Mar 28, 2025

Add release notes for 0.292 #24825

Merged

30 tasks

unidevel mentioned this pull request Apr 25, 2025

Add release notes for 0.292 unix280/presto#23

Closed

30 tasks

This was referenced May 6, 2025

Add release notes for 0.292 unix280/presto#28

Closed

Add release notes for 0.292 unix280/presto#29

Closed

Add github action to prepare stable release #24697

Add github action to prepare stable release #24697

Uh oh!

Conversation

unidevel commented Mar 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Action 1 - "Presto Stable Release - Prepare"

Parameters

Action 2 -"Presto Stable Release - Publish"

Motivation and Context

Impact

Test Plan

Contributor checklist

Release Notes

Uh oh!

czentgr left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

czentgr left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

unidevel commented Mar 26, 2025

Uh oh!

unidevel commented Mar 26, 2025

Uh oh!

steveburnett commented Mar 26, 2025

Uh oh!

unidevel commented Mar 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steveburnett commented Mar 27, 2025

Uh oh!

unidevel commented Mar 28, 2025

Uh oh!

wanglinsong left a comment

Choose a reason for hiding this comment

Uh oh!

majetideepak commented Mar 28, 2025

Uh oh!

unidevel commented Mar 28, 2025

Uh oh!

unidevel commented Mar 28, 2025

Uh oh!

Uh oh!

Reviewers

unidevel commented Mar 10, 2025 •

edited

Loading