OCurrent 0.1 has just been released to opam-repository.
OCurrent is an OCaml eDSL intended for writing build/test/deploy pipelines. It is being used as the engine for ocaml-ci and the docker-base-images builder (used to build the OCaml Docker images, such as ocurrent/opam:alpine-3.10-ocaml-4.08). Other good uses might be building and redeploying a Docker service or a unikernel whenever its source repository changes. It can be run locally as a single Unix process.
An OCurrent pipeline is written as an OCaml program, but the OCurrent engine ensures that it is kept up-to-date by re-running stages when their inputs change. A web UI is available so you can view your pipeline and see its current state.
OCurrent can statically analyse the pipelines before they have run, allowing it to run steps in parallel automatically and to display the whole pipeline. It does this using a light-weight alternative to arrows, which doesn’t require programming in an awkward point-free style. See CI/CD Pipelines: Monad, Arrow or Dart? for more about that.
The basic functionality can be extended using “plugins” (just normal OCaml libraries). Plugins are available for interacting with Docker, Git, GitHub and Slack. These are in separate packages (e.g. current_github) to avoid having the base package pull in too many dependencies).
There is also an optional Cap’n Proto RPC interface, in the current_rpc opam package. This is used, for example, by citty to provide a TTY interface to ocaml-ci.
The OCurrent wiki contains examples, and documentation on the various plugins.
Here’s an example pipeline (from the base image builder):
For those curious about the relation to the existing CI used in opam-repository, then it is no coincidence that @talex5 is the author of both
This DSL is the next iteration of the datakit-ci, but specialised to be faster and simpler for extending with OCaml and more complex workflows that our OCaml Platform tools need these days (like ocamlformat linting, or dune expect promotion, or odoc cross-referenced doc generation). We are planning a smooth migration next year over to the new system, but wanted to release this early to show you some of the pieces going into this new iteration. I am particularly excited about the new tty-based interface that saves an awful lot of clicking around on web UIs for CI results…
docker-slim is pretty much the opposite of what a CI/CD system needs: it does runtime analysis within a container to remove unused dependencies. So it’s something that an end user application would use, not images for CI/CD.
current.mli contains an Unit module (type t = unit), which appears to be designed to pass to functors expecting a comparable/hashable type, with a note saying: “Missing from the OCaml standard library”. Have you considered proposing it for inclusion in the standard library?
I have a more high-level question, which is: I would be interested in a somewhat generic “job” abstraction, that I could use to describe computations, and then run them (benefitting from parallelism for computations that release the runtime lock), facilities to persistent intermediate results (or error logs), and to rerun jobs (recomputing only the parts that have changed). Your DSL is currently specialized to the CI/CD use-case, but how far is it from a generic “job” DSL?
(My question also sounds like Incr(emental), and maki, and a build system. Is there a clean reusable abstraction that I could use, rather than an encoding in some more complex system?)
current.mli contains an Unit module ( type t = unit ) […] Have you considered proposing it for inclusion in the standard library?
Looks like Unit has been added to the stdlib already (since 4.08)
Your DSL is currently specialized to the CI/CD use-case, but how far is it from a generic “job” DSL?
It’s already pretty generic and should do what you want. At the moment, it works best when the jobs are relatively large (e.g. each job takes seconds to hours to run) and re-evaluating what it needs to do therefore doesn’t add much overhead. Ideally it would use something like incremental/react internally to make that more efficient.
Yes, but I have never looked at the details, how nice this part of the API is (if it’s just a deep layer in the middle of dune, it doesn’t need to be made particularly nice), and as far as I know (I asked a couple times) there are no plans to make it an independent library for other use-cases.
