Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

customized compiler distro? #863

Open
progman1 opened this issue Sep 4, 2023 · 5 comments
Open

customized compiler distro? #863

progman1 opened this issue Sep 4, 2023 · 5 comments

Comments

@progman1
Copy link
Contributor

progman1 commented Sep 4, 2023

can a customized ocaml distro be installed as the base compiler and repos
added on top?
would you be willing to add gcc cross-compile packages to the base OS together with Qemu?
can you support codeberg.org as a repo source?
can a github account for initial PR registratiion (or anything else) be avoided?

@tmcgilchrist
Copy link
Member

can a customized ocaml distro be installed as the base compiler and repos
added on top?

No that is not a goal of this project, we use a set of standard OCaml distros based off ocaml-dockerfile. The general intent is to support all Tier-1 supported platforms for OCaml plus the most common distributions. Right now we support Linux (x86, ARM, POWER, s390x), MacOS (x86, ARM) and FreeBSD (x86), with ongoing work to support Windows and Linux RiscV.

would you be willing to add gcc cross-compile packages to the base OS together with Qemu?

What kind of things would you want to do with that?

Can you support codeberg.org as a repo source?

It would be possible to add codeberg as a repo source, but we do not have plans to do it currently.
Technically we would need a programatic API for getting information about users/repositories and activity on repositories like git pushes, pull request creation and git branch create. It looks like https://codeberg.org/api/swagger#/ would cover some of that. I couldn't see an equivalent to GitHub's web hooks, which would make things more difficult and would require a polling loop.

If someone was interested in working on it I could help guide the implementation. A good starting point would be looking at https://github.com/ocurrent/ocurrent/tree/master/plugins/gitlab and try building a minimal example like https://github.com/ocurrent/ocurrent/blob/master/doc/examples/gitlab.ml

Can a github account for initial PR registration (or anything else) be avoided?

A GitHub (or GitLab) account is fundamental to how we query for repositories to build, interact with the Git Forge and receive web hook notifications.

@progman1
Copy link
Contributor Author

progman1 commented Sep 8, 2023

What kind of things would you want to do with that?

I originally approached the sandmark-nightly people with the idea of leveragnig their
amd64 hardware to do distro testing on that and other architectures via Qemu, but got nowhere in 9 months :

ocaml-bench/sandmark-nightly#119

... together with a bizarre message exchange with @shakthimaan.

But you mention the whole range of hardware for your service which would be great news if one was able to also input one's modified distro a'la sandmark-nightly,
as then no Qemu needed.

A GitHub (or GitLab) account is fundamental to how we query for repositories to build, > interact with the Git Forge and receive web hook notifications.

I was confused by the github-centric documentation as to whether one needed a github account in addition to a gitlab account.
So I think you're answer indicates that's not the case and so if a codeberg plugin were available, an account there would be sufficient.

With ocaml distro abstraction a non-goal perhaps a possibility is to overlay the installed
one with one's own via opam. I don't know whether that is possible but would you object to it in principle?

@MisterDA
Copy link
Contributor

MisterDA commented Sep 8, 2023

Note that you an also run ocaml-ci locally, on a git repository. It will track changes committed to the repository, and run its usual test suite. Try dune exec -- ocaml-ci-local --help.

@progman1
Copy link
Contributor Author

local? I don't have the hardware to do this which is why I am asking about your service.
but after sandmark-nightly, I am not sure now whether it is your own hardware or github's.
nevertheless, the question was whether, assuming it is possible for the user to specify
packages to install even up to a replacement ocaml-variant, you would be willing to have that done within your 'service'?

@tmcgilchrist
Copy link
Member

I was confused by the github-centric documentation as to whether one needed a github account in addition to a gitlab account.
So I think you're answer indicates that's not the case and so if a codeberg plugin were available, an account there would be sufficient.

A codeberg plugin would be mandatory then it would require some changes to ocaml-ci directly. Each GitForge type (GitHub, GitLab) has its own ocurrent pipeline. If codeberg support were to be added then a new pipeline would need setting up plus some ops stuff to plumb in the right deployment configuration. This all assumes there is sufficient interest in supporting Codeberg.

With ocaml distro abstraction a non-goal perhaps a possibility is to overlay the installed
one with one's own via opam. I don't know whether that is possible but would you object to it in principle?

ocaml-ci only consults the main https://github.com/ocaml/opam-repository for packages, so installing a different ocaml compiler would be difficult and working against the goals of ocaml-ci. The project is aimed at providing a zero config CI solution for OCaml projects using the metadata from opam, dune and a supported set of platforms (linux, macOS, FreeBSD).

I would suggest opening an issue on https://github.com/tarides/ocaml-jit/issues outlining in detail what you are trying to achieve and what resources are required (possibly restating some of what was included in ocaml-bench/sandmark-nightly#119).

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

No branches or pull requests

3 participants