Elemental OBS Dev project in github

[davidcassany]

This epic is about migrating current OBS Dev project to github, keeping an automated generation of OBS sources (for now could be manually gated by manually merging autogenerated PRs).

• Create a new repository under rancher owned by the elemental-team. Requested in this EIO ticket
• Create OBS user bot to run OBS workflows
• Create a branch in upstream repositories with required adaptations (gitified branch)
  There are three types of recipes, RPM specs, Dockerfiles and Helm charts. Each obs package recipe must live under root directory following the scheme: .obs/<recipetype>/<obspkgname>. recipetype can be one of dockerfile|chart|spec. obspkgname must match exactly the OBS package name. This way the preparation of all OBS sources can be generalized by recipe type. Impacted repositories:
  • rancher/elemental-toolkit
  • rancher/elemental-operator
  • rancher/elemental-channels
  • rancher/elemental
• Use of semver translating - to ~ in RPM versions and translating + to _ for tags (Helm criteria).
  • Reconsider tagging scheme of our images to something like: <version>_<release>, note the underscore to match helm semver criteria. #27
• Create scripts to generate sources in rancher/elemental-obs. The builder can be based on the PoC in davidcassany/elemental-obs repository. Ideally there should be a generalized method to build each recipe type: chart, dockerfile or spec.
• Create a workflow to update sources in rancher/elemental-obs. The branches of the upstream repositories and the local repository could be managed with a yaml such as:

  dev:
  - repo: rancher/elemental-toolkit
    branch: main
  - repo: rancher/elemental-operator
    branch: main
  - repo: rancher/elemental
    branch: main

  Where objects in root are the rancher/elemental-obs branches containing a list of repository and branch pairs to checkout the sources from. The workflow could create/update a PR to update sources. The workflow could be run on scheduled basis and on manual dispatch.
• Set a meaningful process for *.changes generation. Would be desirable having a dual setup:
  • Automated process for RPMs such as toolkit and operatior
  • Manual or semi-automated and enforced method for images (suggestion is to find out how this is handled at SUSE/BCI-dockerfile-generator)

[davidcassany]

Closing the card as it already accomplished and the small missing pieces around semver adoption are tracked in separate cards