hi,
I want to be able to trigger external actions when rpms are built successfully into some specific targets. How would I do this today ?
My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ? if not, do we need to then just hit a specific url on the jenkins side as a 'notify' from the mash run when it sees new content ?
regards,
On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote:
My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ?
https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py
is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg.
Hi Folks,
On 04/15/2015 05:07 AM, Colin Walters wrote:
On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote:
My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ?
https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py
is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg.
I agree that having a messaging queue is the best solution long term.
In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_...
Run mash tasks and do some action at the end.
On 04/15/2015 08:25 AM, Thomas Oulevey wrote:
Hi Folks,
On 04/15/2015 05:07 AM, Colin Walters wrote:
On Tue, Apr 14, 2015, at 07:04 PM, Karanbir Singh wrote:
My immediate requirement is to run jenkins jobs when a new rpm drops into a repo. Does koji have any support for this without the remote having to constantly poll every second ?
https://git.fedorahosted.org/cgit/koji/tree/plugins/messagebus.py
is one example. The main question I'd say is around *which* messaging system and the larger work around wiring things up around it like Fedora has been doing with fedmsg.
I agree that having a messaging queue is the best solution long term.
yup, we should look at this longer term, it will also help with things like when we want to feed content back in ( eg. make the CI tests be a part of the build run on koji:: new rpm fails CI, fail the build optionally )
In the meantime, we could hack something like this : https://github.com/philicious/koji-scripts-and-plugins/blob/master/mash_and_...
Run mash tasks and do some action at the end.
How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ?
Run mash tasks and do some action at the end.
How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ?
- Design and code ; define if we want a koji-builder plugin or koji-hub plugin - Ship the plugin as an rpm - Add rpm to internal infra repos - Install rpm through puppet - Enable plugin in koji conf
On 15/04/15 09:44, Thomas Oulevey wrote:
Run mash tasks and do some action at the end.
How would we push this in ? is it a case of setting up the plugin by hand and dropping it into the koji setup ?
- Design and code ; define if we want a koji-builder plugin or koji-hub
plugin
What would the difference be ?
it would be awesome if we could block -release tag's/repos from getting content that failed CI! But this is clearly something for the long term.