koji

#3875 Log the macros enabled in side tag
Closed: Fixed by tkopecek. Opened by vondruch.

Closed: Fixed
Reopen Issue

This is followup to #3673. For auditing purposes, I think it would be useful if the macros injected into the side tag were recorded somewhere in logs / UI.

Not sure what is the mechanism behind, so maybe I should ask mock developers instead.

@praiskup FYI

side tags are tags, and the macros set for them are recorded in the tag_extra table.

Unfortunately, side tags tend to get deleted pretty quickly. This doesn't mean the data is gone from Koji, but it does make it a bit awkward to get to as many parts of koji will tell you "no such tag". PR #3828 will make that a little better, but probably not enough to help here.

You can however see the history of the tag_extra table. E.g.

$ koji -p fedora list-history -v --tag f38-build-side-67598 -s tag_extra
Sun May 14 16:53:42 2023 (eid 111319915) added tag option sidetag for tag f38-build-side-67598 by kalev
    value: true
Sun May 14 16:53:42 2023 (eid 111319915) added tag option sidetag_user for tag f38-build-side-67598 by kalev
    value: "kalev"
Sun May 14 16:53:42 2023 (eid 111319915) added tag option sidetag_user_id for tag f38-build-side-67598 by kalev
    value: 994
Sun May 14 16:53:59 2023 (eid 111319927) added tag option rpm.macro.with_bootstrap for tag f38-build-side-67598 by kalev
    value: 1
Sun May 14 17:32:18 2023 (eid 111321599) tag option rpm.macro.with_bootstrap removed for f38-build-side-67598 by kalev
Sun May 14 17:33:37 2023 (eid 111321661) tag option sidetag removed for f38-build-side-67598 by buildvm-ppc64le-28.iad2.fedoraproject.org
Sun May 14 17:33:37 2023 (eid 111321661) tag option sidetag_user removed for f38-build-side-67598 by buildvm-ppc64le-28.iad2.fedoraproject.org
Sun May 14 17:33:37 2023 (eid 111321661) tag option sidetag_user_id removed for f38-build-side-67598 by buildvm-ppc64le-28.iad2.fedoraproject.org

Obviously grotty, but I want to reinforce that Koji does not throw away build data, even if it sometimes might be hard to find.

If you query koji at the right event, you'll see the parameters.

$ koji taginfo f38-build-side-67598 --event 111321660
Querying at event 111321660 (Sun May 14 17:33:35 2023)
Tag: f38-build-side-67598 [67598]
Arches: i686 x86_64 aarch64 ppc64le s390x
Groups: appliance-build, build, livecd-build, livemedia-build, srpm-build
Tag options:
  mock.new_chroot : 1          [f38]
  mock.package_manager : 'dnf' [f38]
  sidetag : True
  sidetag_user : 'kalev'
  sidetag_user_id : 994
Targets that build into this tag:
  f38-build-side-67598 (f38-build-side-67598)
This tag is a buildroot for one or more targets
Targets that build from this tag:
  f38-build-side-67598
Inheritance:
  0    .... f38-build [56370]

Metadata Update from @mikem:
- Custom field Size adjusted to None

All that said, it certainly seems reasonable for mock itself to log this stuff too. I'm a bit surprised that the act of writing these macros isn't already recorded in root.log.

All that said, it certainly seems reasonable for mock itself to log this stuff too. I'm a bit surprised that the act of writing these macros isn't already recorded in root.log.

So what mechanism is Koji using to inject these macros into buildroot? Does it just modify the config_opts['macros'] in mock config? Actually confirming with staging Koji, that is likely true:

$ koji -p stg mock-config --task 110077615
# Auto-generated by the Koji build system
config_opts['basedir'] = '/var/lib/mock'
config_opts['chroot_setup_cmd'] = 'groupinstall build'
config_opts['chroothome'] = '/builddir'
config_opts['dnf_warning'] = False
config_opts['package_manager'] = 'dnf'
config_opts['root'] = 'f39-build-side-66874-task_110077615'
config_opts['rpmbuild_networking'] = False
config_opts['rpmbuild_timeout'] = 86400
config_opts['target_arch'] = 's390x'
config_opts['use_host_resolv'] = False
config_opts['yum.conf'] = '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# repos\n\n[build]\nname=build\nbaseurl=https://kojipkgs.stg.fedoraproject.org//repos/f39-build-side-66874/9002809/s390x\n'
config_opts['plugin_conf']['ccache_enable'] = False
config_opts['plugin_conf']['root_cache_enable'] = False
config_opts['plugin_conf']['yum_cache_enable'] = False
config_opts['macros']['%_host'] = 's390x-koji-linux-gnu'
config_opts['macros']['%_host_cpu'] = 's390x'
config_opts['macros']['%_rpmfilename'] = '%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm'
config_opts['macros']['%_topdir'] = '/builddir/build'
config_opts['macros']['%_with_bootstrap'] = 1
config_opts['macros']['%distribution'] = 'Koji Testing'
config_opts['macros']['%packager'] = 'Koji'
config_opts['macros']['%vendor'] = 'Koji'

The only problem I see that there is kind of too many macros. Not sure if it would be reasonable to filter them somehow or not.

Alternative solution could be to log the mock config in Koji. I think that mock configs are useful independently of macros being recorded there while there is no UI to obtain them. That would cross two hurdles with one leap

Does it just modify the config_opts['macros']

yes. This happens in BuildRoot._writeMockConfig() in kojid

Alternative solution could be to log the mock config in Koji

I've been thinking this as well.

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

PR #3903

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

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

Commit c44be86c relates to this ticket

Commit 91f176cc relates to this ticket

PR #4023 was merged, which includes changes (originally from #3926) to log the mock config. If that's sufficient, then let's close this.

Metadata Update from @tkopecek:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/koji/koji/issues/3875

Please continue any further discussion there.
Metadata
None

testing-done testing-ready

None
None
Low
None
Related Pull Requests
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.