search

clearlinux / mixer-tools

Software update mixer and related tools
Apache License 2.0
28 stars 37 forks source link

Reduce mixer build bundle scope to changed bundles #630

Open gtkramer opened 5 years ago

gtkramer commented 5 years ago

If a build only has one package changing that is found in only a small handful of bundles, do all of the bundles need built? Given mixer produces a stateful workspace that is iterative, would it be possible to build bundles only for the bundles that have changed to coincide with how the update is performed? I think existing information to populate Manifest.full should be able to be obtained from existing manifests if I understand how changes work across manifests correctly.

rchiossi commented 5 years ago

The problem right now is that the process of building the bundles is what we use to figure out what changed, but in theory it should be possible with a change in mixer architecture.

gtkramer commented 5 years ago

Ah, that makes sense. That's where the manifest info and includes files are made. I think that's still reasonable to do, and probably unavoidable, but maybe we don't need to install all bundles? Combined with doing the rpm2cpio bits, I think doing less work in parallel would be a big speed up.

gtkramer commented 5 years ago

I'm not sure how this plays into a possible long-term strategy, but if we want to start farming out work with mixer onto multiple machines, I think it would be useful to have the process/logic already in place to only build the bundles that have changed (and subsequently the update off those bundles).

insilications commented 4 years ago

Yes, a simple bundle with a few dozen file changes takes more than one hour in a 9900ks in my personal mix update. It would be nice to have the control to customize CL without having to wait more than one hour to update. It is unsustainable for small developers.