Continous deployment workflow fails

[hannobraun]

The CD workflow on GitHub Actions fails: https://github.com/hannobraun/Fornjot/actions/runs/1899543863

It complains about some glibc version issue in the Linux/glibc job: https://github.com/hannobraun/Fornjot/runs/5335984400?check_suite_focus=true

The other jobs are aborted because of that one failure.

Since Rust 1.59 has been released very recently, I suspect that's what triggered the problem.

More observations:

• There are also warnings about rustfmt already being installed.
• All jobs are still called "Binaries", even though the workflow as a whole has been renamed to "Continuous Deployment".

cc @hendrikmaus, in case you want to take a look

[hendrikmaus]

I will take a look this weekend and update this issue with my findings.

[hannobraun]

Thank you, @hendrikmaus!

One thought: If 1.59 is the problem, we could just pin these workflows to 1.58 for now. This is what our rust-toolchain.toml does anyway, and it's probably not a good idea that CD uses a different version.

1.59 contains nothing we need, as far as I can tell, but disables incremental compilation, due to a bug. I think that makes it a good release to just skip.

[hendrikmaus]

I was just about to say: why does CD not adhere to the rust-toolchain.toml? The idea is that every contributor and every machine compiles using the same Rust version so that we can upgrade with more control.

In CI, we're using cross a lot, I will have a look at that more closely. Replicating the same command on my machine behaves differently:

• it adheres to rust-toolchain.toml
• therefore runs with rustc 1.58.1
• and still passes

[hendrikmaus]

All jobs are still called "Binaries", even though the workflow as a whole has been renamed to "Continuous Deployment".

We changed the workflow's name, but not the job's name inside the workflow:
https://github.com/hannobraun/Fornjot/blob/main/.github/workflows/cd.yml#L16

So that's no reason for concern. I'll get to that when putting my release process thoughts into code for #104

There are also warnings about rustfmt already being installed.

Acknowleged, will also keep an eye out for a fix of those.

[hendrikmaus]

tl;dr: Good news: it is not Rust's fault. I can compile using 1.59.0 locally just fine. The fault only occurs within the Linux container image that cross uses to compile for GNU Linux.

When compiling outside of cross' container, the rust-toolchain.toml is respected as planned as the GitHub runner (and our pipeline) use rustup. One can see that in the fornjot.yml build at https://github.com/hannobraun/Fornjot/runs/5337174261?check_suite_focus=true

As soon as I disable cross on the Linux GNU build, it behaves the same and passes. The musl target passed with cross enabled no problem. That is understandable, since glibc isn't involved. Aside: there is a bigger discussion around various versions of glibc popping up cross-rs/cross#455.

However, the cross calls still do not adhere to rust-toolchain.toml. That is very likely due to their container image not using rustup https://github.com/cross-rs/cross/blob/master/docker/Dockerfile.x86_64-unknown-linux-gnu. The toolchain config file only works for systems that use rustup to manage the toolchain.

---

I will open a pull-request that disables cross on the GNU Linux target; we do not need it there anyways. I am also looking into using zig cc for cross-compiling Rust binaries, but that is quite a complicated topic and I have a lot to learn to make progress.

[hendrikmaus]

You can also do it if you're currently working, set cross: false on this line https://github.com/hannobraun/Fornjot/blob/main/.github/workflows/cd.yml#L24

[hendrikmaus]

I'll check on how we can build the remaining Linux targets with a container that has rustup installed. I'll update over the course of the weekend.