Goal:

• Image definitions, and libraries for image building and invoking osbuild are extracted to a separate image-definitions git repository. osbuild-composer consumes this repository as a dependency.
• The dependency is updated regularly by a bot
• The new repository is now responsible for functional tests of the images: build, upload and validate.
• osbuild-composer doesn't run all the functional tests on every PR.
• The new repository carries the whole history from the osbuild-composer repository.

Acceptance Criteria:

• The functional tests of images are no longer performed via the cloud/weldr API.
• osbuild-composer (jobqueue, APIs, weldr store) is a separate repository from image-definitions (image-defs, upload code, osbuild API client).
• The new structure is demoed.

Open questions:

• Is image-definitions a good name for a repo that contains also the uploading code?
• What to do with the tests in osbuild-composer? They should focus on the jobqueue and APIs, not on image building and functional tests?

• • What to do with the nightly pipeline?
• What to do with RPM release notes in osbuild-composer? They will no longer contain any notes about image definitions. Is that an issue?

Proposed steps:

1.  ** Untangle the dependencies between go packages that will be extracted (distro, upload, osbuild). We cannot have any dependencies from image-defs to composer. We already know that the blueprint package is an issue.
2. Build a go wrapper that can build, upload and test an image. Something like osbuild-pipeline or osbuild-playground is probably the goal.
3. Create a new repository for image-definitions with the extracted packages and the go wrapper that's used as a new way to test these the definitions.