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
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.
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.
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
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
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?
(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.
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
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
(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.