#215 Mechanism for content generators to link to build task
Closed: Fixed a year ago by tkopecek. Opened 7 years ago by mikem.

While a content generator can be completely separate from Koji, it is possible to be a little more integrated, as with the koji-containerbuild plugin. If a CG import originates from a Koji task, it should be possible to specify that in the metadata and have koji do the right thing.

Additionally, it should also be possible for the metadata to specify an external link to the build task (e.g. an osbs link, a copr link) and for the Koji interface to display that appropriately.


Because CG will have koji to create a build (hence there will be a buildinfo page for this imported results), and creating a build need an unique NVR, hence, even perhaps some CGs could uses a trial and error method to get an available NVR, the best way is koji to allocate NVR (and other resources if such resources are competed).

If CG import doesn't originate from koji task, then when the build task done, the build task will call CG api to import its build results. In this case, if the metadata specifies an external link for the Koji interface to display the build task appropriately. That means

  1. Content Generator need provide a web service. Otherwise the task link will not work.
  2. Synchronization problem.

If a CG import originates from a Koji task, for a packager, suppose that he know nothing about or doesn't care about how koji to do the task, does it matter and make sense for him whether the task calls CG api or not? For the packager, the task is a brew task, not a CG. Hence for him it's reasonable to expect that there is a link to task in the buildinfo page. Hence the metadata must tell koji how to show these build task or tasks.

For the txkoji client library, I've implemented this workaround for the container_koji_task_id data that OSBS gives us.

https://github.com/ktdreyer/txkoji/commit/93f80545a609ead01116577ddbde886d34e14b49

This lets me access the task ID property in a unified way for both types of builds: the regular ones from Koji, and the OSBS builds that originate from the content generator.

Metadata Update from @yulwang:
- Issue priority set to: Normal
- Issue tagged with: groomed, tech-debt

4 years ago

OSBS uses container_koji_task_id. I think we could pick a standard here for all content generators, like koji_task_id or something, and then the tools (like kojiweb) could display that.

I found OSBS also uses filesystem_koji_task_id in some situations (the base image, I guess?) Anyway it would be fantastic to standardize a simple way to specify a Koji task integer in the Content Generator.

Metadata Update from @mikem:
- Custom field Size adjusted to None
- Issue tagged with: discussion

3 years ago

I think if we're going to add a standardized way, it would be live in the main build section. This is a key piece of data. We might, as a transitional aid, also honor some of the existing fields under extra.

@julian8628 suggests also providing a way for content generators to link to their own (external) tasks/etc that were used to generate the build. That might need to be a separate issue since there is no clear place in the Koji schema for that yet.

Hi @mikem! For the osbuild integration with koji we have been passing the task_id as part of the CGImport metadata, as we thought that was the right thing to do. However, it turns out that this field is ignored by koji. Is there some reason why koji could not simply used the task_id from the main build struct passed to CGImport? I think this would improve the user experience a lot, without us having to also introduce osbuild-specific hacks to get the information out.

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.31

2 years ago

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.32 (was: 1.31)

a year ago

Metadata Update from @jcupova:
- Issue tagged with: testing-ready

a year ago

Metadata Update from @mfilip:
- Issue tagged with: testing-done

a year ago

Commit 5bbe106 relates to this ticket

@tkopecek The task is still not shown in the UI, do I get it correctly, right?

It should be (at buildinfo page) - isn't it in some case?

Metadata Update from @tkopecek:
- Issue set to the milestone: None (was: 1.32)

a year ago

Metadata Update from @tkopecek:
- Issue set to the milestone: 1.32

a year ago

Login to comment on this ticket.

Metadata
Related Pull Requests
  • #3656 Merged a year ago