Create Downgrade-CI and bump lower compat bounds

[simsurace]

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

• The remaining dependencies can still be resolved
• All the tests pass

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]

Codecov Report

All modified and coverable lines are covered by tests ✅

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

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #391   +/-   ##
=======================================
  Coverage   96.95%   96.95%           
=======================================
  Files          12       12           
  Lines         394      394           
=======================================
  Hits          382      382           
  Misses         12       12           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[simsurace]

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

[simsurace]

Ok, these are the highest lower bounds that work.

[simsurace]

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]

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]

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

[simsurace]

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]

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

[theogf]

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]

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]

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.