-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
abortOnError:false not working #13482
Comments
Hi there, Help us by making a minimal reproduction repository. Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this. To get started, please read our guide on creating a minimal reproduction to understand what is needed. We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment. Good luck, The Renovate team |
Created the minimal reproduction repo - https://github.com/bprachi29/testRepo1 |
Thanks, could you edit the readme there to describe what it is aimed to demonstrate, e.g. expected behavior vs observed behavior? Also attach relevant debug logs |
Updated the readme file |
Please reduce the repo to minimal (I assume that you don't need 10 or more dependencies to demonstrate it?) plus format the logs in the readme so that they're readable. |
Hey.. I have removed most of the dependencies now.. but we are facing issues with the grunt libraries, so kept all of them. Formatted the logs as well. |
Also happening for me, when a Docker image is not present everything fails (even when
|
Hi, |
Hi
Because as I see in the code, it doesn't handle the abortOnError flag when throwing the exception instead the code throws new exception The code parts that I'm talking about has been attached below. Docker: renovate/lib/datasource/docker/index.ts Lines 171 to 179 in 98b20ad
Npm : renovate/lib/datasource/npm/get.ts Lines 199 to 207 in 98b20ad
Thanks |
Thanks. What I think this means it that for Docker and npm, we are not aborting on every error and instead specific ones. Therefore it's not the HTTP layer (which understands |
+1, having this issue with docker. Maybe for my particular issue a fix could be ignoring |
Crosslinking discussion with same problem observed with docker #17794 |
FYI the workaround for this is to add the affected libraries to |
@rarkins I encountered again this issue due to the fact that the dockerhub image prometheus/prometheus has migrated to prom/prometheus and is now erroring. This suddently broke the renovate builds for our project without us noticing immediately. As a result, we were not receiving any renovate PRs or rebases from the renovate SaaS instance. As a workaround for this issue, is there a known approach to receive notifications for failed SaaS renovate builds for more than a given duration ? Could a prometheus metrics endpoint exposing metrics per project allow users to handle their own monitoring and alerting ?
https://hub.docker.com/r/prometheus/prometheus 404 |
Sorry, already tracked into #17661 |
🎉 This issue has been resolved in version 37.267.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
How are you running Renovate?
Self-hosted
If you're self-hosting Renovate, tell us what version of Renovate you run.
latest
Please select which platform you are using if self-hosting.
GitLab self-hosted
If you're self-hosting Renovate, tell us what version of the platform you run.
No response
Describe the bug
I have added "abortOnError: false" for npm host type, but the renovate bot is still exiting with the error
External host error causing abort - skipping
Relevant debug logs
Logs
Have you created a minimal reproduction repository?
Repo link (https://github.com/bprachi29/testRepo1)
The text was updated successfully, but these errors were encountered: