right now we need to build twice ovirt-node-ng for including the correct nodectl tool rpm in the image. Let's split the tool from the image creation process so we won't have to build node twice.
Yuval, Could you please help to verify this bug once the bug is fixed due to QE is not familiar with build process? Thanks.
The tool is already built as a subpackage. Can we change the ng-image job to only build some parts?
(In reply to Ryan Barry from comment #2) > The tool is already built as a subpackage. Can we change the ng-image job to > only build some parts? I'm not sure we can do this with current standard ci - it would mean adding parameters to the build job. Moving nodectl to different repository with its own build job sounds cleaner. @cshao, sure :)
(In reply to Yuval Turgeman from comment #3) > (In reply to Ryan Barry from comment #2) > > The tool is already built as a subpackage. Can we change the ng-image job to > > only build some parts? > > I'm not sure we can do this with current standard ci - it would mean adding > parameters to the build job. Moving nodectl to different repository with > its own build job sounds cleaner. @cshao, sure :) Thanks Yuval.
We're nearing deployment of STDCI V2 (I just merged the biggest patch today). One of the feature we're adding is sub-stages - which is to have more then one job (we call them threads, because they will not have 1-1 relation with Jenkins jobs any more) run in parallel for a given STDCI stage. We also intent to add conditional logic so that the 'threads' that run can be decided dynamically based on the files that were changed. Will these kinds of capabilities remove the need to split the repo?
Not sure it helps, perhaps I dont understand, I'll try to explain our problem - the "image-build" job needs to pull in packages from the ovirt repos that are built in the same job. So, what the integration team does today is run "build-artifacts" that generates some rpms (version X) and an image (with rpms version X-1 - those that are currently in the repos). Then they call build-artifacts again to collect fresh rpms-X from the previous job into the final image+iso. So if you'd take a look at the rc/ga jobs, you'd see "4.1.8 rpms" and then immediately after "4.1.8 isos", both producing rpms and isos, very ugly. Logically, I think we need to separate, but if you think there's another way, I'm all ears ;)
Ok I see what you mean, you actually mix 2 events in the same job/script here: Event 1 - the repo source had changed - > as a response you build the "small" packages Event 2 - oVirt repos get updated - as a result you build an ISO Essentially the ISO depends on the "small" packages as well as other oVirt packages. The thing is that STDCI does not model event 2 ATM, we had put forward a design for that back when we were dealing with ovirt-containers, but that was put on the back burner when that project was dropped. Ok. So seeing your needs now, and after spending a few minutes thinking about how to best meed your current needs without making any radical changes, I agree that the way to go for now is to separate the ISO generation code from the small tools generation code.
New Gerrit project was created under gerrit.ovirt.org called 'ovirt-node-ng-image'
The iso for ovirt-node-ng (master) is now built in the ovirt-node-ng-image repository