Details
-
Improvement
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
Description
When using the "Install automatically", an install is performed from the repositories as it stands right there and then. Subsequent updates to the repository will not be picked up automatically. I think that's fine. I would however like a way to force an update. It could be as simple as just removing whatever is there first and then reinstall from scratch using the same config.
Attachments
Activity
Code changed in hudson
User: : jutzig
Path:
trunk/hudson/plugins/buckminster/src/main/java/hudson/plugins/buckminster/BuckminsterInstallation.java
trunk/hudson/plugins/buckminster/src/main/java/hudson/plugins/buckminster/command/CommandLineBuilder.java
trunk/hudson/plugins/buckminster/src/main/resources/hudson/plugins/buckminster/BuckminsterInstallation/BuckminsterInstaller/config.jelly
trunk/hudson/plugins/buckminster/src/main/resources/hudson/plugins/buckminster/BuckminsterInstallation/BuckminsterInstaller/config_de.properties
trunk/hudson/plugins/buckminster/src/main/resources/hudson/plugins/buckminster/BuckminsterInstallation/config.jelly
trunk/hudson/plugins/buckminster/src/main/webapp/help-update.html
trunk/hudson/plugins/buckminster/src/main/webapp/help-update_de.html
http://jenkins-ci.org/commit/29335
Log:
JENKINS-6065 Need a way to force update of an install
jutzig
added a comment - That sounds very promising.
To sum this up:
1. use the director instead of buckminster install
2. if buckminster does not exist (initial install) invoke
director -i product
-i featureA
-i featureB
3. if buckminster already exists and update flag was set in the hudson config invoke:
director -u featureA
-i featureA
-u featureB
-i featureB
That way the admin can define a stable buckminster without automatic update and a 'bleeding edge' buckminster that gets updated whenever there is something new. If the director really transforms -u + -i into an update than the update check itself shouldn't take too long so it is no big deal to run that before every build.
Alright, if I got you right with everything, I will implement it like that, otherwise correct me.
jutzig
added a comment - That sounds very promising.
To sum this up:
1. use the director instead of buckminster install
2. if buckminster does not exist (initial install) invoke
director -i product
-i featureA
-i featureB
3. if buckminster already exists and update flag was set in the hudson config invoke:
director -u featureA
-i featureA
-u featureB
-i featureB
That way the admin can define a stable buckminster without automatic update and a 'bleeding edge' buckminster that gets updated whenever there is something new. If the director really transforms -u + -i into an update than the update check itself shouldn't take too long so it is no big deal to run that before every build.
Alright, if I got you right with everything, I will implement it like that, otherwise correct me.
thhal
added a comment - Uh, I wrote "the trick for update is just to append '.feature.group'. That was a typo. The '.feature.group' has nothing to do with updates. It's just the way p2 names all features so the director needs that to be able to identify them. The buckminster installer however, does not.
thhal
added a comment - Uh, I wrote "the trick for update is just to append '.feature.group'. That was a typo. The '.feature.group' has nothing to do with updates. It's just the way p2 names all features so the director needs that to be able to identify them. The buckminster installer however, does not. thhal
added a comment - Thinking more about this. If the director receives both an -u <feature> and -i<feature> on the same <feature>, it will come up with a plan for an update if a newer version is available. So perhaps its as simple as doing that on all features (except the product itself).
Ideally, I think you should abandon the buckminster install and instead just use the director. An initial install of a fully configured buckminster can be made with one single director call using repeated -i <feature> [ -i <feature> ... ], i.e.,
director
-i org.eclipse.buckminster.cmdline.product
-i org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-i ...
-r <repo>
The trick for update is to just append '.feature.group' at the end of each feature. A call like this:
director
-u org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.core.headless.feature.feature.group
-u org.eclipse.buckminster.pde.headless.feature.featuregroup
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-u ... -i ...
-r <repo>
will result in an update if updates are available.
thhal
added a comment - Thinking more about this. If the director receives both an -u <feature> and -i<feature> on the same <feature>, it will come up with a plan for an update if a newer version is available. So perhaps its as simple as doing that on all features (except the product itself).
Ideally, I think you should abandon the buckminster install and instead just use the director. An initial install of a fully configured buckminster can be made with one single director call using repeated -i <feature> [ -i <feature> ... ], i.e.,
director
-i org.eclipse.buckminster.cmdline.product
-i org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-i ...
-r <repo>
The trick for update is to just append '.feature.group' at the end of each feature. A call like this:
director
-u org.eclipse.buckminster.core.headless.feature.feature.group
-i org.eclipse.buckminster.core.headless.feature.feature.group
-u org.eclipse.buckminster.pde.headless.feature.featuregroup
-i org.eclipse.buckminster.pde.headless.feature.featuregroup
-u ... -i ...
-r <repo>
will result in an update if updates are available. jutzig
added a comment - I do understand the need of that, but it raises a few issues depending on how and when this is triggered:
First Option:
This is a setting in the 'Manage Hudson' page as part of the Buckminster Installation configuration (a checkbox 'update automatically' or so). In this case the tool gets deleted and re-installed every time a build runs. This sounds a bit heavy to me but could be considered
Second Option:
this setting is part of a build job (update before execution)
That however is problematic. The managment of tool installations are a job of an admin whereas the job configuration is the responsibility of the job owner. The job should probably not be allowed to delete/alter the configuration given by the hudson admin (since the effects are global).
None of these I really like to be honest. It would be better to have the ability to actually update (or at least check for updates) instead of deleting and installing again. Is there a way (planned at least) to update buckminster, or is there a way for the director application to perform an update?
If not, would it be possible to check for updates to see if it makes sense to erase the existing installation and provision a new one?
That would match best with the workflows in hudson, since that way the first option could be used (make it part of the hudson configuration if the tool should be updated) while avoiding excessive network traffic.
The other installers (that download things) work in a similar way. When the tool is requested they check if it is already present. If so, they check if the download archive has been updated since the tool was installed. If so, they download the newer version and replace the old tool.
jutzig
added a comment - I do understand the need of that, but it raises a few issues depending on how and when this is triggered:
First Option:
This is a setting in the 'Manage Hudson' page as part of the Buckminster Installation configuration (a checkbox 'update automatically' or so). In this case the tool gets deleted and re-installed every time a build runs. This sounds a bit heavy to me but could be considered
Second Option:
this setting is part of a build job (update before execution)
That however is problematic. The managment of tool installations are a job of an admin whereas the job configuration is the responsibility of the job owner. The job should probably not be allowed to delete/alter the configuration given by the hudson admin (since the effects are global).
None of these I really like to be honest. It would be better to have the ability to actually update (or at least check for updates) instead of deleting and installing again. Is there a way (planned at least) to update buckminster, or is there a way for the director application to perform an update?
If not, would it be possible to check for updates to see if it makes sense to erase the existing installation and provision a new one?
That would match best with the workflows in hudson, since that way the first option could be used (make it part of the hudson configuration if the tool should be updated) while avoiding excessive network traffic.
The other installers (that download things) work in a similar way. When the tool is requested they check if it is already present. If so, they check if the download archive has been updated since the tool was installed. If so, they download the newer version and replace the old tool. 
Fix released to TRUNK revision 20055. Will be available in version 1.0.0.
Now there is a new checkbox in the Tool configuration (update before build).
If this checkbox is set, the installation will be updated automatically before every build run.
If new features are added into the JSON file, they will be installed, if features get removed from the JSON file, they get also removed from the buckminster installation.
As long as there are no updates/new features available the update check should finish rather quickly (a few seconds) so the impact on the overall build time should be low.