Julia and Gitlab self-hosted : a state-of-the-art?

General Usage
, ,
22

I would recommend to use Releases | GitLab (with a generic package) for artifacts, i.e., with a separate GitLab CI job in the GitLab CI pipeline to circumvent the limitation of Artifacts not supporting authentication - by downloading the artifacts to a local (cached) path before the Julia jobs needing the artifacts run (and re-writing the paths of the artifacts to use the local ones) - e.g. using GitForge.jl if possible - or python-gitlab.

I have yet to implement this, though - but I believe it should work :innocent: :slight_smile:

I would support implementing this in a common Julia GitLab CI Templates repo., e.g. IHP Systems / Julia / Julia GitLab CI templates · GitLab (which could be moved to a common JuliaCI org.) - the aim of which is to support generic Julia package development on GitLab CI, including:

  • Support for different project types, e.g., packages, applications, registries, BinaryBuilder recipes, packages with Python dependencies, (and packages using private artifacts).
  • Support for best practices, e.g. testing (with multi-threading), formatting with JuliaFormatter, and analysis with JET, and Aqua.
  • Support for GitLab CI features like test reports, caching, “needs”, etc.
  • Extended support for Julia versions (e.g. the last two LTS versions, and the last two stable versions) - to support CI even for projects migrating from older to newer versions, e.g. from Julia 1.0 to Julia 1.6.
  • Support for Julia-supported platfoms (across architectures and operating systems) - using tags compatible with GitLab.com SaaS runners (a super set of those runner tags).
  • Versioned and stable - respecting semantic versioning.