On 2. 12. 2021, at 19:09, Nir Soffer <nsoffer@redhat.com> wrote:

Looking this very helpful document https://ovirt.org/develop/developer-guide/migrating_to_github.html

The suggested solution is to create artifacts.zip with all the rpms for a project.

But to use the rpms in OST, we need to create a yum repository before uploading the artifacts, so we can pass a URL of a zip file with a yum repository.

Here is what we have now in ovirt-imageio:

1. We build for multiple distros: https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e...

2. Every build creates a repo in exported-artifacts https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e...

3. Every build uploads the exported artifacts to rpm-{distro}.zip https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e...

Yes, something like this looks ideal. The only thing I'd like to get to is a common organization-wide template or action so that we do not have to reimplement this in every single oVirt project.

An example build: https://github.com/nirs/ovirt-imageio/actions/runs/1531658722

To start OST manually, developer can copy a link the right zip file (e.g for centos stream 8): https://github.com/nirs/ovirt-imageio/suites/4535392764/artifacts/121520882

And pass the link to OST build with parameters job.

In this solution, OST side gets a repo that can be included in the build without any additional code or logic - just unzip and use the repo from the directory.

We plan to add this to OST directly, we currently have a helper code that handles stdci's jenkins repos, we can implement similar functionality for GH's zip files

I think this is the minimal solution to allow running OST with built artifacts from github.

For triggering jobs automatically, we will need a way to find the right artifacts for a build, or use some convention for naming the artifacts in all projects.

yeah, so probably a common oVirt's action that does the repo creation and is used by all projects would do the job...

I started with the simple convention of jobname-containername since it is easy to integrate with the infrastructure we already have in the project.

Nir _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-leave@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/devel@ovirt.org/message/K46FB3JIV6HALX...