> On 2. 12. 2021, at 19:09, Nir Soffer <nsof...@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/790e6b79e756de24ef5134aa583bea46e7fbbfb4/.github/workflows/ci.yml#L32 > > 2. Every build creates a repo in exported-artifacts > https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e7fbbfb4/ci/rpm.sh#L7 > > 3. Every build uploads the exported artifacts to rpm-{distro}.zip > https://github.com/nirs/ovirt-imageio/blob/790e6b79e756de24ef5134aa583bea46e7fbbfb4/.github/workflows/ci.yml#L53
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-le...@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/K46FB3JIV6HALXJKC3MARNHDWHAXPG5K/ _______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-le...@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/VWVEKLOM5OVM7E632BATLL3YOD762MVE/
