Fix CI config issues (actually build with different GHC versions)

[jhrcek]

Hello,
I'm potentially interested in helping contributing some work towards unblocking #1037

But first things first, looking at latest CI run on main https://github.com/brendanhay/amazonka/actions/runs/25209453900
it seems that CI is not in a very good shape.

This PR aims to fix some of that and hopefully unblock bumping the flake.lock dependencies so we could test with more recent versions of GHC.

Together, these changes fix 3 of the 4 CI jobs currently broken on master (see this same PR in my fork: jhrcek#2).
What's left is a failure in macOS build, which seems to fail when building the GHC 9.0 bootstrap compiler - not sure how to fix that yet..

Heads up: I'm not very skilled with nix (just know some basics)..

[jhrcek]

The YAML extension in vscode caught couple of schema issues in this config (screenshot below)

• branches should be an array of values
• strategy: section has mandatory matrix parameter - but it seems to me since amazonka-gen job is a standalone job, it doesn't make sense to have the strategy key at all.

[jhrcek]

This matrix argument was not taken into account at all - all the jobs were using the ghc 9.4.8 provided by the default shell

It seems to me this is because the last param was somehow consumed by the bash -c ... part and not passed to the nix develop command.

Moving the arg before the --command seems to have fixed it (in that I see Build profile: -w ghc-9.6.6 ... in the cabal build core step).

[endgame]

Thank you for taking this on. I'm not the best at GHA so I'd been avoiding it.

I'm in the middle of a house move and I'm not sure if this PR is completely ready to go but in the interest of not losing momentum I wanted to give it at least a once-over. I'll try to be responsive but if I go silent, please ping.

As for your goal of fixing #1037. That's going to be a substantial amount of work, because we are stuck on an old pin of botocore. We can't advance botocore because if we do, we break the generation of existing libraries. The generation of existing libraries is brittle because we use a Ptr type to break cyclic references in the generator (because the generator usually resolves references by inlining), and a Ptr doesn't contain enough information for the generator to correctly calculate the set of instances a type needs to have (see #888 for the gory details). I've written up my vision for carving off an "output" layer to make the gnarlier bits of the generator to work on. If you're interested, those notes are at #1058.

[endgame]

Can you please explain what is forcing you to add the extra packages? I haven't needed them even when running NixOS (which is where I expect the most shenanigans around paths). If there's something wrong with the GHC you get when you use Nix as a package manager on a standard distribution, I think setting up the right ghcWithPackages calls to wire in the native libraries is probably going to work better, but I want to know what the thinking is before I insist on that change.

[jhrcek]

I'm still iterating on this (and learning ins and outs of nix along the way), but TBH I initially just let claude-code thrash around to make the build pass. It seems to have found a fix which however has bunch of unnecessary stuff. Based on your remark I pushed it harder into making it demonstrate to me that all the changes are actually necessary and managed to trim it down to just this PKG_CONFIG_PATH declaration below. I still want to look around to see how people using nix + zlib do it in their projects, but this seems to be necessary to avoid linker picking the zlib1g-dev package that comes pre-installed on ubuntu github action runners.

[endgame]

Please also add an entry in lib/amazonka/CHANGELOG.md, section Fixes, as this is the primary changelog for the project and it's good to get credit for a thankless task.

[jhrcek]

Thanks for the initial feedback and staking out the path that would need to be followed towards making bedrock lib(s) available. I'm learning nix as I go but I'd like to also try to fix the macos job as part of this PR. Consider this still WIP.

[jhrcek]

@endgame I consider this ready for review.
You can see the 3 linux configurations passing in my fork.

I tried to fix the macos-latest build too, but that will probably require bumping to more recent version of ghc in the macos job. Still I think this PR is worth merging as it's better to have at least some end-to-end build in CI than none.

I fell down the rabbit hole of trying to bump the dependency versions in flake.nix, but got tons of failures, because package sets we're getting generally require newer version of hashable, which I saw is problematic.

It looks like the gen improvements will have to be implemented first before we're able to untie this Gordian knot and bump to newer nixpkgs / ghc versions in CI.

I'll start looking into how the gen stuff works to see if I can contribute in meaningful way.