Remove unused ubuntu packages to avoid running out of disk space

[teodanciu]

when building nix derivations

Description

Checklist

• Commit sequence broadly makes sense and commits have useful messages
• New tests are added if needed and existing tests are updated
• When applicable, versions are updated in .cabal and CHANGELOG.md files according to the
  versioning process.
• The version bounds in .cabal files for all affected packages are updated. If you change the bounds in a cabal file, that package itself must have a version increase. (See RELEASING.md)
• All visible changes are prepended to the latest section of a CHANGELOG.md for the affected packages. New section is never added with the code changes. (See RELEASING.md)
• Code is formatted with fourmolu (use scripts/fourmolize.sh)
• Cabal files are formatted (use scripts/cabal-format.sh)
• hie.yaml has been updated (use scripts/gen-hie.sh)
• Self-reviewed the diff

[aniketd]

I rebased this since the jobs had failed on account of some downloads failing (most likely during the time GitHub services had degraded recently). Hopefully now these jobs will pass. 🤞

[lehins]

Don't merge until #3697 is merged

[teodanciu]

Also, the requested changes have to be approved before merging - are you happy with the changes @angerman ?

[angerman]

So am I understanding this right, we are building .#hydraJobs.required on GHA? Don't we build that exact derivation on hydra anyway for each commit already? So then the jiggly job would only end up pulling all the prebuilt stuff from hydra?

Sorry, I'm a bit confused what we do here 😵‍💫

[teodanciu]

So am I understanding this right, we are building .#hydraJobs.required on GHA? Don't we build that exact derivation on hydra anyway for each commit already? So then the jiggly job would only end up pulling all the prebuilt stuff from hydra?

Sorry, I'm a bit confused what we do here 😵‍💫

No, it's good you're asking, because you're probably right that it doesn't make much sense.
So, the initial idea was this: because our CI doesn't use nix, it sometimes happened that after a change that successfully passed CI and got merged, we couldn't enter nix-shell (because the change had broken the nix build).
So we just wanted to add something that runs a nix-shell (as it was back then before flakes). This was after the original hydra got decommissioned.
Then after the transition to flakes, this job has evolved a little bit, and indeed it makes sense what you're saying, it doesn't make sense to just pull prebuilt hydra stuff.

Does it still make sense to check that nix develop works, what do you think ?
We're building the jobs on hydra now as well, I see, so maybe we can make that check mandatory for merging. I guess if nix develop would not work, then that build would maybe break too?

[angerman]

So am I understanding this right, we are building .#hydraJobs.required on GHA? Don't we build that exact derivation on hydra anyway for each commit already? So then the jiggly job would only end up pulling all the prebuilt stuff from hydra?
Sorry, I'm a bit confused what we do here 😵‍💫

No, it's good you're asking, because you're probably right that it doesn't make much sense. So, the initial idea was this: because our CI doesn't use nix, it sometimes happened that after a change that successfully passed CI and got merged, we couldn't enter nix-shell (because the change had broken the nix build). So we just wanted to add something that runs a nix-shell (as it was back then before flakes). This was after the original hydra got decommissioned. Then after the transition to flakes, this job has evolved a little bit, and indeed it makes sense what you're saying, it doesn't make sense to just pull prebuilt hydra stuff.

Does it still make sense to check that nix develop works, what do you think ? We're building the jobs on hydra now as well, I see, so maybe we can make that check mandatory for merging. I guess if nix develop would not work, then that build would maybe break too?

Right, so pretty much every PR already runs the required job on hydra (you can see the required job being built on this PR as well. If it includes the devShell from the flake in the required property, then it will always be built.

You may also consider dropping the shell logic altogether from hydra, and using e.g. https://github.com/input-output-hk/devx as a way to obtain a development shell with IOG libs, and tools. That one, by being independent of the repo, doesn't risk getting accidentally broken by changes to the repo. The downside is that you potentially have to rebuild a tiny bit more as it doesn't come with any hydra dependencies pre-cached. (Yet; this is on the roadmap but likely will take quite a while, and cabal-cache is a good substitute).

[lehins]

We're building the jobs on hydra now as well, I see, so maybe we can make that check mandatory for merging

That's not going to happen until I have full confidence in hydra. Throughout my time at IOG every CI setup (hydra, cicero, BuildKite) that was on anything other than Github Actions has always had problems, sometimes only intermittent, but still problems, which often blocked PRs from being merged, potentially for days.

I'd be totally happy to not doing any nix stuff on GithubActions and run it on hydra only. Important part is that we still do get results from Hydra, so if there is some issue, we'll notice it. It is just not going to block us from moving forward.

[teodanciu]

I'm going to close this PR, since it became clear that this is a questionable solution to a seemingly non-existent problem.
When the time comes for nightly builds to matter, I will remove the nix derivation building from it.
Good to know about input-output/devx, will look into into, thanks @angerman .