Learn more about these different git repos.
Other Git URLs
The cg_id field was added to the build table to enable reservations by content generators.
However for cg imports that are not reserved, it appears that cg_id is not set.
This is tricky because technically the cg spec allows for one import to cover multiple content generators. However, I'm unaware of systems performing imports that span multiple cgs.
I'm not sure what the right thing here is, but there is certainly potential for confusion.
We could:
Thanks to @mfilip for pointing this out
Metadata Update from @mikem: - Custom field Size adjusted to None
I would pick a second option. I'm not sure if we want to drop multiple CGs support. On the other hand as you've said it is 100% usage now that only one CG is included. Maybe we can pick not randomly but come near with picking CG with majority usage in the import buildroots.
What I wonder now is the semantics of cg_id field - If we are allowing more CGs as part of the buildroots which have created different parts of output - what is the CG for the build itself - does it make any sense even? /Isn't the other option to drop cg_id from buildinfo?/
I'm not sure if we want to drop multiple CGs support. On the other hand as you've said it is 100% usage now that only one CG is included. Maybe we can pick not randomly but come near with picking CG with majority usage in the import buildroots.
It's a tough spot. The cg_id field is decidedly single, and the CGImport code distinctly allows multiple. So, we are already contradicting ourselves.
I frequently regret the choice to support multiple CGs in one import. I'd be interested in trying to move to make them singular, but I don't know if that is feasible (i.e. I don't know if anyone is using that option).
Doing the above right is probably a change to the json schema for cgs.
Metadata Update from @tkopecek: - Issue set to the milestone: 1.24
Let's gather all CG implementations: #2572 (and I'll start a thread in koji-devel)
Limiting CGs to one: #2574
I came across this issue while looking to file another RFE. In the event that you do end up moving to a one-cg-per-build implementation it won't be necessary ...
For now in order to identify what CGs a given build was produced with it requires a number of calls. We have to load all archives for the build, then load the individual buildroot records that produced each of those archives, and from there we can get the list of CGs. It would be great if there were a single hub call to fetch this in one go, similar to how the getBuildType call works.
If the issue #2574 goes through, then presumably the fields used to reserve the build for a CG can be used for this instead. But in the event that this doesn't work or cannot be safely implemented, would you prefer a file an RFE for the new call now or wait to see how things pan out?
Note that even with #2574, some existing systems could have old imports with multiple cgs. Also, this change does not add cg_id values to old builds that lack them
Metadata Update from @jcupova: - Issue tagged with: testing-ready
Metadata Update from @mfilip: - Issue tagged with: testing-done
Commit 812c1a8 fixes this issue
Commit f5ddbbf relates to this ticket
Commit 39ab9fb fixes this issue
Login to comment on this ticket.