Repository navigation
gh release create successfully returns before release is available to subsequent calls #6599
Description
Activity
Hi, thank you for reporting. We talked about this previously here: duplicate of #6198 (comment)
Summary:
- Draft releases referenced by tag name are looked up by listing releases from API;
- API list of releases suffers replication lag;
- As a result, trying to reference a draft release immediately after its creation might be too soon.
Workaround: just upload assets to a new non-draft release and allow it to be published. Internally, GitHub CLI will create a draft release first, upload assets to it, and publish it after all the assets are fully uploaded and available.
gh release create <tag> --generate-notes <file1> <file2>Workaround: just upload assets to a new non-draft release and allow it to be published.
That doesn't work in a workflow of mines. There are a bunch of uploads, which are included if necessary and required:
- name: Upload Asset XYZ if: ${{ needs.some.condition }} working-directory: ${{ env.ASSETS_FOLDER }} run: | gh release upload <tag> <Asset_XYZ>So I prefer and want a Draft Release that is only being published once all conditional Assets are uploaded.
We talked about this previously here: duplicate of #6198 (comment)
Ah - I haven't found that. Sorry about the duplicate.
I still consider the current behavior a bug, or at least an unexpected behavior of the system.
One would assume that creating a (draft) release returning a success, that that draft release is immediately available.Sure, one can workaround with either
sleep x, or such as mentioned above do some polling until the just-created (draft) release available for further processing. But honestly I'd prefergh release createto do that internally.A shell script, an action or a workflow should not be aware of GitHub internals (such as what you have mentioned: " I suspect some kind of database or ElasticSearch replication lag."). If that's know to GitHub, it should handle that accordingly on their end.
I am obviously not the first one running into this. And I won't be the last one. Which basically means that you're going to get issues about this again and again.
At the very least... it would have helped to find this "potential/known issue" in the documentation. If GitHub really wants to have this current behavior "by design", then the documentation should mention this in the docs for
gh release create(along with suggestions how to deal with it).Reacted by dkThis may be the wrong place to jump in but I'm experiencing similar issues with
gh release create ... --draftand subsequently attempting to access the release withgh release view ...where I'm receivingrelease not found. I have no troubles running the samerelease viewcommand locally, and this appears to only occur in GitHub Actions. BUT what's interesting is that this was working fine and as I've continued working on the action it suddenly stopped working.I noticed a similar issue (#3037) which talks about a similar behavior, and I did notice GitHub actions is able to list the draft releases on subsequent runs
I was able to add
sleep 5betweencreateandviewto workaround this issue in the meantimeSure, one can workaround with either
sleep x, or such as mentioned above do some polling until the just-created (draft) release available for further processing. But honestly I'd prefergh release createto do that internally.Good point. We can consider blocking
gh release createoperation until the newly created draft release is "visible".So I prefer and want a Draft Release that is only being published once all conditional Assets are uploaded.
Your conditional logic could put all the assets to upload in a single directory. Then, when all that is processed and done, a single
gh release create <tag> dist/*operation could upload all the files at once. I believe that a release automation approach that relies on fewer totalghcommands will be simpler and more resilient to maintain.But that's beside the point. Of course that the main problem still remains, and that is that draft releases are not immediately visible by CLI upon creation.
I just experimented with the API and found out that the GraphQL
Repository.releaseconnection allows us to directly fetch a draft release by its pending tag name (unlike the REST API where this is not allowed). By switching to GraphQL for this, we could avoid having to rely on release listing that has replication lag and gain the ability to immediately reference the new draft release in a subsequent CLI operation.{ repository(owner: "cli", name: "cli") { release(tagName: "v2.20.2") { name databaseId isDraft } } }We might have to completely reimplement FetchRelease and FetchLatestRelease for this, but I think it could be worth it
cli/pkg/cmd/release/shared/fetch.go
Line 122 in 8891456
Your conditional logic could put all the assets to upload in a single directory. Then, when all that is processed and done, a single
gh release create <tag> dist/*operation could upload all the files at once.Good hint - thanks. But that's not the point of this issue.
We can consider blocking
gh release createoperation until the newly created draft release is "visible".Or document that it is designed to behave "async". And similar to Apple's
notarytooladd a parameter--wait, which would block and only return once available for all subsequent calls.- added a commit that references this issue
on Apr 27, 2026
Describe the bug
The command to create a release returns too early - before the release is available to subsequent calls.
This possibly leads to errors when trying to upload files right after creating a release.
Steps to reproduce the behavior
When trying to do the following in a Shell Script or in a GitHub Workflow:
Then the second line
gh release upload ...(often - not always) fails with the error:release not foundExpected vs actual behavior
gh release upload ...should wait until the release is available to other calls.If this command returns OK, then it's expected that the release exists for the next call.
Workaround