Error on run

[ritvij14]

https://github.com/ritvij14/cnc_flutter_app/runs/3274828570?check_suite_focus=true

I am unable to figure out how to sort out this error, everything was working fine till yesterday and since today all my runs are failing

[andreashock101]

I'm experiencing the same issue on a private repo of mine.

[ahaasler]

This is also happening to me https://github.com/ahaasler/dotfiles/runs/3274924051?check_suite_focus=true

[andreyvrn]

Hi! From commit 59c3b4891632ff9a897f99a91d7bc557467a3a22 everything works!

uses: softprops/action-gh-release@59c3b4891632ff9a897f99a91d7bc557467a3a22

[DerYeger]

I'm getting the same error across all repositories of mine with this workflow setup: https://github.com/DerYeger/jan-mueller/blob/1ec24888456ee9723b13bfc82ec08542c1c3f3c7/.github/workflows/cd.yml#L53

As mentioned above, nothing changed in my configuration.

[softprops]

Deep apologies for the disruption and thas for the reports folks. Keep the links coming where possible.

until I’m able to get a deeper understanding of the problem the suggested temporary fix is this comment

https://github.com/softprops/action-gh-release/issues/139#issuecomment-894845588

The longer possible explanation is I’ve recently merged a lot of long standing well intentioned prs starting here, some of which I’m now learning have created regressions

as I deal with these, I plan on commuting to much shorter more frequent release cycles which allows me to more clearly see potential for breakage

again, thank you for any patience you are able to lend me on this

[agc93]

Can these updates to go to a different tag or something so that @v1 continues using the older (known working) method and the new and improved goes to a v2 tag or something? I just got stung by a similar build failure despite using a pinned version

[CalvinWilkinson]

Deep apologies for the disruption and thas for the reports folks. Keep the links coming where possible.

until I’m able to get a deeper understanding of the problem the suggested temporary fix is this comment

#139 (comment)

The longer possible explanation is I’ve recently merged a lot of long standing well intentioned prs starting here, some of which I’m now learning have created regressions

as I deal with these, I plan on commuting to much shorter more frequent release cycles which allows me to more clearly see potential for breakage

again, thank you for any patience you are able to lend me on this

This is a great idea. I myself like to keep my projects with short small pull requests and releases.

I will be waiting patiently!! Thanks for looking into the issue. 🙂

[softprops]

the new and improved goes to a v2 tag

This is a good idea and I feel you but I’d like to reserve these for intentional breaking changes. We haven’t yet intentionally removed any existing functionality or interfaces.

My hope is that with smaller change sets and perhaps stricter guidelines on testing issues like these will be rarer

[thaunguyen]

This version softprops/[email protected] is working for me

[CalvinWilkinson]

I confirm as well that this is working. I will be patiently waiting for a fix.

• KinsonDigital/CASL#7

Thanks @softprops!!

[EdJoPaTo]

Keep the links coming where possible.

https://github.com/EdJoPaTo/website-stalker/actions/runs/1112600663

Using v0.1.8 also fixed it for me.

And while I'm already here: Thanks for doing this and its awesome to see the takeaways and learnings to improve something like this in the future.

[mziech]

I was facing the same problem yesterday. In my case, the root cause for the 404 seems to be an invalid discussions category being posted with the release. I was able to continue using v1 by applying the following steps:

1. Enable discussions
2. Create a discussions category "Releases"
3. Add the following option to the release action:

discussion_category_name: releases

Of course it would probably be better to make the discussions category optional again...

[softprops]

it would probably be better to make the discussions category optional again

Hrm. It shouldn’t be required today https://github.com/softprops/action-gh-release/blob/815e45857946b196197a116aa0def711ff7f8ecc/action.yml#L42

This should be easy to fix if not

[aiastia]

"softprops/action-gh-release@v1" Can it work?

[softprops]

the main issue the causing the error breaking releases is now fixed in https://github.com/softprops/action-gh-release/releases/tag/v0.1.12 (v1 tag was updated)

there may be smaller cosmetic issues but the main issue is resolved

[softprops]

the tl'dr on the underlying issue. post the introduction of target_commitish users not using the new input were impacted in this way

1. attempt to resolve an release to update failed (this is normal of a first release run as there's nothing to update)
2. attempt to create a release fails, the target_commitish is provided by the actions runtime when not provided by users is an EMPTY STRING and not undefined as one might expect causing the create rest api call to fail with 422. (this is NOT normal)
3. the release requests recursively retried, so we loop until we run out of reties

this can be observed in all examples run logs provided

to further make the situation worse https://github.com/softprops/action-gh-release/releases/tag/v0.1.9 was hit with the same gotcha. discussion_category_name this time was again an empty string and not undefined suffering the loop of doom above

🙏 many thanks for the patience on this. a few take aways from me on this are.

• this action is depended on by more people than I thought or ever expected with many more usecases that I have which means I need to think harder about testing its strategy. In the first case that caused the problem for example, if I'd asked to show a repo demonstration of the new target_commitish feature, I would have totalled miss the bug that would effect anyone not using the feature
• I need smaller more frequent release cycles. covid and a new family member had be busy for a while I should not have let this pulls set for as long as they did which made it hard to understand where breakage was possible.
• I can use at least one other maintainer. It's just me now. I received a lot of feedback about this bug but no offers to help investigate or fix it. If there were only few users of this action that might be fine but because there are many that puts a lot of stress on one person's shoulders to fix the issue quickly, putting normal life aside.

If anyone is interested in any of all of the above. I'm open to any ideas that would help

[CalvinWilkinson]

Thanks for the update @softprops!!

You did a great job and got a fix out quickly in my mind. Don't stress about it. 🙂 Thank you so much for looking into it. We are all human, not machines and I definitely sympathize when it comes to real life getting in the way.

Open source is a thankless job!! 🚀

[CalvinWilkinson]

Just to make sure I am understanding though, I was using v1. But your saying that the fix is on v0.1.9?

Which version should I use? Sorry for any confusion on my side.

[EdJoPaTo]

@CalvinWilkinson

the main issue the causing the error breaking releases is now fixed in https://github.com/softprops/action-gh-release/releases/tag/v0.1.12 (v1 tag was updated)

I think thats why you thought about v0.1.9:

to further make the situation worse https://github.com/softprops/action-gh-release/releases/tag/v0.1.9 was hit with the same gotcha. discussion_category_name this time was again an empty string and not undefined suffering the loop of doom above

---

And yeah, I am with CalvinWilkinson on this, don't stress about it, we are all humans.

What maybe a good idea might be: provide a stable and an experimental tag. Or maybe v1 and "master"/"main" and promote it in the README. People who are willing to test stuff and accept breaking parts can use the main branch and maybe a week later the version gets rolled up to v1. That way testers can supply "this broke for me" to the repo while others arn't affected yet. If they want new features, they should help testing ;)

[softprops]

@CalvinWilkinson You can use these

https://github.com/softprops/action-gh-release/issues/139#issuecomment-895714781

[CalvinWilkinson]

I am not sure if you are using semantic versioning, but that is the route I take and it is fantastic. This means in regards to testing/non production ready builds, you could tag something with a version v1.2.3-preview.3 for example and that is what people can use for testing. Once it is stable, it then finally becomes v1.2.3.