Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6065

Need a way to force update of an install

    XMLWordPrintable

    Details

    • Similar Issues:

      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

          Hide
          jutzig 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.

          Show
          jutzig 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.
          Hide
          thhal 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.

          Show
          thhal 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.
          Hide
          thhal 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.

          Show
          thhal 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.
          Hide
          jutzig 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.

          Show
          jutzig 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.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          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

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - 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
          Hide
          jutzig jutzig added a comment -

          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.

          Show
          jutzig jutzig added a comment - 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.

            People

            Assignee:
            jutzig jutzig
            Reporter:
            thhal thhal
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: