Multiple Draft Releases Created when >100 Releases Exist in GitHub

[rwaskiewicz]

Overview

I have project(s) that use v2.2.1 of this action in the following manner:

• draft release input is enabled (draft: true)
• we multiple usages of this action in a workflow

Some of these projects have greater than 100 releases in GitHub.

I've found that in these circumstances, running the a workflow with multiple instances of this action will result in multiple draft releases being created, rather than one (which is the behavior for the first 100 releases).

Steps to Reproduce

Prerequisites:

1. A repository with 100 GitHub releases.
   I've created https://github.com/rwaskiewicz/action-gh-release-repro for this purpose.
   This repository has been 'primed' to have 101 releases to demonstrate the issue.
2. A workflow that uses the action-gh-release action multiple times with the draft: true input.
   This is included in .github/workflows/main.yml in the above repository.

Steps to Reproduce:

1. Run the main.yml workflow in this repository.
   This is more difficult than it should be, as a fork of the repo won't have the releases that are in the original (if I understand correctly).
   This is why I 'primed the pump' so to speak - so we could just look at logs (below)
2. On the 101st run of the workflow, the action-gh-release action will create a new release entity for each usage of the action, rather than one draft release.

Real world example using that repo:

The 212th run of the workflow in this repository created the 100th release entity in the repository:

• Logs from the workflow: https://github.com/rwaskiewicz/action-gh-release-repro/actions/runs/14272880833
• Release Entity: https://github.com/rwaskiewicz/action-gh-release-repro/releases/tag/212

The 213th run of the workflow in this repository created the 2 draft release entities in the repository:

• Logs from the workflow: https://github.com/rwaskiewicz/action-gh-release-repro/actions/runs/14272890579
• Release Entity 1: https://github.com/rwaskiewicz/action-gh-release-repro/releases/tag/untagged-ba4721d8b12f6bbd9e7c
• Release Entity 2: https://github.com/rwaskiewicz/action-gh-release-repro/releases/tag/untagged-534d93ef9215159ec0a3

Note how in the logs of the 212th run, the action-gh-release action created a single release entity.
It was able to find the existing release entity in the "Upload World File to Release step":

Run softprops/action-gh-release@c95fe1489396fe8a9eb87c0abf8aa5b2ef267fda

Found release 212 (with id=210448811)

However, in the 213th run, the action-gh-release action created 2 release entities.
It was not able to find the existing release entity in the "Upload World File to Release step":

Run softprops/action-gh-release@c95fe1489396fe8a9eb87c0abf8aa5b2ef267fda

👩‍🏭 Creating new GitHub release for tag 213...

Root Cause Analysis

I believe this code is the reason for the failure:

      for await (const response of releaser.allReleases({
        owner,
        repo,
      })) {
        _release = response.data.find((release) => release.tag_name === tag);
      }

When there are 101+ releases in GitHub we may accidentally overwrite a detected release.
As a concrete example, let's say there are 150 releases in GitHub.
There will be 2 pull of releases:

• 1 batch will contain 100 releases
• 1 batch will contain the remaining 50

I believe what's happening is that GitHub may return the release we want in batch 1, and we assign that to _release correctly. However, we still fetch the second batch of releases, and when we call find(), it returns undefined and we end up assigning _release = undefined

[rwaskiewicz]

My PR now (#603) mostly exists for tests ATM. A fix for the issue I'm seeing was merged in under 36833a1 (#316). I'm going to close this since the issue itself was fixed, but keep the PR open to see if the maintainers are interested in the tests I added.