Add CI workflow lane for dependency testing (canary lane) - #3430
Conversation
d9ce322 to
a7b8470
Compare
There was a problem hiding this comment.
Very nice, super useful for the version upgrades milestone.
One higher level design question, would you be in favor of removing those tests once we successfully increment a package and keep the infra for later? Or would this be more of a permanent CI lane by design?
@C-Achard, good question. Yes, as mentioned, I think this would indeed be very helpful as a permanent CI lane after we resolved the current dependency upper bounds (i.e. the first test layer that could find out if upstream packages become incompatible with our current API). |
9fd8978 to
1cc0cb9
Compare
Co-authored-by: Cyril Achard <cyril.achard@epfl.ch>
Co-authored-by: Cyril Achard <cyril.achard@epfl.ch>
The canary lane was the only lane missing the is_dev_draft guard
43fb461 to
2dbc6db
Compare
Motivation
We currently enforce version pins for quite some dependencies. This PR introduces a non-blocking test lane that can help to identify future-incompatibilities when we release these upper bounds.
Changes
Add add a non-blocking "canary" test lane that tests future compatibility for specific pip-overrides. Currently, we run only the pytests and the torch functional tests for just one python version (3.12) and os (ubuntu). The following dependency overrides are tested:
albumentations >= 2numpy >= 2pandas >= 3matplotlib >= 3.9Related PRs