Work around for hiedb build failures

[hamishmack]

See wz1000/HieDb#42

[michaelpj]

It feels bad that we have to basically "pre-fix" hackage-based regressions like this. It is simply true that hiedb is broken on hackage, should we not just live with it until it gets fixed properly? Otherwise we will have perpertual work mimicing Hackage fixes in haskell.nix...

[hamishmack]

bors try

[hamishmack]

It feels bad that we have to basically "pre-fix" hackage-based regressions like this. It is simply true that hiedb is broken on hackage, should we not just live with it until it gets fixed properly?

If I had not added the constraint for the dependent-sum issue to haskell.nix we probably would not have found this one yet (as dependent-sum is still broken in hackage). I'm not sure if anyone else is checking that haskell-language-server builds from hackage.

[ocharles]

I'm not sure if anyone else is checking that haskell-language-server builds from hackage.

I am, we don't use Haskell.nix definitions at work, but instead add it as our own hackage-tool.

[michaelpj]

I sure don't object to us finding these things, I just don't feel good about accruing random Hackage fixes in haskell.nix.

[hamishmack]

I just need a good way to make our CI green until it is fixed upstream and because of the way we combine all our results into required jobs there is no easy way to mark individual tests and broken.

One problem is I have to manually remove the code when the issue is closed (not ideal as I might not see the fix come in). This problem would still exist if I was marking the test as broken (I would still need to remember to mark it as working).

It's a pretty common problem with adding work arounds for upstream issues. I wonder if anyone has a tool to automatically remove code once an GitHub issue is closed. Ideally what I would like is to be able to add a couple of comments around a block of code like this:

   # WORKAROUND-BOT WHILE OPEN https://github.com/obsidiansystems/dependent-sum/issues/71 || https://github.com/wz1000/HieDb/issues/42
   ... code here ...
   # WORKAROUND-BOT END

The bot would send a PR once the issues were closed.

[michaelpj]

How about this: have the test build HLS with a specific index-state. Then it shouldn't ever go red unless we take the action to bump the index state.

[hamishmack]

Pinning the index-state is an option as is adding the constraints only to the test (not to hackage-quirks). We could also pin the index state in hackage-quirks.nix.

Pinning the index-state seems might result in more work regularly updating the index state though. Some times haskell-language-server in hackage goes months without breaking.

One thing I did wonder about is if hackage-package function could default the index-state to the upload timestamp of the package. The problem with that though is that it would cut off fixes in dependencies and that might lead to more issues than it would fix.

[michaelpj]

Pinning the index-state is an option as is adding the constraints only to the test

Right. The question is: what is the test testing? If the test is testing "can we build the latest haskell-language-server from hackage" then it will stop it doing that, but I'm not sure that's really what we should be testing. Instead it tests "can we build a known version of haskell-language-server" where we bump that occasionally. We could have a global index-state to be used in tests, even.

I think making the test test something more constrained is a better fix for our CI.

Some times haskell-language-server in hackage goes months without breaking.

That's way too frequent IMO.

[iohk-bors]

try

Timed out.

[hamishmack]

This one is fixed in hackage now. Thanks @sjakobi! Any chance you could take a look at obsidiansystems/dependent-sum#71? I think it might be the same situation as obsidiansystems/dependent-sum#66 (which was solved by @Bodigrim with a hackage revision).

[sjakobi]

Any chance you could take a look at obsidiansystems/dependent-sum#71? I think it might be the same situation as obsidiansystems/dependent-sum#66 (which was solved by @Bodigrim with a hackage revision).

Unfortunately I don't think this can be solved with another revision for dependent-sum. The changelog for some-1.0.4 mentions changes in the modules re-exported by dependent-sum, e.g. the addition of defaultGeq in Data.GADT.Compare. AFAIK, to satisfy the PVP, this requires a new release of dependent-sum with bounds some >= 1.0.4 && < 1.0.5.

BTW, feel free to open issues at https://github.com/haskell-infra/hackage-trustees/issues if you want help from Hackage trustees.