chore: enable ocaml trunk job on ci

[Alizter]

This will have to be bumped with every new OCaml release, but AFAICT there is not way to generically rely on trunk, since the OCaml action works on the latest opam repo which doesn't have an entry for ocaml trunk without a version.

Should I make these jobs allow fail? I guess if the compiler team moves libraries around, this has a chance of breaking.

close #2298

[emillon]

One rule I like is that we should test something moving against something stable - for example dune main vs ocaml release, or latest dune release vs ocaml trunk - otherwise when something breaks it's difficult to determine who's at fault.

I don't think there's much value in adding that job. We're already proactive in adding canary tests for the next version of the compiler and adopting it in our tests. I'm not sure what kind of issues we would find with that extra job.

[rgrinberg]

We're already proactive in adding canary tests for the next version of the compiler and adopting it in our tests.

Where can I see our canary tests?

[emillon]

Since several releases, there's a readiness process put in place by the compiler team to make sure that some core tools including dune are compatible with it. It's not automated but I don't think it needs to be.
That being said, that's a change that's easy to revert so it's not a big risk either.

[Alizter]

What do we do about this then?

[rgrinberg]

I think it's useful. Yes, it's difficult to determine who is at fault, but at least we find out there is a fault right away and not months after the offending commit was merged.

I'll leave the decision to @Alizter. If he finds it useful, then we can merge. I would personally run at least the minimal set of the test suite that doesn't rely on any external dependencies as well though

[Alizter]

Let's keep it around for now.

I don't know how to run the test suite for just tests without external deps (we should add a makefile target for that, not sure how).

@rgrinberg can you merge when the CI is happy?