changeset version Throws "ENOENT: no such file or directory 'CHANGELOG.md'"

[oliversalzburg]

When you disable changelog generation, you have no CHANGELOG.md. Some parts of the code explicitly deal with this, but https://github.com/changesets/action/blob/main/src/run.ts#L300 doesn't seem to care and always tries to read the nonexistent README.md, causing the process to fail.

[Andarist]

It would be good to fix this issue - PRs are welcome. However, I also wonder how are you exactly using Changesets without CHANGELOGs. This use case is a little bit esoteric and I would love to learn more about it.

[oliversalzburg]

Generally, there is an option to disable changelog generation in changesets itself, so I assumed this is within scope and a supported use case. If not, I would have to look at entirely different solutions.

Generation changelogs with changesets is fragile, as GitHub reliably responds with "secondary rate-limit" errors sooner or later and the exact cause for these is not well understood. I have spent the past month with GitHub support to try to get any insights into why our release/publish process is suffering from these failures and it was mostly a waste of energy.

As I can not rely on changelog generation being stable for the time being, I feel like it's in my best interest to not generate changelogs entirely.

[Andarist]

Generally, there is an option to disable changelog generation in changesets itself, so I assumed this is within scope and a supported use case. If not, I would have to look at entirely different solutions.

Yes, it is an option - it predates my involvement in the project though so I'm missing some context behind it. That's why I was asking about your use case.

Generation changelogs with changesets is fragile, as GitHub reliably responds with "secondary rate-limit" errors sooner or later and the exact cause for these is not well understood. I have spent the past month with GitHub support to try to get any insights into why our release/publish process is suffering from these failures and it was mostly a waste of energy.

I've also tried to learn more about this through their support channels but I have a similar experience 😭 We might need to revisit how we interact with their API and try to minimize it somehow - although I also experienced this secondary rate-limit when there was almost none other activity within the whole GitHub organization, so I can't imagine why they would reject a particular request.

As I can not rely on changelog generation being stable for the time being, I feel like it's in my best interest to not generate changelogs entirely.

Perhaps switching back to the regular git changelog generator would be an option? That should minimize the interaction with the GitHub API.

[oliversalzburg]

although I also experienced this secondary rate-limit when there was almost none other activity within the whole GitHub organization, so I can't imagine why they would reject a particular request.

That matches my experience exactly. Last Friday I was trying to push a single last release, after being in a 1h meeting and my pipeline failed for "secondary rate-limit". It is way too intransparent of an issue that I could reasonably work around it. Even after all this investigation, I'm still unclear if this limit is effective on the enterprise, organization, repo, user, ... whatever level.

And GitHub support made it clear that they don't want to disclose further information about inner workings, because then people would work around them 😄

Perhaps switching back to the regular git changelog generator would be an option? That should minimize the interaction with the GitHub API.

I actually haven't considered this yet and I should likely investigate it as a possible solution, but when I looked into this action earlier, I realized it also queries the GitHub API with a search that could potentially fail for the same reasons yet again. I'm not sure if it is even feasible to consider a release process on GitHub without search API interaction, but I've lost a lot of my trust in it.

When I was trying to work around the rate-limit earlier, I just figured disabling changelog generation would be a quick and easy fix. In general, I like having changelogs, but considered this a reasonable price to pay for stability. If this action would have caught the error and told me "Sorry, but you really need the CHANGELOG generation to be enabled if you want to use this.", that would have been good enough for me.