Learn more about these different git repos.
Other Git URLs
The rpm spec has a largely undocumented tag, VCS, which can be used to point to the vcs repository that hosts the code. We've recently started adding this tag to RPMs automatically created from our Gitlab infrastructure to help maintain visibility into the origin of our RPMs.
I think it could be useful to expose this tag in Koji's web interface when it's available, perhaps in Extra alongside the original_url. Is there any interest in this from anyone else?
original_url
Metadata Update from @tkopecek: - Custom field Size adjusted to None - Issue set to the milestone: 1.24 - Issue tagged with: discussion
(Marking as discussion with decision to de done before 1.24)
Here are a couple of mockups of what this could look like:
<img alt="Screenshot_2020-10-28_13-16-15.png" src="/koji/issue/raw/files/47572b03b2937b29ab573f80b7c395542fe41e2f8936a078076bbf35f6d075e5-Screenshot_2020-10-28_13-16-15.png" />
<img alt="Screenshot_2020-10-28_13-14-25.png" src="/koji/issue/raw/files/30e096e513f324469d38fb2fe103a2dffc08c10b6644d06df48b1c198cb20de9-Screenshot_2020-10-28_13-14-25.png" />
It would probably make sense to have VCS and DistURL exposed if they're used.
VCS
DistURL
I think the original intent was to use VCS for upstream version control...
That said, openSUSE uses DistURL the way you're proposing to use VCS, and it might not be a bad idea for Fedora to do the same in the near future, so we might want that...
Here's an idea for a small patch that would read the values of VCS and DistURL and store it in the extra field of a build.
extra
<img alt="Screenshot_2020-10-29_15-37-09.png" src="/koji/issue/raw/files/245264e1138ba599c9c4f8b1af41bd7011c5e7a0d7289e354b96616be83b0752-Screenshot_2020-10-29_15-37-09.png" />
I've created PR #2683 - it displays these tags on rpminfo page. It makes sense there as it is the only place where we display other rpm tags.
About saving this data to build.extra - I don't think it is necessarry, as it is still available via standard getRPMHeaders call. If there will be some other usecase (so this API is not sufficient, we can open new issue.
getRPMHeaders
Metadata Update from @tkopecek: - Issue untagged with: discussion - Issue tagged with: testing-ready
The advantage of adding it to the extras would be that it would show up in the buildinfo page, where I think it would be more useful.
buildinfo
@alexi What I'm afraid here that we can open a can of worms here. If there is one rpm tag in build extras why not all of them? Adding the value to buildinfo page is still doable without moving it to extras (we can simply find the srpm and query headers).
Adding the value to buildinfo page is still doable without moving it to extras (we can simply find the srpm and query headers).
That would be better, yes, I was just unsure how to do it when I was playing around with this.
Metadata Update from @tkopecek: - Issue untagged with: testing-ready
Added also to buildinfo page (updated PR)
Metadata Update from @tkopecek: - Issue tagged with: testing-ready
Metadata Update from @jobrauer: - Issue tagged with: testing-done
Commit ec3ef39 fixes this issue
Commit 0b99fe1 fixes this issue
Commit 9e376a2 fixes this issue
Commit 8fb0a53 relates to this ticket
Commit 556f8a1 fixes this issue
Commit 9fb1a53 relates to this ticket
Login to comment on this ticket.