@julian8628 wdyt?

Note this affects:

• rpm buildroot components for cg imports
• rpm components of cg imported images
• rpm components of koji-built images

I'm a bit concerned with the first one "rpm buildroot components for cg imports", since rpms in buildroot and rpm components probably have different usage.

Theoretically, we can use draft builds in koji internal buildroot, but probably don't want to "release" draft builds as well as images that contain draft builds. So, differentiating them sounds reasonable?

Maybe better to have one option for buildroot components and one option for rpm components at the beginning?

I'm a bit concerned with the first one "rpm buildroot components for cg imports", since rpms in buildroot and rpm components probably have different usage.

Well, we already allow draft builds in regular buildroots. So that part is just parity between cg and native builds.

That said, I consider this option dangerous, at least for now, and I would recommend folks leave it off (as is the default). In my case, this option is needed in a staging environment. I'm not intending to use this option in prod.

By design, draft builds can be used as regular builds in most every way. If you can't use them, they aren't any more useful than a scratch build.

From The Koji perspective, draft builds are just a way to have overlapping NVRs without massive backwards-incompatible changes. Of course, folks naturally want to apply additional meaning to the term "draft", e.g. to interpret it in terms of publication processes that are outside of Koji's purview.

Rules about managing content in Koji (e.g. how certain builds should or shouldn't be used) are generally enforced by:

• policy
• the behavior of external systems (e.g. jobs that perform tagging operations)

It should not be too difficult for a release pipeline to include a check for draft content. It is pretty easy to query.

Yeah, makes sense. :thumbsup:

Testing notes

Case 1: with AllowDraftComponents=False (the default), using draft components in cg imports (either as a buildroot component or an archive component) should result in an error. You could check this with a very minimal cg import using a single draft rpm as a component.

Case 1b: conversely, a cg import with only non-draft rpms should succeed with this setting

Case 2: with AllowDraftComponents=True, using using draft components in cg imports should succeed. Those components should show up appropriately for the resulting imported build.

Commit fa4cb46c fixes this pull-request