Adapt pipelines

[hannesm]

on top of #36, only the last commit is relevant.

[hannesm]

/cc @samoht I've no clue whether the last commit does what I have in my brain (and unfortunately no way to test it, since "ocurrent" still doesn't work on FreeBSD), but this may solve mirage/mirage-skeleton#364 (comment)

[samoht]

@hannesm if you are interested to test the FreeBSD support, you can find some notes here: ocurrent/obuilder#109 (comment)

[hannesm]

@hannesm if you are interested to test the FreeBSD support, you can find some notes here: ocurrent/obuilder#109 (comment)

I've no time to read and understand "ocurrent", sorry. I have something else that satisfies my needs (for reproducible builds, working on Linux and FreeBSD; code is roughly 2 orders of magnitude less than ocurrent*).

[hannesm]

To briefly describe what my intention is: there is a synchronization / compatibility of some repositories:

• the latest release of mirage to opam-repository should always work with mirage-skeleton on the main branch
• the main branch of mirage should work fine with mirage-skeleton on the dev branch

This means, we need to configure two CI systems:

• whenever something is PR'd on mirage-skeleton for the main branch, the first CI should be running (or when the opam-repository gets a new mirage release)
• on PRs (and merges) to the mirage main branch, the second CI system should be running. this as well is true for the case that there's a PR to the dev branch of mirage-skeleton

The mirage-dev overlay is a place to put some more packages, useful only for the second CI.

I've no good idea / feeling about how "ocurrent" decides what to execute, that's why I wrote the above comment. I'm pretty sure there's someone who understands the systems in place and can comment on how to achieve such a setup. The previous setup was a mix of the two: the mirage main branch was attempted to be compatible with mirage-skeleton on the main branch -- but this is actually not what we aim for.

To make it more clear:

• from a user perspective, they'll opam install mirage and expect the git clone of mirage-skeleton to just work [tm]
• from a development perspective, we're interested that our mirage development works fine with mirage-skeleton examples (on the dev branch since sometimes we break the API, and that is fine).

At any release point, we'll just merge the dev branch of mirage-skeleton into the main branch, and voila, the user experience is fine.

Thanks for reading :)

[samoht]

Suggested change

	{ org = "mirage"; name = "mirage-skeleton"; branch = "main" };
	{ org = "mirage"; name = "mirage-skeleton"; branch = "dev" };

[samoht]

I've deployed this branch + the s/main/dev fix to live and it seems to work as expected.

The way to test it (deploy it in production) is not great, as the local CI still needs network access (and currently doesn't work in macOS due to a hacl* hitting an llvm bug but that's another story). It would be nice to make it work without network access (by considering local Git clones). I've opened #41 to track this.

See mirage/mirage-skeleton#378 (for stable) and mirage/mirage-skeleton#377 (for dev).

[hannesm]

Thanks @samoht. I'm a bit puzzled how to move here -- I guess the main thing I find strange is that there's a "main" and a "live" branch in this repository, and somehow the "live" is the one that matters. So why is there a main branch?

Should we reconcile, make the "live" branch the default one, and get rid of the "main" branch (and also close this PR, since it is merged into "live" already)?

[hannesm]

Whatever it takes, seems this is deployed. I'll close it. Feel free to resort your branches.