Trigger refresh of build information by URL hook
From what I can tell there are two ways to trigger a refresh of the build information for a project. One is to have it update on every index request (potentially slow). The other way is to issue
Update on every index request can be slow and is a drain on resources. If Hudson builds are infrequent this is a waste.
Update by polling can be a waste as well but that can be limited by running the polling less frequently. By running the polling less frequently, this can make the information that Redmine knows about Hudson feel very out of date.
Neither option are ideal. What would be preferable would be something like this:
- Hudson notifies Redmine anytime a build is completed. This means that Redmine can sync only when it knows that something has changed.
- Poll Hudson either daily or several times a day as a "backup" in case realtime notification of build fails for some reason (cron)
I would like to add functionality that can trigger a refresh of build information based on a URL hook. This would be similar to how the Redmine GitHub Hook handles HTTP requests to be notified that a Git repository has been updated on GitHub.
Hudson has something similar. I have it setup so that anytime a specific GitHub project gets a commit it sends a ping to Hudson to do a build. In this way, both Redmine and Hudson are already being driven by HTTP requests from GitHub to do things. (Hudson updates and starts a build, Redmine updates and Repository tab shows fresh data immediately)
On the side of security, Hudson has a build request by URL feature that allows a token to be specified. We could do something similar to ensure that only valid check-for-update-requests are actually acted upon.
I would be happy to help contribute to this project and add this functionality if it is something that you would like to have in the core Redmine Hudson plugin. Please let me know and I can start working this into my schedule.
Adding this functionality will require cooperation from the Hudson side. I am happy to work on that side of the software as well. The two ways this can be handled from the Hudson side are by adding to the Hudson Redmine plugin (the Redmine plugin for Hudson) or by creating a standalone post build process plugin that can be used generically to ping a specific URL after build has completed.
The main benefit to adding this feature would be that the status between Redmine and Hudson can stay very up to date with minimal polling. Anytime a new Hudson build has completed it can notify Redmine that it needs to check for updates from Redmine.
I'm very new to Redmine and to Rails but think I can probably do this given a little time. It might be the end of the year before I could actually finish this and might have a lot of questions along the way.
Updated by Toshiyuki Ando about 10 years ago
sorry, need further explanation.
Redmine Hudson plugin has rake task 'redmine_hudson:fetch'.
This task can get information from Hudson job.
Hudson job can call rake task, and can call another job after build completed.
1) disable 'AutoFetch' ( Go Administration -> Plugins -> 'Redmine Hudson Plugin' Configure. )
2) create a Hudson job for execute 'redmine_hudson:fetch'
3) other Hudson job called 'redmine_hudson:fetch' job, after build completed.
Updated by Beau Simensen about 10 years ago
I appreciate the clarification. This is something that I think I would be able to use right away until I am able to work on a more complete solution.
From what I can tell, what you suggest here will only work if Redmine and Hudson are on the same host. This is the case for me currently, which is why this would work. However, an HTTP callback solution would be more appropriate in cases where one or more dedicated systems are in place for Hudson.
If I make progress on this I will make sure to let you know!
Does the Redmine Hudson plugin have a public repository (even if read-only) that I would be able to access?
Updated by Toshiyuki Ando over 9 years ago
- Priority changed from 通常（Normal） to 高め（High）
Josh Davidson proposed this feature.