First steps failed when trying dhall for gitlab-ci

Hey everyone,

I’m new here, working together with @Lee_Hambley. We both really like dhall and specifically want to use it to generate our Gitlab CI YAML files, because they have reached a level of complexity that is hard to deal with in plain YAML.

Unfortunately, my first experience with dhall is frustrating. Here is the series of steps I’ve been through:

  1. Learn about dhall and get excited
  2. Install dhall
  3. Search for a dhall-based solution to my problem and find it :rocket:
  4. Copy-paste the example from the README and hit a wall :sob:

:question: why does the import fallback in the Prelude.dhall not work?


:exclamation: the import integrity check fails when importing the Gitlab module, but I don’t see the reason why:

:; export DHALL_PRELUDE=''
:; dhall-to-yaml-ng --file .gitlab-ci.dhall


Error: Import integrity check failed

Expected hash:

↳ 0c04cbe34f1f2d408e8c8b8cb0aa3ff4d5656336910f7e86190a6d14326f966d

Actual hash:

↳ 10db3c919c25e9046833df897a8ffe2701dc390fa0893d958c3430524be5a43e

24│ sha256:0c04cbe34f1f2d408e8c8b8cb0aa3ff4d5656336910f7e86190a6d14326f966d

This is also detailed in this issue on Github:

But the Prelude.dhall file explicitly has a fallback without the integrity check:

? sha256:0c04cbe34f1f2d408e8c8b8cb0aa3ff4d5656336910f7e86190a6d14326f966d

What happened

Setting DHALL_PRELUDE apparently had no effect, so it fell back to the first import, which fails due to the failed integrity check and then execution stops.

What I expected to happen

The final import without the integrity check is executed and works, since there is no integrity check.

This sounds pretty similar to:

… which was fixed in version 1.41.0 or later of the Haskell implementation of Dhall. Double-check that you’re using that version or newer.

The environment variable import only works for files that were imported locally (i.e. not GitHub repositories), which is why that workaround did not work. Something like env:DHALL_PRELUDE ? … is only useful for local development.

Oh wait, sorry. I was mistaken. That bug and resolution fixed the output of dhall freeze --cache, but didn’t change how imports were actually resolved.

The actual issue here is that in version 21.0.0 of the language standard the ? operator no longer falls back in the event of a hash mismatch so the idiom of https://foo sha256:… ? https://foo is no longer correct. While the output of dhall freeze --cache was changed to adjust, existing repositories in the wild (such as dhall-gitlab-ci) that used the old idiom are now broken in the way you just described.

The fix here is that you would need to submit a patch to amend the Prelude.dhall file to:

? missing sha256:0c04cbe34f1f2d408e8c8b8cb0aa3ff4d5656336910f7e86190a6d14326f966d

… and probably also fix the hash along the way

First of all, thank you for the prompt reply!

A change of the behavior of ? explains the problem, thank you!

I’m on a very recent version of dhall:

:; dhall --version

The gitlab-ci repository looks pretty inactive. We’ll see how far we take this at work and might publish a fork with all of the fixes applied if we end up using it enough.

I’ve linked your answer to the issue on Github

1 Like

Indeed. That’s we had to do.

Here’s a Prelude.dhall where that’s fixed.