-
Notifications
You must be signed in to change notification settings - Fork 16
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
Handle issues from other packages side? #19
Comments
I would say it is fine to have the CI broken when a package change/is not installed correctly anymore. That being said, if the CI breaks due to an external package and there is no fix on the way, we can also skip this particular test using the |
All right. Thank you for the clarification So I am wondering would it make more sense from a user pov to have at the end of the readme a table with the status of each "dependency" instead of having only one status per problem? (not that I know how to make it right now) |
Interesting idea. I think this is easy to do in the context of running the tests separately but the issue is morer how to report this. I would say it is not a priority right now but it could be fun to try. |
The CI is currently red and one of the reasons is a problem from a package that is used (see ).
Technically, this is not a BenchOpt error, and it can impact multiple repositories if the same library is used for different problems to solve.
So where is the limit (if there is one) between a warning in the CI that there is a problem on some library side and a real error from BenchOpt that we can deal with?
(poke @josephsalmon)
The text was updated successfully, but these errors were encountered: