Using draft: true causes release-pr to fail to find the previous release.

[plaflamme]

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

• OS: MacOS Monterey
• Node.js version: 14
• npm version:
• release-please version:

Steps to reproduce

1. use draft GH release
2. make a release using github-release command
3. immediately issue a release-pr command

The 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 in git; 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 with isDraft set to true.

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 additional tagName field):

query ($name: String!, $owner: String!) {
  repository(owner: $owner, name: $name) {
    releases(orderBy: {field: CREATED_AT, direction: DESC}, first: 10) {
      nodes {
        name
        isDraft
        url
        tag {
          name
        }
        tagCommit {
          oid
        }
        tagName
      }
    }
  }
}

We obtain this:

{
  "data": {
    "repository": {
      "releases": {
        "nodes": [
          {
            "name": "v14.6.0-exists",
            "isDraft": true,
            "url": "https://github.com/plaflamme/release-please/releases/tag/untagged-1343daf7aae1ed4c3da5",
            "tag": {
              "name": "v14.6.0"
            },
            "tagCommit": {
              "oid": "faaf56cc557cbcfdbb881efe81e1da8e22441d31"
            },
            "tagName": "v14.6.0"
          },
          {
            "name": "v14.6.1-lazy",
            "isDraft": true,
            "url": "https://github.com/plaflamme/release-please/releases/tag/untagged-dd0aaa72f95f1a467bbe",
            "tag": null,
            "tagCommit": null,
            "tagName": "v14.6.1"
          }
        ]
      }
    }
  }
}

As you can see the tag and tagCommit 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 and tag fields; but an alternate approach would be to make the github-release command actually create the tag in git and avoid these "lazy" releases altogether. This second approach seems more correct since the github-release command did indeed create the release and the repository should be tagged accordingly.

Any thoughts on what the fix should be here?

[chingor13]

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.

[cdata]

😩 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).

[cdata]

@plaflamme I think you're right; the tag should be created even if the release is marked as a draft.

[plaflamme]

@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)?

[XeroxDev]

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!)