Visitar URL original
[bug] generator_generic_slsa3.yml upload-assets creates duplicate draft release · Issue #4000 · slsa-framework/slsa-github-generator · GitHub
Skip to content

[bug] generator_generic_slsa3.yml upload-assets creates duplicate draft release #4000

Open

Description

@bradh352

Describe the bug
We are using generator_generic_slsa3.yml to generate SLSA3 for the c-ares project and just had our first release using it. We generate the release and upload the tarball using softprops/action-gh-release@v2 and mark the release as a draft. We then go through the provenance and it generates another draft of the release with the same name instead of uploading it to the existing draft with the name.

I have not attempted to allow it to use a non-draft release for both steps of the process, mainly because I must come back and PGP sign the tarball that is generated and upload that signature and want to wait to turn off the draft status until that is done. So maybe this is a draft-related issue.

To Reproduce

See workflow https://github.com/c-ares/c-ares/blob/v1.34.3/.github/workflows/package.yml

Expected behavior
Expected that the generated .intoto.jsonl file be uploaded to the existing draft release.

Activity

  1. changed the title [-][bug] generator_generic_slsa3.yml upload-assets creates duplicate release[/-] [+][bug] generator_generic_slsa3.yml upload-assets creates duplicate draft release[/+] on Nov 9, 2024
  2. bradh352 commented on Nov 9, 2024

    @bradh352
    Author

    I see #1476 for go which happens to sort of discuss this issue, and points to this diff for a workaround: https://github.com/sigstore/helm-sigstore/pull/111/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R61-R90

    I'll implement that workaround until this gets resolved

  3. bradh352 commented on Nov 9, 2024

    @bradh352
    Author

    I tried to implement the same workaround, I won't know if it works until our next release ... regardless I'd think this should be resolved within the generic generator itself. c-ares/c-ares@75a382c

  4. chicks-net commented on Oct 20, 2026

    @chicks-net

    Another datapoint, with the trigger confirmed: DNSControl/dnscontrol hit this on its first dry-run using draft releases (PR, run 39435368847).

    That repo has 157 releases, which pins this squarely on the pagination bug in softprops/action-gh-release v2.2.1 (the version pinned by generator v2.1.0): the draft-mode lookup runs for await (const response of releaser.allReleases(...)) { _release = response.data.find(...) } — the found-release variable is reassigned on every page, so only the last (oldest) page's match survives. With >100 releases, the GoReleaser-created draft is on page 1, gets found, and is then overwritten by the last page — so the action falls back to creating a second draft release for the same tag. The run log shows Creating new GitHub release for tag v5.5.99-rc1... even though the draft existed, and the release page ends up with two v5.5.99-rc1 drafts — one with all assets, one holding only multiple.intoto.jsonl.

    The repo where we originally validated the pattern has only 45 releases (single page), so the buggy path never fired there — the bug is invisible until a repo crosses 100 releases, which matches the c-ares report timing (a long-lived repo adopting the generator).

    Two notes that might help a fix:

    • Newer softprops releases have this fixed: the latest (v3.0.3) accumulates matches across pages (matches.push(...)), disambiguates with a pickCanonicalRelease step, and caps the scan at 2 pages. Bumping the pin inside upload-assets would resolve this for everyone; we couldn't find a released softprops v2.x line with the fix, so the pin would need to move to v3.
    • For anyone blocked meanwhile: the workaround c-ares adopted works fine on generator v2.1.0 as-is — upload-assets: false, then download the provenance via needs.provenance.outputs.provenance-name with actions/download-artifact and upload it yourself. (We attach with gh release upload, which resolves draft releases by pending tag name — avoids depending on softprops behavior entirely.)

    Happy to test a release candidate with the pin bump if that's useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    status:triageIssue that has not been triagedtype:bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions