OBS shut down and next steps

General
31

To sum up the problem:

  1. OBS can be seen as a CI
  2. OBS provides a RPM package repository (as CD)
  3. building of RPMs is done via RPM SPEC files that optional references dependencies from the custom build RPM repository, re-building a package will trigger all dependencies to rebuild.
  4. you can chose different build targets (arm, amd64)
  5. you can chose different releases (SFOS 3.3.x, 3.2.x)

Replacing this with an alternative solution would mean to provide two components: CI/CD system and repository service.

RE 1:
There are many CI/CD tools around (Jenkins, Travis, Drone, Concourse-CI). The build-pipeline per package could be scripted into CI files, i.e. downloading coderus docker image, pulling source code from github as ressource, building within docker env and pushing final RPMs into repository ressouce.
However the build job order must be resovled by the developer himself, i.e. root packages first then building child packages and so on.

That being said someone must provide the CI/CD infrastructure to solve this part of the problem.

RE 2:
That part of the story must be provided by some service provider (Github, Gitlab) or setup in the build pipeline, i.e. the creation or update of the required repository meta files will be triggered as a pipeline job on the repository. A basic http or S3 server repository will not solve this problem as “createrepo” command must be triggered locally to build the index files for all provided RPMs. A custom solution with some kind of API must be provided for CD to trigger this repository creation step.

RE 3:
If 1 and 2 are in place this should work (depends on the defined pipelines).

RE 4:
Docker build env provides both targets so arm and amd64 are supported.

RE 5:
CI scripts can define different target pipelines pulling the tagged docker image for the required SFOS release.

Pros:

  • Docker-based CI guarantees clean builds
  • CI scripts can be hosted inside the git repo (one source of truth also for the source code as you don’t need to clone a local copy into OBS)
  • Build process for independant RPMs can be parallized if there are multiple worker nodes
  • Pipelines allow dependencies, i.e. some staging job like a testcase fails so the complete pipeline will stop
  • Supports different resources for input and output (Github, Gist, S3 …) of source code and builds
  • more control for the developer as he defines the pipelines and what should be done
  • use a CI/CD tool that fits the job (CI/CD tool maintenance should be much lower than full OBS setup)

Cons:

  • more scripting (pipelines, shellscripts) needed
  • will take some effort to migrate packages to CI/CD pipeline
  • needs an external repository with some createrepo magic that can be triggered via CI/CD or service provider offering this feature
  • decentralized (devs will host their own CI/CD + repository)

Verdict:

In the end it comes to the situation that community will have a fragmented build and repository space for non-harbour compliant applications.

Jolla should consider if:

  • hosting a community repository with createrepo task / API is feasible
  • providing a docker-based CI/CD for automatic build pipelines (much lower maintenance instead of OBS, community has centralized CI/CD and repository for their work). I personally would suggest Concourse-CI here.
2 Likes