Skip to content

ci(interpreter): update setup-ocaml to v3 for ubuntu-24.04 - #165

Open
matthargett wants to merge 1 commit into
WebAssembly:mainfrom
matthargett:ci-setup-ocaml-v3
Open

ci(interpreter): update setup-ocaml to v3 for ubuntu-24.04#165
matthargett wants to merge 1 commit into
WebAssembly:mainfrom
matthargett:ci-setup-ocaml-v3

Conversation

@matthargett

Copy link
Copy Markdown

The interpreter job fails on every interpreter/** and test/** PR because ocaml/setup-ocaml@v2 unconditionally apt-get installs darcs, which Ubuntu 24.04 "noble" (now ubuntu-latest) no longer ships:

E: Package 'darcs' has no installation candidate
##[error]The process '/usr/bin/sudo' failed with exit code 100

The job dies during environment setup, before the OCaml interpreter is ever built.

Fix

Bump ocaml/setup-ocaml@v2@v3. v3 probes for darcs with apt-cache search '^darcs$' and treats it as optional — opam simply notes that darcs repositories won't be usable and continues — instead of hard-failing the apt install. OCaml 4.12.x and every tool pin are left unchanged, so the build and test steps run exactly as before; only the environment setup is repaired.

Evidence

The sibling WebAssembly/threads proposal repo already runs this exact configuration (setup-ocaml@v3 + OCaml 4.12.x) green on noble — its setup step probes darcs with apt-cache search and installs ocaml-base-compiler.4.12.1 cleanly.

This unblocks all pending interpreter/** / test/** PRs (e.g. #164).

The interpreter job fails on today's ubuntu-latest (24.04 'noble'): ocaml/
setup-ocaml@v2 unconditionally apt-get installs darcs, which noble dropped
("E: Package 'darcs' has no installation candidate"), so the job dies in
setup before the interpreter is ever built. setup-ocaml@v3 probes darcs with
'apt-cache search' and treats it as optional, so opam init/switch succeed.

OCaml 4.12.x and all tool pins are unchanged, so the build and test steps run
exactly as before. Mirrors WebAssembly/threads, which already runs green with
this same configuration on noble.
@rossberg

Copy link
Copy Markdown
Member

This proposal has long been merged, and the repo should probably have been archived. Is there any reason why you'd want to open PR's here instead of the upstream repo?

@matthargett

Copy link
Copy Markdown
Author

This proposal has long been merged, and the repo should probably have been archived. Is there any reason why you'd want to open PR's here instead of the upstream repo?

so that if anyone else was implementing the feature, they'd have a conformance suite to help prevent the same class of bug I backed into. the CI on #164 isn't passing, which I thought might be holding up the review/merge, so I took the step to (hopefully) get it green in a discrete PR. just trying to do right by the open standards community :)

@rossberg

Copy link
Copy Markdown
Member

Well, all tests from this repo have been merged, too. If you discover issues with the tests, please open PRs upstream. Fixes done here would be lost.

@matthargett

Copy link
Copy Markdown
Author

Well, all tests from this repo have been merged, too. If you discover issues with the tests, please open PRs upstream. Fixes done here would be lost.

ok, I'm confused. is there a reason @ppenzin didn't mention this when he self-assigned the other PR? if you tell me which repo is actively maintained, I can relocate the PR(s) :)

@rossberg

Copy link
Copy Markdown
Member

Yes, sorry for not flagging this with your earlier PR already. As I said, this repo has been merged. All further activity should happen upstream in the main spec repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants