-
Notifications
You must be signed in to change notification settings - Fork 229
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
manifest
command takes a while when the release PR is merged
#747
Comments
The logic in this function is opposite from what we do in our app implementation. In the app, we tag releases first, then try to open any new release pull requests if necessary. |
Thank you for the update. What do you refer to when you say "our app implementation"? This might be interesting to us, to find a workaround until this is solved. Also, do you have any idea why this function has this logic? |
@chingor13 do you think that switching the order of operations here: https://github.com/google-github-actions/release-please-action/blob/main/index.js#L65 Would address this issue? |
🤖 I have created a release *beep* *boop* --- ## [3.7.8](google-github-actions/release-please-action@v3.7.7...v3.7.8) (2023-04-11) ### Bug Fixes * bump release-please from 15.9.2 to 15.10.2 ([#755](https://github.com/google-github-actions/release-please-action/issues/755)) ([6730d1a](google-github-actions/release-please-action@6730d1a)) * tag releases before opening new pull requests ([#753](https://github.com/google-github-actions/release-please-action/issues/753)) ([6a803df](google-github-actions/release-please-action@6a803df)), closes [#747](https://github.com/google-github-actions/release-please-action/issues/747) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Fix works like a charm on our end! Thanks :) |
Fixing this bug broke our release process. Some of our releases need binary artifacts attached to them that take a while to build. So, we create the releases as drafts, and then set them to non-draft when the binary artifacts are ready to be attached. As of the fix in #753, we are hitting the bug described in googleapis/release-please#1650. Our releases that are marked as drafts don't have a concrete tag associated with them; then, the action immediately tries to update the release PRs and cannot find a tag associated with the draft releases it just made. The result is that we get an erroneous release PR that includes a huge swath of already-released history for the packages that were marked as drafts. |
Same here, since the new release is created as draft the action checks again the git history trying to find the new version tag (which not exists because it is a draft and hasn't been released yet) and then opens a new release pull-request with a lot of old commits as new changes u.u |
TL;DR
When the release PR is merged,
manifest
command warnsand then
which takes a while.
Expected behavior
When the release PR is merged,
Observed behavior
In
runManifest
, thecreatePullRequests
function is looking for the latest release before this is actually created bycreateReleases
. This results inneedsBootstrap
beingtrue
and 'Collecting commits since all latest releases'.Action YAML
Log output
Additional information
No response
The text was updated successfully, but these errors were encountered: