-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade nixpkgs #3155
Upgrade nixpkgs #3155
Conversation
No idea why the nix build succeeds locally, but fails in CI. Shouldn't this be reproducible? |
It's taking a while to build this locally.. maybe the CI failure could be related to the Prepopulate Nix cache for Linux runners job? Perhaps opening another PR could confirm this? |
Could the local environment leak into the build? Does it build in |
Nope, just tried running the tests locally and failed too:
Same error message as CI |
Only the tests though, running the executable works fine:
|
|
No problem with the above from my side. Let's just upgrade and figure it out later. |
I'm not sure what to conclude from the observations here.
Correct? I wonder what I need to do to make it fail.. so I can actually debug it. |
Aha. I deleted my So |
Doing a ... but this is all confusing. We should not need to run |
My bad, |
a63d771
to
f53ad14
Compare
Added to commits to test building with GHC 9.6.x and GHC 9.8.x just out of curiosity.. |
Seems like our dependencies are not ready for GHC 9.6+, yet. Will drop those for now. |
f53ad14
to
846f12c
Compare
Previously this command upgraded to the latest unstable version of nixpkgs, but this was often broken. Taking the latest stable branch should give better results.
846f12c
to
17e5faa
Compare
Couldn't help but notice "prepopulate nix cache" job is building the |
It's expected that the toolchain needs to be rebuilt after a nixpkgs upgrade, I think. I have not looked at the prepopulate nix cache job and the related changes in the last months, so I can't tell whether it does something odd there. But a complete rebuild after a nixpkgs update often takes a lot of time - and in the small machines that are run in CI, 5+ hours are expected for me. Am I missing something? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@wolfgangwalther I see. Are you suggesting these long-building outputs eventually make their way to PostgREST's Cachix? Fine by me, then. |
That's my understanding, yes. Once those jobs run on the main branch, they will actually push to cachix. |
I tried updating nixpkgs a few day ago. This didn't work out well, because the nixpkgs-unstable channel had some packages that we require broken. Then I wondered: Why do we even have nixpkgs-unstable in
postgrest-nixpkgs-upgrade
? So I changed that to use the latest stable channel - and then ran the upgrade again.This time, I was able to make it work with a few changes here and there. One major change:
text >=2.0.2
- which is only available in GHC 9.4+That means that because of the fuzzyset dependency, we can't build with GHC 9.2 or GHC 9.0 anymore. I don't think that this is a problem... but let's wait and see what the
Build-Cabal-Arm
job says about that.TODO:
Resolves #3107
Supersedes #3112
Probably still blocked by #2834