-
Notifications
You must be signed in to change notification settings - Fork 349
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
@polkadot/api@10.12.5 references non-existing versions #5841
Comments
Weird thanks for notifying of this. I didn't get any notification, and CI process had successfully published the tags, and release therefore I assumed the automation had finished correctly. Not good. |
latest release fixes this: https://github.com/polkadot-js/api/releases/tag/v10.12.6 Thanks a ton for the info and reporting this 🙏 |
Thanks! I can confirm that the release of 10.12.6 has solved the issue that we had with the CI, and now However, there is IMO a learning lesson from this: which is that the |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query. |
The CI of polkadot-api, which relies on a
npx @zombienet/cli
command, started failing a couple of hours ago for no apparent reason. After some digging, it turns out that the reason why it stopped working is because of the recent release of@polkadot/api@10.12.5
:which references a bunch of dependencies:
that have not yet been published:
Please, publish those versions ASAP, because
@polkadot/api@10.12.5
is a patch release. Therefore, all libraries that reference version "^10.12.x" of@polkadto/api
are now broken. I mean, sure... the lock files will prevent some incidents, but this is still a serious issue. Eg what just happened to us while usingnpx @zombienet/cli
.EDIT:
Actually, if it's not too late, the best solution IMO would be to perform a:
Mainly for 2 reasons:
EDIT II:
This job has been running for more than 3 hours and 30 mins, and it seems to keep on trying to re-publish a wrongly published release. I think that it should be manually stopped.
EDIT III:
I ended up taking the liberty of canceling the workflow, given the fact that it was obvious that there was no one monitoring it, and the npm servers had been responding with
403
and429
errors for hours.The text was updated successfully, but these errors were encountered: