-
Notifications
You must be signed in to change notification settings - Fork 76
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
"experimental" "variants" #858
Comments
I got some replies in ocurrent/opam-repo-ci#230 (comment) and am closing this, looks like there's not much to say here. |
I'll copy my longer response here for general documentation. @hannesm the use of the experimental label is somewhat overloaded as you've noticed. The main functional purpose is to introduce new types of builds without breaking existing project's CI. For example we introduced FreeBSD support for all projects that claim to support it via their opam configuration but in reality some don't properly support it and/or our FreeBSD infrastructure is not considered stable yet. Another other type is for pre-release compilers or opam versions, to help provide visibility of future changes and let library authors prepare for those releases. One further type is linting builds that probably should be looked into as failures but currently aren't. So we have these types of builds all reported under experimental:
Of those 1 has a clear path to being moved out of experimental, once we are happy with the stability of the underlying infrastructure and have sufficient capacity they will move to non-experimental builds. At that point project builds will fail if they fail on that platform. 2 (Pre-release OCaml/Opam) will probably always stay as experimental but perhaps we can use a different label for them. Pre-release or Preview, I am open to suggestions. 3 is tricky because that is the most opinionated type of build and not all projects work well with lower-bounds checks for example. There is clear scope for improving these checks and we would consider moving them out of experimental once most projects pass these builds.
experimental builds should not fail CI for a project, if they do that's a bug and it should be reported.
Yes, we try to provide a stable CI service on https://ocaml.ci.dev. Please report issues against this repo. |
Thanks. Just in case that's not yet known, but since several hours (days?) the OCaml CI is not running and ocaml.ci.dev is not reachable. I tried status.ocaml.org (as hinted in ocaml/infrastructure#31), but that doesn't exist yet it seems. Have a nice weekend, I hope it's something simple that turned ocaml CI off. |
I have restarted the web service and it looks back to normal now. |
Thanks a lot @mtelvers. Is there any post-mortem on what caused the service unavailability? |
Dear Madam or Sir,
I notice there are some jobs that are marked as "experimental", some of which are pre-releases of the OCaml compiler; while others are specific operating systems.
How comes that these two are intermingled? And is there a process (and document thereof) how/when they will raise out of the experimental pod? Is the build status indication related to stuff marked as experimental (i.e. overall it'll be green even if all experimental builds fail)?
Thanks for reading and your support for the OCaml community. Is OCaml-CI itself considered to be stable?
The text was updated successfully, but these errors were encountered: