Thanks Robert, I hadn't seen that plugin before. It does look remarkably 
close to my requirements! I'll see if it's adaptable for our lamp. 

Ta,
Andy

On Wednesday, 12 February 2014 11:57:55 UTC, Robert Sandell wrote:
>
> It seems like you want to do something very similar to the Extreme 
> Feedback plugin
>
> https://wiki.jenkins-ci.org/display/JENKINS/Extreme+Feedback+Plugin
>
> but for a different kind of lamp.
>
>  
>
>  
>
> *Robert Sandell*
>
> Software Tools Engineer - SW Environment and Product Configuration
>
> Sony Mobile Communications
>
>  
>
> *From:* [email protected] <javascript:> [mailto:
> [email protected] <javascript:>] *On Behalf Of *Daniel Olausson
> *Sent:* den 12 februari 2014 09:55
> *To:* [email protected] <javascript:>
> *Subject:* Re: Plugin design advice
>
>  
>
> Hi,
>
>  
>
> I have understood you correctly?
>
>  
>
> Let's say we have 2 lamps( or two projects), and in the Jenkins we have 10 
> jobs, and that you want to associate 5 jobs to lamp number 1 and 5 jobs to 
> lamp number 2.
>
>  
>
> The behavior will be such that when one of the jobs in a "lamp-group" 
> fails, it should trigger some kind of event which will be used to turn the 
> real lamp on/off/green/red..etc/blabla?
>
>  
>
> There are a number of ways you could group jobs together. Either you could 
> go for your initial idea of specifying the lamp-groups as a global 
> configuration and then in the configuration for a job having a setting 
> which selects one( or more?) of these lamp-groups. However, this would mean 
> that you would have to access each and every job and select the wanted 
> lamp-group, and if there are a lot of jobs it will be a mind numbing task. 
> For example if there are 50 jobs in a group, having to add each job to the 
> group one by one is not such a good idea.
>
>  
>
> The filter view rss thingy sounds like an easy thing to do, but as you say 
> it requires polling and is not very configurable.
>
>  
>
> I didn't quite understand the part where you said a view wont work when 
> its not visible. I think a view would be a good choice for this project. 
> You can extend the regular ListView with your own code, where you can use 
> the RunListener to receive events from Jenkins when a job has finished 
> executing, check if this job is in this view( this lamp-group ), and if it 
> is trigger the lamp thingy.
>
>  
>
> 1. Create a View that extends the ListView
>
> 2. Connect a RunListener to your implementation
>
> 3. When RunListener.onFinalized() is triggered, check if the finalized 
> build is from a job in this view(lamp-group)
>
> 4. If (3) is true -> trigger your lamp in some way. If (3) is false, just 
> ignore it
>
>  
>
> This solution would mean that each instance of the lamp-group-view will 
> have its own RunListener and every time a build is finished all of these 
> RunListeners will get triggered. I guess this isn't a good thing if you 
> have hundreds of lamp-group-views since it will do the same check 
> everywhere, but since you probably won't have that many I think it should 
> be okay. If you really want to have only one RunListener, you would have 
> your plugin keep a list of all lamp-group-views and then iterate over them 
> when a build has finished to see which lamp to trigger. 
>
>  
>
>  
>
> Regards,
>
> Daniel
>
>  
>
>  
>
>
>
> On Tuesday, 11 February 2014 20:26:29 UTC+1, AndyB wrote:
>
> Hi  Plugin-developers,
>
>  
>
> I'd like to ask some advice about how best to architect a plugin. 
>
>  
>
> We have a system that can wirelessly enable build break 'lamps' from a 
> master controller running on a PC (could be Jenkins master). What I'd like 
> to do is create something like a view filter that will allow a number of 
> jobs to be selected and tied to a particular lamp instance (representing a 
> project or team). A lamp would reflect the worst-case build state of the 
> selected jobs. E.g. if any jobs failed it would indicate a fail, if all 
> jobs passed it would indicate passing state.
>
>  
>
> What I'm wondering is how this would be best achieved (please bare mind 
> this will be my first plugin development so it's possible(likely) I've got 
> the wrong end of the stick in some of the following...).  
>
>  
>
> I first thought about the 'wall display' type view (exemplified by the 
> 'Build  Monitor' plugin), this allows a list of jobs to created easily, I 
> thought to add a global config section that added a list of lamps, then 
> each view could be associated with a lamp. This seems like a reasonable 
> design, but I think it would only work if the view was visible, checking 
> for build state changes. I don't think this would work as there wouldn't be 
> a guarantee that view was visible so that changes could be missed.
>
>  
>
> It seems that push style notifications would be better, however I've only 
> seen this as something that's configurable as a post build step. I'd prefer 
> to have the user select what jobs they want to monitor rather than having 
> to modify the jobs. Basically I'd like to aggregate the notification over a 
> number of jobs.
>
>  
>
> A simpler alternative would be to create an RSS feed for a filter view 
> (functionality that already exists) and associate a feed with each lamp, 
> the controller would then continuously poll the feed for changes and send 
> updates to the appropriate lamp. This also sounds less than ideal as the 
> feed would need continuous polling and it doesn't leave any room to tune 
> any parameters that could be associated with a lamp (as the content of the 
> RSS feed is fixed). It could however be implemented without a plugin, or 
> maybe a global config could be created that the user entered a view in (the 
> RSS being based on that view name).  I don't see any kind of extension 
> point that could be used to create a custom RSS-like notifier.
>
>  
>
> Is my analysis correct? Is there a better way to create the type of 
> aggregate notifier I need?  Any suggestions of how I could approach this 
> would be much appreciated.
>
>  
>
> Thanks,
>
> Andy
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to