Thanks fcamblor, for that great writeup. Of course I disagree with some points of your analysis. (If you know me better you would expect that from me - I like to play the devils advocate.)
Currently the plugin only supports one strategy - HUDSON_HOME rules. I think the plugin should support more strategies.
(S-1) HUDSON_HOME rules
(S-2) SVN rules
(S-3) HUDSON_HOME and SVN rules
In case S-1 and S-2 the synchronization can be performed automatically. For S-3, the automation needs additional criteria or default to asking the admin . In all three cases there should be a ask admin option (default).
- All jobs will be tested on a Hudson-Dev instance. Hudson_Dev pushes the changes to its own configuration branch. When the job does what it is supposed to do, the changes will be copied from the dev location in SCM to the prod location in SCM. The prod Hudson will pull the changes and apply them without additional user iteraction. (S-2)
- Some job changes will automatically be performed using the API or by changing the configuration on disk. The desire is to automatically update SCM to have a history of the file changes. The assumption is here that the plugin does not intercept (re)loading the config or config changes through the API to automatically commit them. (S-1)
- A combination of the above. The big changes are developed and tested on the Dev-Hudson and pushed to the prod instance via SCM. The smaller changes will be performed directly on the Prod-Hudson. (S-3)
- Jobs will be update and created in Hudson. But certain jobs are created automatically and pushed to SCM instead of using the remote API from Hudson. (S-3)
Relevance of Hudson_SSC
How to compare
We don't need to change the behavior of the current checkout behavior. As long as you make sure that files that are not in the SCM are eliminated (svn revert + svn update should do the trick). Special cases:
(C-1) The location in SCM does not exists. Delete the contents of HUDSON_SSC and initialize HUDSON_SSC with contents of HODSON_HOME hierarchy. Initialize the SCM with contents of HUDSON_SSC.
(C-2) HUDSON_SSC is not attached to any SCM. Delete the contents of HUDSON_SSC and checkout a fresh copy from SCM. Synchronize according to compare strategy.
If you follow the above step every time you synchronize with the SCM, the HUDSON_SSC folder is up to date. This makes it easier for the plugin too, since it only has to worry about the UI point of view.
Ideas for Implementation
- Hudson offers the remote API, to change a job on the fly. It can always be called from inside or outside of Hudson. I am not sure what the implications are, if the Hudson instance is secured by username and password.
- The configuration slicing plugin can update the job config on the fly, so there must be a functionality to change the job-config from a plugin without reloading the config.
I hope that I properly communicated the motivation behind this request and that I have shown that the scenarios are possible (may be even used) in the real world. For me the first use case (Hudson-Dev -> Hudson-Prod) is appealing and I would be interested to implement this in my environment.
explanation of the numbering scheme:
S ... Strategy
I ... Initialization
C ... Compare Process