Closed josepot closed 7 months ago
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 npx @zombienet/cli
works again 🎉. I'm closing this issue.
However, there is IMO a learning lesson from this: which is that the @polkadot/*
packages should be published in topological order. Otherwise, this kind of problems could happen again.
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: 1) According to the release notes: this should have been a minor release, rather than a patch release. 2) The release is completely broken, so if possible it's better to just unpublish it for now.
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.