Uploading an artificat to a draft release doesn't work (not found) #6198

Activity

1. ctron

   added

   bugSomething isn't workingSomething isn't working

   on Sep 5, 2022
2. cliAutomation

   added

   needs-triageneeds to be reviewedneeds to be reviewed

   on Sep 5, 2022
3. mislav commented on Sep 5, 2022

   

   mislav

   on Sep 5, 2022

   Contributor

   More actions

   Thank you for reporting. I've managed to reproduce, and it's bizarre: it looks like although the release was properly created and visible via gh release list (backed by GitHub GraphQL API), the new release is not immediately available to gh release upload (backed by GitHub REST API) until a few seconds later. For about 2 seconds after the creation of the release, GitHub GraphQL and REST APIs are out of sync. I suspect some kind of database or ElasticSearch replication lag.

   Your workarounds are either:

   1. Since you are publishing the draft release immediately after uploading the assets, you can just switch to gh release create -p $TAG <files>... invocation, which will upload your assets and publish the release when finished.
   2. Alternatively, you can add a sleep 3 statement before gh release upload step.
4. mislav

   added

   priority-3Affects a small number of users or is largely cosmeticAffects a small number of users or is largely cosmetic

   platformProblems with the GitHub platform rather than the CLI clientProblems with the GitHub platform rather than the CLI client

   and removed

   needs-triageneeds to be reviewedneeds to be reviewed

   on Sep 5, 2022
5. ctron commented on Sep 6, 2022

   

   ctron

   on Sep 6, 2022

   Author

   More actions

   Thanks for taking a look at this.

   We are using this pattern of (create draft, add assets, remove draft) in a bunch of cases. Sometimes with a more variable list of files, or multiple steps of uploading. So this ensures that the draft state only gets removed when everything is complete. But maybe we just need to rework this.
6. ctron

   added a commit that references this issue on Sep 6, 2022

   ci: work around cli/cli#6198

   d2d4075
7. mislav commented on Sep 15, 2022

   

   mislav

   on Sep 15, 2022

   Last edited by mislav

   Contributor

   More actions

   Sometimes with a more variable list of files, or multiple steps of uploading.

   You can dynamically resolve a variable list of files in your script to the final set of files, and pass that final set to gh release create as arguments for a single call. You still have flexibility that way.

   But If you do need to keep your upload flow as separate commands, then just put a sleep 3 after the gh release create --draft to work around the current API issue at the cost of slowing down your workflow a bit.

   So this ensures that the draft state only gets removed when everything is complete.

   gh release create will automatically keep the release as draft until all uploads are complete.
8. mislav commented on Oct 14, 2022

   

   mislav

   on Oct 14, 2022

   Contributor

   More actions

   Hi, a platform update shipped which will ensure that GraphQL and REST APIs match when listing releases, meaning that gh release list will no longer list releases which subsequently can't be found by referencing its tag name. However, due to platform internals, a small replication lag can occur between creating a draft release and having that release be selectable by its tag name. The workaround remains the same: either

   • Upload artifacts in the same gh release create call; or
   • Add a sleep statement after the gh release create operation.
9. mislav

   closed this as completedon Oct 14, 2022
10. suncompass

    added 2 commits that reference this issue on Oct 6, 2026

    fix: 按 tag 首次发布的附件上传改走 release id 直传（0.2.97）

    ...

    39536d2

    fix: 草稿读回按复制延迟有限重试（0.2.98）

    ...

    e330b70