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

Additional confiuguration files to back up

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Currently the main Hudson config.xml and the job config.xml are considered for back up. Please add comments for additional configuration files that should be added to the back up procedure.

      I will use the first comment as an overview for all suggested files and will update it regularly with newly suggested files.

        Attachments

          Issue Links

            Activity

            Hide
            peter_schuetze peter_schuetze added a comment - - edited
            component files impl status comments
            main Hudson config.xml 0.0.2  
              hudson.xml   contains information for the Hudson service
              all *.xml files in HUDSON_HOME   com.michelin.cio.hudson.plugins.wasbuilder.WASInstallation.xml
            config.xml
            hudson.maven.MavenModuleSet.xml
            hudson.model.UpdateCenter.xml
            hudson.plugins.emailext.ExtendedEmailPublisher.xml
            hudson.plugins.locksandlatches.LockWrapper.xml
            hudson.scm.CVSSCM.xml
            hudson.scm.SubversionSCM.xml
            hudson.tasks.Ant.xml
            hudson.tasks.Mailer.xml
            hudson.tasks.Maven.xml
            hudson.tasks.Shell.xml
            hudson.triggers.SCMTrigger.xml
            hudson.xml
            nodeMonitors.xml
            scm-sync-configuration.xml
            Jobs config.xml 0.0.1  
            build number nextBuildNumber   Only makes sense if other volatile data is stored,
            like the jobs folder of the jobs.
            configurations in matrix
            job subdirectories
            ???    
            promoted builds plugin promotions/Promotion_Name/config.xml    
            user specific patterns definable pattern   see discussions below
            Show
            peter_schuetze peter_schuetze added a comment - - edited component files impl status comments main Hudson config.xml 0.0.2     hudson.xml   contains information for the Hudson service   all *.xml files in HUDSON_HOME   com.michelin.cio.hudson.plugins.wasbuilder.WASInstallation.xml config.xml hudson.maven.MavenModuleSet.xml hudson.model.UpdateCenter.xml hudson.plugins.emailext.ExtendedEmailPublisher.xml hudson.plugins.locksandlatches.LockWrapper.xml hudson.scm.CVSSCM.xml hudson.scm.SubversionSCM.xml hudson.tasks.Ant.xml hudson.tasks.Mailer.xml hudson.tasks.Maven.xml hudson.tasks.Shell.xml hudson.triggers.SCMTrigger.xml hudson.xml nodeMonitors.xml scm-sync-configuration.xml Jobs config.xml 0.0.1   build number nextBuildNumber   Only makes sense if other volatile data is stored, like the jobs folder of the jobs. configurations in matrix job subdirectories ???     promoted builds plugin promotions/Promotion_Name/config.xml     user specific patterns definable pattern   see discussions below
            Hide
            wohauser wohauser added a comment - - edited

            May be the flow informations like last build number should be saved/syncronized too, at a crash or move of the jenkins server, this information have to be restored to be in sync.
            Also the configurations in matrix job subdirctories may be synchronized.

            Show
            wohauser wohauser added a comment - - edited May be the flow informations like last build number should be saved/syncronized too, at a crash or move of the jenkins server, this information have to be restored to be in sync. Also the configurations in matrix job subdirctories may be synchronized.
            Hide
            jchatham jchatham added a comment -

            I'm using the Promoted Builds plugin, which generates some additional configuration files. Would it be possible to allow user-specified patterns for files that need to be saved/synchronized?

            If not, the specific configuration files from that plugin are stored under jobs/Job_Name/promotions/Promotion_Name/config.xml

            Show
            jchatham jchatham added a comment - I'm using the Promoted Builds plugin, which generates some additional configuration files. Would it be possible to allow user-specified patterns for files that need to be saved/synchronized? If not, the specific configuration files from that plugin are stored under jobs/Job_Name/promotions/Promotion_Name/config.xml
            Hide
            fcamblor Frédéric Camblor added a comment -

            Yep I already thought about it ...

            There are several ways to implement this :
            1/ As you said, allow user to provide custom pattern. That way, we would be able to face every use case for every plugin.
            Drawback : Everyone should re-define its own pattern, whereas it could be interesting to share patterns for plugins (in a wiki entry for example).
            Another drawback is when a plugin will change its file path prior to a version, it will be hard to track this changes.
            2/ Hardcode some patterns in scm sync configuration plugin.
            Drawback : implementations will depend on my mood for this or that plugin . Plus, it will represent a big amount of work (and maintenance) for me. Don't like this point
            3/ I provide an extension point in my plugin, allowing other plugins to implement it to be "scm-synchronizables".
            It would be better to my mind (and allow to do more things programmaticaly than via a UI), but would imply plugin developpers to be aware of this extension point and implement it in their plugin (not sure of the adoption, especially for plugins which don't evolve. In all cases, it will take time !)

            Show
            fcamblor Frédéric Camblor added a comment - Yep I already thought about it ... There are several ways to implement this : 1/ As you said, allow user to provide custom pattern. That way, we would be able to face every use case for every plugin. Drawback : Everyone should re-define its own pattern, whereas it could be interesting to share patterns for plugins (in a wiki entry for example). Another drawback is when a plugin will change its file path prior to a version, it will be hard to track this changes. 2/ Hardcode some patterns in scm sync configuration plugin. Drawback : implementations will depend on my mood for this or that plugin . Plus, it will represent a big amount of work (and maintenance) for me. Don't like this point 3/ I provide an extension point in my plugin, allowing other plugins to implement it to be "scm-synchronizables". It would be better to my mind (and allow to do more things programmaticaly than via a UI), but would imply plugin developpers to be aware of this extension point and implement it in their plugin (not sure of the adoption, especially for plugins which don't evolve. In all cases, it will take time !)
            Hide
            peter_schuetze peter_schuetze added a comment -

            I think user definable patterns would enable a better adoption of this plugin and reduce the maintenance. I am for it, since it will require the least communication between plugin developers (and reduce the risk that a API change will break the integration of other plugins.) Predefined pattern can be published on a subpage of the wiki plugin page. So every plugin developer and every enthusiastic user can publish patterns there for users to copy and paste them into the plugin configuration page.

            Hardcoding of patterns could be done, but I would restrict it for the same reasons to a few bundled plugins and Jenkins (may be with an option to tweak it, in case something changes).

            The API sounds fantastic but, as you mentioned, it needs the cooperation/awareness of other plugin developers. Therefore I see the priority of 1/ and 3/ would be "golden" version. You could also wait with the API until a few plugin developers showed interest/requested it, before implementing the api.

            So in short:
            I like the first solution, the third is second choice. The second I would leave out.

            Show
            peter_schuetze peter_schuetze added a comment - I think user definable patterns would enable a better adoption of this plugin and reduce the maintenance. I am for it, since it will require the least communication between plugin developers (and reduce the risk that a API change will break the integration of other plugins.) Predefined pattern can be published on a subpage of the wiki plugin page. So every plugin developer and every enthusiastic user can publish patterns there for users to copy and paste them into the plugin configuration page. Hardcoding of patterns could be done, but I would restrict it for the same reasons to a few bundled plugins and Jenkins (may be with an option to tweak it, in case something changes). The API sounds fantastic but, as you mentioned, it needs the cooperation/awareness of other plugin developers. Therefore I see the priority of 1/ and 3/ would be "golden" version. You could also wait with the API until a few plugin developers showed interest/requested it, before implementing the api. So in short: I like the first solution, the third is second choice. The second I would leave out.
            Hide
            lothar Lothar Werzinger added a comment - - edited

            +1 for user editable patterns (multiple)

            Show
            lothar Lothar Werzinger added a comment - - edited +1 for user editable patterns (multiple)
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Frédéric Camblor
            Path:
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/AbstractScmSyncStrategy.java
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/impl/JenkinsConfigScmSyncStrategy.java
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/impl/JobConfigScmSyncStrategy.java
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/ClassAndFileConfigurationEntityMatcher.java
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/ConfigurationEntityMatcher.java
            src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/PatternsEntityMatcher.java
            http://jenkins-ci.org/commit/scm-sync-configuration-plugin/561266a7499b4797d903c021dcac1daab9a17990
            Log:
            Refactored PatternsEntityMatcher.pattern field from Pattern to String, using ant-like includes instead of regexes, for sync'ed files => ScmSyncStrategy.createInitializationSynchronizedFileset() can be simplified by using these includes.
            Will be a first step for implementing JENKINS-8225

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Frédéric Camblor Path: src/main/java/hudson/plugins/scm_sync_configuration/strategies/AbstractScmSyncStrategy.java src/main/java/hudson/plugins/scm_sync_configuration/strategies/impl/JenkinsConfigScmSyncStrategy.java src/main/java/hudson/plugins/scm_sync_configuration/strategies/impl/JobConfigScmSyncStrategy.java src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/ClassAndFileConfigurationEntityMatcher.java src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/ConfigurationEntityMatcher.java src/main/java/hudson/plugins/scm_sync_configuration/strategies/model/PatternsEntityMatcher.java http://jenkins-ci.org/commit/scm-sync-configuration-plugin/561266a7499b4797d903c021dcac1daab9a17990 Log: Refactored PatternsEntityMatcher.pattern field from Pattern to String, using ant-like includes instead of regexes, for sync'ed files => ScmSyncStrategy.createInitializationSynchronizedFileset() can be simplified by using these includes. Will be a first step for implementing JENKINS-8225
            Hide
            fcamblor Frédéric Camblor added a comment -

            User-defined backup file will be available in incoming v0.0.6
            Wiki has now a dedicated page to share your own includes

            Show
            fcamblor Frédéric Camblor added a comment - User-defined backup file will be available in incoming v0.0.6 Wiki has now a dedicated page to share your own includes

              People

              • Assignee:
                fcamblor Frédéric Camblor
                Reporter:
                peter_schuetze peter_schuetze
              • Votes:
                3 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: