Open Thaodan opened 3 months ago
The schema in OBS says that package
attribute is not allowed (only arch
or repository
are):
project.rng
<optional>
<element ns="" name="build">
<ref name="flag-element"/>
</element>
</optional>
obs.rng
<define ns="" name="flag-switch">
<optional>
<attribute name="repository">
<data type="string" />
</attribute>
</optional>
<optional>
<attribute name="arch">
<ref name="build-arch" />
</attribute>
</optional>
</define>
<define ns="" name="flag-element">
<zeroOrMore>
<optional>
<element name="enable">
<ref name="flag-switch"/>
</element>
</optional>
<optional>
<element name="disable">
<ref name="flag-switch"/>
</element>
</optional>
</zeroOrMore>
<empty/>
</define>
Let me check with the OBS developers if the schema doesn't need an update...
I'm even unable to add such xml chunk to project meta in the OBS webui (the latest snapshot from git). Are you really sure that this is a valid attribute, everything indicates that most likely it's not.
The per package build flags in project meta are a custom feature in our OBS, so not exactly a bug in osc.
Though it seems that the new XML model parsing and validation in osc is a bit problematic in that sense. Isn't backwards and forwards compatibility with the server and client quite difficult if this kind of things are hard coded on the client side?
I may need to re-think the object model, maybe only manipulate the underlying XML instead of parsing it and assembling from scratch when finished.
Didn't you think about submitting your change upstream? That would close the gap a little.
We are quite a bit behind upstream OBS, on 2.9, and haven't had time to update and rebase the patches. That is the main reason for not submitting them upstream. But also for this particular per package build flag feature, I'm not sure how useful it really is. The reasons why we have it can be handled in other ways, which probably would also make things easier in general.
Personally I think enforcing a strict XML model is wrong, I agree with Pami on that.
About the per package disable flags inside the prjconf: Since they could also be added to the package itself I'm not sure how much difference it does make in the end to put them in the prjconf. But if the patch is useful to upstream we could submit it.
The easiest and fastest fix is probably extending osc to support your use case. I'll document that the attribute is a private extension and may not validate on the server.
Working with XML differently requires a lot of time and effort and is not on my priority list at the moment. If this becomes a common problem, I'll return to it in the future.
@Thaodan @keto I spoke to the OBS developers and they would prefer you to use the existing OBS features:
BuildFlags: onlybuild:<package>
Would any of these options work for you? If not, why?
Daniel Mach @.***> writes:
@Thaodan @keto I spoke to the OBS developers and they would prefer you to use the existing OBS features:
- Disable package builds in package meta
- The latest version of OBS supports project config directive
BuildFlags: onlybuild:<package>
Would any of these options work for you? If not, why?
The first option could work. We have to discuss this internally and report back.
Thanks for helping so far.
Describe the bug A clear and concise description of what the bug is.
openSUSE Tumbleweed
1.8.3
To Reproduce Steps to reproduce the behavior:
osc --debug -H build <repo> <arch>
Expected behavior A clear and concise description of what you expected to happen.
Screenshots, console outputs If applicable, add screenshots or console outputs to help explain your problem.
Additional context