Open plaflamme opened 1 year ago
Sorry, I don't have a good idea on a fix for this right now. This draft feature was community contributed and this needs a design for how to handle it.
:weary: ran into this one while working on a fix for #1896 . This used to work in our flow; a draft release would be created and somehow detected by release-please
. Now the draft release is not considered a release by release-please
, so when we merge a release PR we immediately get a new PR containing a proposed release for the packaged set to draft (and that proposed release PR seems to consider the entire history when determining the changelog for those packages).
@plaflamme I think you're right; the tag should be created even if the release is marked as a draft.
@cdata yes, I believe that would be the best way forward and likely the simplest. I believe it would not affect the non-draft flow as well, but that's a little difficult to know for sure without testing.
@chingor13 do you think it would be acceptable for the tag to be created by release-please
instead of GH in both cases (draft: true
and draft: false
)?
I know this issue is a bit older, but is there any update on this?
I'm kinda new to release-please and implemented it into an existing project with draft: true.
I had a huge release (breaking changes) from v1.x to v2.0.0 and I'm adding the artifact after bumping and changelog generation (I've to build it manually and that's why I use draft: true)
After the release PR was merged, the action (I'm using the action) started again, triggered release-please and created another release PR with v3.0.0
The most important things in the logs are:
‼ Found release tag with component 'v1', but not configured in manifest
‼ Expected 1 releases, only found 0
‼ Missing 1 paths: .
> looking for tagName: v2.0.0
‼ Expected 1 releases, only found 0
√ Collecting commits since all latest releases
> commit search depth: 500
> Set(0) {}
> Fetching merge commits on branch master with cursor: undefined
(Many "Backfilling" lines)
...
√ Splitting 161 commits by path
√ No latest release found for path: ., component: , but a previous version (2.0.0) was specified in the manifest.
√ Building candidate release pull request for path: .
> type: node
> targetBranch: master
‼ No latest release pull request found.
> commits: 97
√ Considering: 97 commits
> component:
> pull request title pattern: undefined
> Fetching package.json from branch master
√ Looking for open release pull requests
√ found 0 open release pull requests.
√ Looking for snoozed release pull requests
√ found 0 snoozed release pull requests.
> Fetching package-lock.json from branch master
‼ file package-lock.json did not exist
> Fetching npm-shrinkwrap.json from branch master
‼ file npm-shrinkwrap.json did not exist
> Fetching samples/package.json from branch master
‼ file samples/package.json did not exist
> Fetching CHANGELOG.md from branch master
> Fetching package.json from branch master
√ updating from 2.0.0 to 3.0.0
> Fetching changelog.json from branch master
‼ file changelog.json did not exist
> Fetching src/version.ts from branch master
> Fetching .github/ISSUE_TEMPLATE/BUG-REPORT.yml from branch master
‼ No entries modified in $.version
> Fetching manifest.json from branch master
> Fetching .release-please-manifest.json from branch master
√ Starting GitHub PR workflow...
and the changelog for v3.0.0 was EVERYTHING ever committed (instead of skipping it completely).
Or is there at least a workaround (which still involves draft: true)?
(And still thanks for this awesome tool! This makes everything so much easier!)
1) Is this a client library issue or a product issue?
Product issue
2) Did someone already solve this?
Not that I'm aware.
3) Do you have a support contract?
No
Environment details
release-please
version:Steps to reproduce
draft
GH releasegithub-release
commandrelease-pr
commandThe
release-pr
will fail to find the drafted release and will immediately create a new "release PR".From my investigation, this is due to the fact that "draft" GH releases are able to lazily create tags. Which is to say that when you create a draft GH release, you can specify the tag name and
ref
, but those are not yet materialized ingit
; instead, they are only created when the release is published. That said, "draft" GH releases can also point at existing tags and will "look" like any other GH release except withisDraft
set totrue
.For example, in my fork for this repo, I created 2 releases. One pointing at an existing tag (
v14.6.0-exists
) and another that will lazily create the tag (v14.6.1-lazy
).Now, if we issue the following GraphQL query (which is used by
release-please
here, except for the additionaltagName
field):We obtain this:
As you can see the
tag
andtagCommit
values are missing for the "lazy" draft release. NOTE: you will not be able to reproduce this on my fork since "draft" releases are private.This causes the iterator defined here to skip this release and makes
release-pr
fail to find the "previous" release.Now the question is what should be the fix? Initially, I thought about removing the filter and properly handle the missing
tagCommit
andtag
fields; but an alternate approach would be to make thegithub-release
command actually create thetag
ingit
and avoid these "lazy" releases altogether. This second approach seems more correct since thegithub-release
command did indeed create the release and the repository should be tagged accordingly.Any thoughts on what the fix should be here?