search

JuliaGaussianProcesses / AbstractGPs.jl

Abstract types and methods for Gaussian Processes.
https://juliagaussianprocesses.github.io/AbstractGPs.jl/dev
Other
210 stars 20 forks source link

Create Downgrade-CI and bump lower compat bounds #391

Open simsurace opened 4 months ago

simsurace commented 4 months ago

Following the general suggestion here. I'm trying the workflow file from here to speed up finding bad lower bounds.

The PR raises lower bounds such that if any single one of the dependencies is pinned at the lower bounds

While this does not guarantee passing tests if multiple dependencies are held back at once, in my view it is an improvement over the status quo.

codecov[bot] commented 4 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (cf311bd) 96.95% compared to head (bacc546) 96.95%.

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #391 +/- ## ======================================= Coverage 96.95% 96.95% ======================================= Files 12 12 Lines 394 394 ======================================= Hits 382 382 Misses 12 12 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

simsurace commented 4 months ago

I guess this means some of the lower bounds are outdated/no longer working.

simsurace commented 4 months ago

Ok, these are the highest lower bounds that work.

simsurace commented 4 months ago

So now that we found good lower bounds, I will condition this O(number of compat entries) CI on a tag, and only use the downgrade action (which downgrades all packages at once) by default. So if the O(1) pipeline fails, one can put the tag on to trigger the O(n) pipeline that allows to find the minimal set of compats that needs bumping.

simsurace commented 4 months ago

I think I went about it the wrong way. I bumped the lower bounds before the pipeline was doing the correct thing. I should maybe start from scratch.

simsurace commented 4 months ago

Ok I think now we have it. Switching to the low-cost action now.

simsurace commented 4 months ago

I think the action that pins all dependencies at their minima is too restrictive. I will disable both by default and let them be enabled by the downgrade-ci PR flag. Let us then decide on a case-by-case basis.

theogf commented 4 months ago

I don't think I fully understand the action? Is the idea to see which is the lowest compatible version of our dependencies?

I am asking this because it looks like the result is much more restrictive than before

simsurace commented 4 months ago

The action fixes each dependency separately to its lowest version that still resolves, and runs tests there. In response, I bumped the lower bound to the lowest possible version where the test passes. Sure, it is more restrictive, but the looser bounds from before are broken.

simsurace commented 4 months ago

In contrast, the test-simple job would pin all dependencies to their lower bounds simultaneously and then runs tests there. I figured that this is too strict a requirement.