Update dhall-openapi

[WillSewell]

Updated dhall-openapi to include changes in dhall-lang/dhall-haskell#2128, and regenerate all of the configuration.

This introduces breaking changes in the generated dhall config.

[TristanCacqueray]

Assuming the hydra job succeed, that looks correct. Thanks!

[WillSewell]

It looks like the libuv build failed due to libuv/libuv#2468. I'd like to rerun the build, but I'm not sure how.

[WillSewell]

I'm not sure what is wrong with the hydra build. It tried to rebuild, but it it failed with the same error. However it says the failed build step "propagated" from another build, which makes me think it might have cached the failure. Do you know how I can clear the cache? I'd appreciate any help here because I have almost no experience with Nix or hydra.

[Gabriella439]

@WillSewell: Yeah, I triggered the rebuild. I'm still investigating what is going wrong. I'm not entirely sure that it is a cached failure, though.

[Gabriella439]

Hmmm, it looks like it just needed to be restarted yet again. I suppose it's just a flaky test. Either way, that specific problem is fixed.

However, it looks like there is a new problem, which is that the changes to the ./nix/kubernetes/*.txt files don't match what Nix is getting. I believe you will want to revert the changes to those files since I believe the original hashes are the correct ones.

My guess is that there might be a subtle difference in the behavior of nix-prefetch-url across different Nix versions or operating systems. For reference, I tested with Nix 2.3.3 and I got the same hashes as the ones on master.

[WillSewell]

Thanks for investigating this.

I'm using Nix 2.3.10, so the behaviour potentially could have changed, though it surprises me that different patch releases might generate different hashes. Anyway, I've reverted the modification of the hashes. I'd like to try switching my version of nix locally, but I'm docker so it will take a long time for nix rebuild everything 😬

[WillSewell]

I can't seem to trigger a Hydra build of this branch. It looks like the most recent build of this branch was at 2021-01-14 17:34:06 - the most recent commit was pushed at 20:25.

The build steps in the most recent build failed with Aborted: �[31;1merror:�[0m�[34;1m --- SysError --- hydra-queue-runner�[0m creating directory '�[33;1m/var/lib/hydra/build-logs�[0m': �[33;1mPermission denied�[0m. That doesn't look right, but I'm not sure if it's related...

[Gabriella439]

@WillSewell: Yeah, I recently pushed a change to upgrade the machine, which is the reason for that failure. I plan to fix it tonight

[Gabriella439]

So I fixed that issue, but now I'm seeing the exact opposite issue as before: after the upgrade it seems to expect the opposite hash (i.e. the one you had in your pull request), as opposed to the hash on master. This seems to confirm that newer versions of Nix or Nixpkgs hash things differently.

If you regenerate the ./nix/kubernetes/*.txt files by just running the first step of ./scripts/add-kubernetes-release.sh then this branch should be good to go.

[WillSewell]

Ok I've tried that in the most recent commit.

However I'm not sure the triggering of builds for the dhall-kubernetes:158 jobset is working. i.e. pushing new commits doesn't seem to have any affect. Do you know why this is? Maybe it needs to be manually triggered...

[Gabriella439]

@WillSewell: It's because the permissions issue due to failure creating /var/lib/hydra/build-logs resurfaced again. I just fixed the permissions again, but it seems to occur whenever hydra is upgraded.

All I know at the moment is that the hydra-init service is supposed to be setting the permissions on these directories correctly (indeed: simply re-running the hydra-init service fixes the problem).

[WillSewell]

Ok, thanks for merging and clarifying what the issue was!