Use dockerised versions of Ligo

[purcell]

Building Ligo from scratch with Nix is impractical given the upstream abandonment of nix support, so we need to use pre-built Ligo executables. Currently only x86_64 linux binaries are available upstream. This is a particular problem for MacOS users with M1 processors (me, Derek), where Docker prefers ARM images, ie. linux-arm64.

Additionally, we would like to patch our Ligo until https://gitlab.com/ligolang/ligo/-/issues/1227 is resolved.

The suggested way forward is to create a minimal fork of the upstream Ligo repo in this github org, with the patches applied, and then build both arm64 and x86_64 docker images into the github repo's container registry. Building can be done manually for now, offline. Automation of all builds would be hard to achieve due to lack of arm64 support in GitHub Actions.

With images built, we can start using the dockerised version of Ligo in our local builds.

---

Done so far:

Created a fork at https://github.com/tezos-checker/ligo, with our patch applied.

To obtain permissions to push new images, follow the guide to set up push access: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

To build multi-arch images, see the docker buildx info as a little initial set-up may be necessary.

touch changelog.txt
docker buildx build --platform linux/amd64,linux/arm64 -t ghcr.io/tezos-checker/ligo:0.22.0-checker --push .

To-do:

Use the docker image in the build-ligo script. This isn't working for me out of the box:

ruby ./scripts/compile-ligo.rb
Compiling contract.
File "/Users/steve/Projects/tweag/nomadiclabs/checker/scripts/../generated/ligo/checker.mligo", line 94, characters 34-51:

Invalid entrypoint value.
The entrypoint value must be a string literal.
Traceback (most recent call last):
./scripts/compile-ligo.rb:26:in `<main>': compile-contract failed: (RuntimeError)

^ Have you seen that before, @utdemir?

[utdemir]

Have you seen that before, @utdemir?

I haven't seen that, but had a look at it and saw that it caused by a recent ligo change.

Updating ligo reproduces it on current master too. We were passing a top-level constant as entrypoint name which is now disallowed, so I made a commit to inline it.

[gkaracha]

Hm, that's a pity. This recent change is not only unnecessarily restrictive, but also it makes it harder to change the oracle entrypoint name later. This is supposed to be somewhat pluggable, since different checker instances will be attached to different oracles, using perhaps different names. Well, it's what it is I guess :shrug: Nice work tracking it down @utdemir anyway :+1:

[purcell]

Yeah, good catch. I had based the docker image on the current dev branch, but it would be easy enough to go back to the actual 0.22.0 tag from 3 weeks ago, which would presumably avoid that change. Though obviously it's an issue we'd hit sooner or later.

[purcell]

Argh, docker build fails with 0.22.0. There must have been a fix in the last few weeks!

[purcell]

Not that it matters, Utku's workaround seems to solve that particular problem.

[dorranh]

Since we're now using the Dockerized version of Ligo (#245), I think the only open item related to this issue was to document the build instructions outlined above. I've ported them over to the ligo fork's README now, so I'm going to go ahead and close this.

https://github.com/tezos-checker/ligo/commit/a7fa6d848e09ca546331df827caa48b2d7925dff