Skip to content

Docker base image for dune pkg #12177

@Sudha247

Description

@Sudha247

Docker Base Image for dune pkg

With dune package management supporting managing packages, some projects have migrated to using dune pkg for deployment, e.g ocaml.org (ocaml/ocaml.org#3132), tarides.com (private repo). They don’t require to use opam for deployment. This is also in-line with the description of Dune as a frontend in the OCaml platform roadmap. As dune package management evolves, more projects might want to migrate to it. In this context, it will be useful to have a docker base image for dune pkg that doesn’t depend on the opam base images.

Possibilities

docker-base-images

docker-base-images is a CI pipeline that generates a bunch opam and compiler (opam + compiler switch) base images. See images generated. One possibility is to generate a base image for dune pkg with the same pipeline, as a different branch from opam. This was proposed in ocurrent/docker-base-images#326 and passed on as it complicates the pipeline and is perhaps better lived elsewhere.

Separate repository

I’ve prototyped here a Docker base image from scratch for dune-pkg - https://github.com/ocaml-dune/docker-dune. This way, the image generation lives outside in a separate repository and can be updated for new releases. The current prototype is very basic and only installs the lates Dune developer preview on alpine. If we were to follow this approach, will need to sketch out a plan for including widely used Dune versions and base images.

Push images with release

One approach I’d like to propose is to include Docker image generation in this repository’s CI. This can be done using GitHub Actions, as described here: https://docs.github.com/en/actions/tutorials/publish-packages/publish-docker-images#publishing-images-to-docker-hub.
The advantage over maintaining Docker images in a separate repository is that pushing new images would be part of the release process and wouldn’t require additional maintenance effort. We discussed this with @shonfeder and are inclined to take this approach for the ease of generating and maintaining images. Before we proceed, we wanted to check if anyone has thoughts on this.

Metadata

Metadata

Assignees

No one assigned

    Labels

    proposalRFC's that are awaiting discussion to be accepted or rejected

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions