-
-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reusing existing draft release no longer works in GH org #163
Comments
I’ll have to take a closer look but when specifying a draft an attempt is made to first resolve an existing draft with the same name before creating a new one action-gh-release/src/github.ts Line 209 in 58fa4b7
|
I'm having a similar issue - in my case I'm building two assets in parallel jobs (one for mac, one for windows) and then uploading to create a new release. Oddly enough this behaved as expected 2 days ago, creating a single draft release with two assets attached, and re-running the action resulted in updating the asset on the existing release. Today it is creating two separate releases with the same tag, each with a single asset, and every time I run the action a new draft release with the same tag is created. Did something change on GitHub's end? I can't see anything different in your action or in my workflow. |
We've been hit by the same issue over on https://github.com/starship/starship. We have a release first be created as a draft by https://github.com/googleapis/release-please, generate our build artifacts, then would use action-gh-release to upload the artifacts and publish the draft with |
I had a similar problem, and ended up using actions/github-script to find and update the release. I originally tried: const tag = "v${{ needs.prepare.outputs.version }}";
const release = await github.rest.repos.getReleaseByTag({
owner: context.repo.owner,
repo: context.repo.repo,
tag: tag,
})
await github.rest.repos.updateRelease({
owner: context.repo.owner,
repo: context.repo.repo,
release_id: release.data.id,
draft: false,
body: "Check the [changelog](https://github.com/qutebrowser/qutebrowser/blob/master/doc/changelog.asciidoc) for changes in this release."
}) But ended up getting a 404 for finding the release, even though the tag was correct. That might well be the same underlying issue which also causes this action to create a new one, I suppose? In the end, I instead used the release ID from this action directly (heavily cut down, untested, but might be a good starting point?): name: Release
on:
...
jobs:
prepare:
...
outputs:
...
release_id: ${{ steps.create-release.outputs.id }}
steps:
- name: Create GitHub draft release
id: create-release
uses: softprops/action-gh-release@v1
with:
tag_name: v${{ steps.bump.outputs.version }}
draft: true
body: "*Release artifacts for this release are currently being uploaded...*"
...
finalize:
...
needs: [prepare, ...]
steps:
- name: Publish final release
uses: actions/github-script@v6
with:
script: |
await github.rest.repos.updateRelease({
owner: context.repo.owner,
repo: context.repo.repo,
release_id: "${{ needs.prepare.outputs.release_id }}",
draft: false,
body: "Check the [changelog](https://github.com/qutebrowser/qutebrowser/blob/master/doc/changelog.asciidoc) for changes in this release."
})
... |
I just recently moved https://bkimminich/juice-shop into https://juice-shop/juice-shop and noticed a behavior change of my release flow https://github.com/juice-shop/juice-shop/blob/master/.github/workflows/release.yml#L49 as follows:
Precondition
I manually create a draft release named
vX.Y.Z
where I store all release notes over time until the release gets published.✅ Before (https://bkimminich/juice-shop)
When pushing tag
vX.Y.Z
the action would use the existing release and attach build artifacts to it.❌ After (https://juice-shop/juice-shop)
When pushing tag
vX.Y.Z
the action will ignore the existing release and create a new release also namedvX.Y.Z
where it attaches all build artifacts. I can use a workaround of copy-pasting my release notes over to the newly created release and delete the old one, but it'd be nice to get rid of this glitch.I am at a loss where this behavior might come from. Is it maybe something with lacking permissions of default
GITHUB_TOKEN
when working in a GitHub org instead of a personal account? Or could this be an actual bug in the action?The text was updated successfully, but these errors were encountered: