webhooks.js: The automated release is failing 🚨

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


The release 10.8.0 on branch main cannot be published as it is out of range.

Based on the releases published on other branches, only versions within the range >=10.7.0 <10.7.1 can be published from branch main.

The following commits are responsible for the invalid release:

  • feat(typescript): new pull_request.milestoned and pull_request.demilestoned events (#830) (8a7ac10)
  • ci(action): update actions/add-to-project action to v0.5.0 (#827) (d64f69a)
  • build(deps): lock file maintenance (#826) (254dce3)
  • chore(deps): update dependency prettier to v2.8.7 (#825) (6fb502c)
  • chore(deps): update dependency prettier to v2.8.6 (#824) (759ebb2)
  • build(deps): lock file maintenance (#823) (ef286ce)
  • chore(deps): update dependency typescript to v5 (#822) (5c6ae69)
  • build(deps): lock file maintenance (#821) (02b5009)
  • chore: explicitly mark imports/exports that are only used as types (#818) (7fb151d)
  • build(deps): lock file maintenance (#817) (3da11ba)
  • ci(action): update actions/add-to-project action to v0.4.1 (#816) (4065cb8)
  • build(deps): lock file maintenance (#815) (9f79d6c)
  • build(deps): lock file maintenance (#814) (97d64e0)
  • build(deps): lock file maintenance (#813) (5511920)
  • chore(deps): update dependency prettier to v2.8.4 (43110c1)
  • build(deps): lock file maintenance (1e5fa7c)
  • build(deps): lock file maintenance (#809) (006946a)
  • build(deps): lock file maintenance (#808) (08c1131)

Those commits should be moved to a valid branch with git merge or git cherry-pick and removed from branch main with git revert or git reset.

A valid branch could be next.

See the workflow configuration documentation for more details.


Good luck with your project ✨

Your semantic-release bot 📦🚀

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 19 (19 by maintainers)

Most upvoted comments

@oscard0m I un-reverted #830 (reverted #833) in next. That way we don’t need a PR for it, and it will be done already. It will already be released

Once it’s merged in main, it’ll get pushed to the @latest tag, and un-marked as a pre-release on GitHub

Yes, you are correct. #835 is the correct one

Merging next into main

@wolfy1339 do you want #834 or #835 to go in?

#834

It has to be a standard merge commit, and not a rebase or squash in order to get the proper release flow

@oscard0m I’m going to try to merge main into next

@gr2m @kfcampbell @nickfloyd Can one of you help merge the branch next into main

Go ahead

The test releases we made