Support buildemptyflavor attribute in multibuild xml#19319
Support buildemptyflavor attribute in multibuild xml#19319rjd15372 wants to merge 7 commits intoopenSUSE:masterfrom
buildemptyflavor attribute in multibuild xml#19319Conversation
github-actions
Bot
added
Documentation 📖
rjd15372
force-pushed
the
empty-multibuild
branch
2 times, most recently
from
0a51f3b to
6fc8909
Compare
|
Hmm, this looks a bit complicated and confusing. I don't think we should completely suppress the main package if buildemptyflavor is set to false. How about just setting the package status to |
Something like this: and 
|
rjd15372
force-pushed
the
empty-multibuild
branch
2 times, most recently
from
2fb54d0 to
7d260a3
Compare
|
No, I meant that the src server should not mess with the package list, but just set |
|
As a bit of background: we may need to have attributes for flavors in the future, e.g. |
Thanks for the clarification and the background context! I've updated the implementation to follow your suggestion. |
| it { expect(test_package_source.first.details).to eq('fake details') } | ||
| end | ||
|
|
||
| context 'when buildemptyflavor=false' do |
There was a problem hiding this comment.
This XML attribute is just ignored by LocalBuildResult. You are not testing anything there, just spending CI cycles. CI time is developer time, the most expensive thing we deal with.
There was a problem hiding this comment.
Sorry, you're right. It's completely redundant. I'll update the PR.
When using multibuilds, users may want to build only flavored packages and skip the base package. This change adds support for the new `buildemptyflavor` attribute on `_multibuild` xml, and makes backend package selection/scheduling work correctly in that mode. Example usage: ```xml <multibuild buildemptyflavor="false"> <flavor>flavor1</flavor> <flavor>flavor2</flavor> </multibuild> ``` With this configuration, `mypackage:flavor1` and `mypackage:flavor2` are built, while `mypackage` (base package) is not added to the build package list. The multibuild handling now excludes the base package when requested, while keeping default behavior unchanged if the attribute is not set. The source server logic is also adjusted so projects are not incorrectly skipped when the package list contains only flavors, and multibuild cache refresh/requeue logic continues to work when flavors change. This includes validation/schema updates for the new attribute and backend tests covering: * valid/invalid `buildemptyflavor` values * base package inclusion/exclusion behavior * flavor matching and stale flavor update paths Side-effects: * opt-in behavior only (buildemptyflavor=false) * existing multibuild projects keep current behavior by default Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
…olations Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
When buildemptyflavor="false" is set, mark the base package as excluded
directly in the src server using $pinfo->{'error'} = 'excluded', rather
than removing it from the package list in addmultibuildpackages().
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
… spec LocalBuildResult::ForPackage has no knowledge of the buildemptyflavor attribute. The excluded base package behavior is already covered by the existing excluded/disabled test cases. Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
rjd15372
force-pushed
the
empty-multibuild
branch
from
b5b0b8d to
c55ffc8
Compare
Signed-off-by: Ricardo Dias <ricardo.dias@percona.com>
3 participants
When using multibuilds, users may want to build only flavored packages and skip the base package. This change adds support for the new
buildemptyflavorattribute on_multibuildxml, and makes backend package selection/scheduling work correctly in that mode.Example usage:
With this configuration,
mypackage:flavor1andmypackage:flavor2are built, whilemypackage(base package) is not added to the build package list.The multibuild handling now excludes the base package when requested, while keeping default behavior unchanged if the attribute is not set. The source server logic is also adjusted so projects are not incorrectly skipped when the package list contains only flavors, and multibuild cache refresh/requeue logic continues to work when flavors change.
This includes validation/schema updates for the new attribute and backend tests covering:
buildemptyflavorvaluesSide-effects:
buildemptyflavor=false)Screenshot example of when using
buildemptyflavor="true", or without using thebuildemptyflavor(default):Screenshot example of when using
buildemptyflavor="false":