Bug 841164 - RFE: allow to pass extra info along with build
RFE: allow to pass extra info along with build
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: koji (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-18 06:20 EDT by Jan Stancek
Modified: 2014-06-23 12:32 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-23 12:32:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jan Stancek 2012-07-18 06:20:14 EDT
Description of problem:
This is feature request for koji client to allow to pass "some extra information" when build is submitted. The reason is to have some extra context / comment by submitter (similar to beaker's whiteboard). 

This would be very handy for automated tools that monitor koji (brew) and take various actions when build is finished. For example submitter can easily express his/her intention to get this build tested.

This should affect only koji client, that would add extra fields to "opts" - same dict where are stored 'scratch' and 'arch_override' options. Server side shouldn't be affected - I tested this with brew and modified koji client. Tools monitoring koji/brew will receive it in options field in same way as now (xmlrpc/amqp), humans will see it in WEBUI.

Proposal 1.
Add "--comment" option to koji client, which would add single "comment" entry to "options".
Example:
    koji build --scratch --comment="w=interim test=tier1" dist-5E-test kernel.src.rpm

Proposal 2.
Add "--private" option to koji client and for each add entry to "options" with "private_" prefix (to avoid conflicts with other options).
Example:
    koji build --scratch --private="w=interim" --private="test=tier1" dist-5E-test kernel.src.rpm
Comment 1 Fedora End Of Life 2013-07-03 18:08:18 EDT
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 2 Fedora End Of Life 2013-07-31 19:47:47 EDT
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 3 Jiri Hladky 2013-11-19 08:06:08 EST
Hello,

let me give the business justification for this feature. 

We are using autobkr to implement a CI methodology for the kernel testing. We would need this feature as a way how developers can flag the kernel builds for a special testing. The CI initiative is the top priority for the QE for FY15 and we would really this feature to support it.

Please let us know your thoughts on it. Could you please come up with a timeplan for the implementation?

Thanks a lot!
Jirka
Comment 5 Jiri Hladky 2013-11-20 04:41:28 EST
Hi Mike,

in fact the comment #3 is not private, I have unchecked Private flag.

We need this feature for Red Hat but I guess it would useful for the Fedora as well.

The idea is following.

Kernel integrator will use the requested switch to add comments when sending jobs to Brew. The comments are generally useful to mark the builds but we have a special usage in mind.

We are using autobrk to automatically trigger QE tests once a kernel build is done. The flows is like this:

Brew -> Build Kernel -> autobrk watching Brew for new kernels -> creating Beaker job to test the new kernel

We need a way how a kernel developer can mark kernels for special testing. So for example we have performance tests which should be triggered only per request. With this new feature developer will just do

koji build --scratch --comment="w=performance" dist-5E-test kernel.src.rpm

autobkr is watching for the the "w=performance" in new kernels comments and when it's their a performance QE suite is triggered.

Jan Stancek has already implemented this support to autobkr, brew supports comments as well, we need only a way how to add comments when submitting jobs via koji.

Please let me know if you need more details.

Jirka
Comment 6 Mike McLean 2013-11-20 17:48:52 EST
How is autobrk watching for new kernels?
Your example is a scratch build, which generates few useful callbacks, so I'm guessing something is just monitoring /mnt/koji/scratch for new kernels? ..and perhaps querying for and parsing the the task request after the fact to determine build target?
Comment 8 Jan Stancek 2013-11-20 18:09:41 EST
(In reply to Mike McLean from comment #6)
> How is autobrk watching for new kernels?
> Your example is a scratch build, which generates few useful callbacks, so
> I'm guessing something is just monitoring /mnt/koji/scratch for new kernels?
> ..and perhaps querying for and parsing the the task request after the fact
> to determine build target?

It's using xml/rpc listTasks() with filter to get completed ones within some interval. 

I don't want to focus on specific tool here, because we are going to have same problem with any tool (jenkins or others): How can developer convey his desire to have his build tested (automatically when build is done) and what tests to run.
Comment 10 Jiri Hladky 2013-11-22 05:04:29 EST
Hi,

please provide a feedback what are your thoughts to implement this. We would need to know if and when it could get implemented.

Thank you!
Jirka
Comment 14 Dennis Gilmore 2014-06-23 11:51:43 EDT
I am not sure that it is something we really want implemented. it seems like the kind of thing that should be in an external service to koji. where a user could opt in or out. official fedora builds for instance will always get the default fedora automated qa run on them.  not sure I really get the request
Comment 15 Jan Stancek 2014-06-23 12:32:38 EDT
(In reply to Dennis Gilmore from comment #14)
> I am not sure that it is something we really want implemented. it seems like
> the kind of thing that should be in an external service to koji. where a
> user could opt in or out. official fedora builds for instance will always
> get the default fedora automated qa run on them.

The need for this came up during kernel testing. Running generic/all testsuites on each kernel build is unfeasible as it would take a lot of time and include running tests, which are pointless for particular change. e.g. xfs regression suite for change in tg3 network driver. Idea here was to allow developer give CI system a hint what tests (if any) to run for particular build.

> it seems like the kind of thing that should be in an external service

That's what we did in the end. Closing.

Note You need to log in before you can comment on or make changes to this bug.