Run cabal outdated on CI

[sol]

This was part of the pre-flight checklist, which I would like to get rid of.

https://github.com/haskell/cabal/wiki/Making-a-release/_compare/a04bbb077297d496d2609a5ca35619427c245fa0...1848c319688beed33254efcf612d01c737c8a78e

[philderbeast]

First time for me testing cabal outdated so apologies if I'm holding it wrong.

Whether I comment out # --exit-code or not, I'm not seeing outdated dependencies with the Makefile recipe. I checked the cabal outdated --help and if I run cabal outdated all with or without a freeze file¹ am seeing outdated dependencies.

Could you please add some manual QA notes on what to expect? Can we manually tweak a dependency to trigger an outdated dependency warning?

$ cabal outdated --help
Check for outdated dependencies.

Usage: cabal outdated [FLAGS] [PACKAGES]

Checks for outdated dependencies in the package description file or freeze
file
...

$ ghc --numeric-version
9.12.4

$ cabal outdated all
Outdated dependencies:
* Cabal-QuickCheck
  - lib:Cabal-QuickCheck
    * QuickCheck >=2.13.2 && <2.18 (latest: 2.18.0.0)
* Cabal-tests
  - test:check-tests
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
  - test:hackage-tests
    * base-compat >=0.11.0 && <0.14 (latest: 0.15.0)
    * optparse-applicative >=0.13.2.0 && <0.19 (latest: 0.19.0.0)
    * tree-diff >=0.1 && <0.4 (latest: 0.4.1)
  - test:no-thunks-test
    * nothunks >=0.1.1.0 && <0.3 (latest: 0.3.1)
  - test:parser-tests
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
    * base-compat >=0.11.0 && <0.14 (latest: 0.15.0)
    * tree-diff >=0.1 && <0.4 (latest: 0.4.1)
  - test:unit-tests
    * Diff >=0.4 && <0.6 (latest: 1.0.2)
    * QuickCheck >=2.14 && <2.15 (latest: 2.18.0.0)
* Cabal-tree-diff
  - lib:Cabal-tree-diff
    * tree-diff ^>=0.1 || ^>=0.2 || ^>=0.3 (latest: 0.4.1)
* buildinfo-reference-generator
  - exe:buildinfo-reference-generator
    * base >=4.11 && <4.22 (latest: 4.22.0.0)
* cabal-benchmarks
  - test:cabal-benchmarks
    * tasty-bench >=0.3.5 && <0.4 (latest: 0.5.1)
* cabal-testsuite
  - exe:cabal-tests
    * base >=4.11 && <4.22 (latest: 4.22.0.0)
  - exe:setup
    * base >=4.11 && <4.22 (latest: 4.22.0.0)
  - lib:cabal-testsuite
    * aeson ^>=1.4.2.0 || ^>=1.5.0.0 || ^>=2.0.0.0 || ^>=2.1.0.0 || ^>=2.2.1.0 (latest: 2.3.0.0)
    * base >=4.11 && <4.22 (latest: 4.22.0.0)
    * containers ^>=0.5.0.0 || ^>=0.6.0.1 || ^>=0.7 (latest: 0.8)
    * network-wait ^>=0.1.2.0 || ^>=0.2.0.0 (latest: 0.4.0.0)
    * optparse-applicative ^>=0.14.3.0 || ^>=0.15.1.0 || ^>=0.16.0.0 || ^>=0.17.0.0 || ^>=0.18.1.0 (latest: 0.19.0.0)

Footnotes

1. Picking up packages not included in the Makefile recipe. ↩

[sol]

@philderbeast yes, manually tweaking some dependency works, that is what I did to test this locally.

[sol]

e.g. change this to < 0.8

cabal/Cabal/Cabal.cabal

Line 46 in 5fe8d8d

, containers >= 0.5.8.2 && < 0.9

[ulysses4ever]

Why part of validate though? This will hit unsuspected contributors at random time. I think if anything it should be a separate cron job.

[sol]

Why part of validate though? This will hit unsuspected contributors at random time. I think if anything it should be a separate cron job.

1. If this causes problems, it can be disabled.
2. From my perspective this is a trade-off. Having master always in a releasable state outweighs any minor inconveniences this may cause. But if it turns out to be too disruptive, then personally I would just iterate over it.

[sol]

Why part of validate though? This will hit unsuspected contributors at random time. I think if anything it should be a separate cron job.

1. If this causes problems, it can be disabled.
2. From my perspective this is a trade-off. Having master always in a releasable state outweighs any minor inconveniences this may cause. But if it turns out to be too disruptive, then personally I would just iterate over it.

To be clear, I don't think it's a contributors responsibility to fix this as part of a feature. I imagine a core developer will take care of it. If I'm around, and somebody pings me, I am happy to do it.

The effect for contributors will be:

• Features cannot be merged until master is green.
• Feature branches have to be rebased, once master has been fixed.

@ulysses4ever does this address your concerns?

[Mikolaj]

The effect for contributors will be:

* Features cannot be merged until `master` is green.

* Feature branches have to be rebased, once `master` has been fixed.

I'm afraid it's worse that that. CI on PRs will start failing out of the blue. Not when a contributor rebases his PR on the master branch, but suddenly, overnight.

Let me quote from the matrix channel: "PR authors use CI a lot to help them debug their PR long before they propose to merge it. Also, conceivably, we may occasionally release without cabal outdated passing (I think this hasn't happened yet, though), e.g., if we have to release ASAP for GHC, but a dependency can't be fixed in time."

Also, fixing any possible upstream problems can take a long time: "Unfortunately, some of the time, this involves fixing the dependencies themselves (cabal's CI has a history of exposing bugs in cabal deps) or other lengthy tasks, during which the CI is broken for all PR authors."