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

scm-sync URL should be per job

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Currently scm-sync-configuration plugin allows specifying single repository URL for everything.
      It would very nice to be able to set distinct arbitrary repo URLs (and credentials) for each job.

      USE CASE
      We have tens of branches in http://svn/outRepo/.../branches/.
      Each branch is built from SVN URL http://svn/outRepo/.../branches/branchXYZ/.
      We want to have http://svn/outRepo/.../branches/branchXYZ/hudson_ci_stuff dir in each branch to be synced with relevant Hudson job config files.

      CONSEQUENCES
      Updating job's config in Hudson UI will trigger SCM change in relevant job due to commit to hudson_ci_stuff.

      FURTHER DISCUSSION
      Possibly a subject to another feature request is truly two way sync: i.e. when somebody manually makes a commit to hudson_ci_stuff, scm-sync-configuration plugin should push job config update to Hudson core.
      And another logical step - about which I, as the one maintaining our HudsonCI deployment, dream very often - is the ability to auto-import jobs from SCM. I.e. once we create a branch from http://svn/outRepo/.../trunk, scm-sync-configuration plugin should discover new http://svn/outRepo/.../branches/branchZZZ/ and auto create job "branchZZZ" from configuration stored in http://svn/outRepo/.../branches/branchZZZ/hudson_ci_stuff.

        Attachments

          Issue Links

            Activity

            Hide
            fcamblor Frédéric Camblor added a comment -

            I think synchronizing things in a "per job" way will become very complex.
            Moreover, don't see the scm-sync-configuration plugin as a "job only" backup. Aim is to backup lots of other entities (like global hudson system properties, plugin configurations, views, users etc..)

            For me, it is a really job specific stuff, I won't prioritize this for the moment.

            Nevertheless, on the 2 way sync topic, if you read http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin, you'll notice this functionality is in my todo list.
            For me, there is 2 different use cases :

            • Provide a "commit history" on the current configuration file, allowing to see who/why commit occured on the configuration file. Ideally, this screen could detect a "current configuration file is not up-to-date" (if commited on the SCM by someone else than current hudson instance) and allow to update current configuration file.
            • Provide a "mirroring" functionality allowing to "auto update" commit on files regularly (very useful, for instance, when we are using a hudson production environnement, mirrored with a "pre-production" hudson environnment).

            For the auto import jobs functionality, this is for me, too, a target objective. Allowing to create some job archetypes for my projects, and import massively them in hudson.

            Show
            fcamblor Frédéric Camblor added a comment - I think synchronizing things in a "per job" way will become very complex. Moreover, don't see the scm-sync-configuration plugin as a "job only" backup. Aim is to backup lots of other entities (like global hudson system properties, plugin configurations, views, users etc..) For me, it is a really job specific stuff, I won't prioritize this for the moment. Nevertheless, on the 2 way sync topic, if you read http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin , you'll notice this functionality is in my todo list. For me, there is 2 different use cases : Provide a "commit history" on the current configuration file, allowing to see who/why commit occured on the configuration file. Ideally, this screen could detect a "current configuration file is not up-to-date" (if commited on the SCM by someone else than current hudson instance) and allow to update current configuration file. Provide a "mirroring" functionality allowing to "auto update" commit on files regularly (very useful, for instance, when we are using a hudson production environnement, mirrored with a "pre-production" hudson environnment). For the auto import jobs functionality, this is for me, too, a target objective. Allowing to create some job archetypes for my projects, and import massively them in hudson.
            Hide
            pancake pancake added a comment -

            All described features are really nice.
            As for "per job" - I guess for now we can try do some hacky solution using svn externals.

            Show
            pancake pancake added a comment - All described features are really nice. As for "per job" - I guess for now we can try do some hacky solution using svn externals.
            Hide
            peter_schuetze peter_schuetze added a comment - - edited

            From my point of view, the job specific URLS are not that important. I was thinking about it to, but in my case I rather have everything in one place than to hunt in different projects for my Hudson configuration (1. separation of concerns; 2. high maintenance to deny developers write access to Hudson config in SVN).

            I also see the creation of a Hudson job from a branch as an highly specialized use case with difficulties to implement general rules for discovery of a new job in svn, whereas the creation of a new job from a centralized place in SVN (all job configs stored together) is way easier (from the perspective of discovering a new job config). (On easy way to implement the job discovery is to mark jobs with a SVN property. So only URLs that contain the job property will trigger the creation of a new job.

            The issue of automatically triggering a build, when the job config changes, is in my opinion irrelevant as long as you do all the job changes manually, since you just hit the build button after you did you changes.

            When I have major changes to a job, I usually save the job config several times before I run a test build. If I do everything in one big change, I tend to loose changes to often, due to my clumsy way to use browsers.

            I think a really nice feature is the synchronizing Hudson with SVN. U hope it is possible to change the config of one job without triggering the config reload on server level.

            Show
            peter_schuetze peter_schuetze added a comment - - edited From my point of view, the job specific URLS are not that important. I was thinking about it to, but in my case I rather have everything in one place than to hunt in different projects for my Hudson configuration (1. separation of concerns; 2. high maintenance to deny developers write access to Hudson config in SVN). I also see the creation of a Hudson job from a branch as an highly specialized use case with difficulties to implement general rules for discovery of a new job in svn, whereas the creation of a new job from a centralized place in SVN (all job configs stored together) is way easier (from the perspective of discovering a new job config). (On easy way to implement the job discovery is to mark jobs with a SVN property. So only URLs that contain the job property will trigger the creation of a new job. The issue of automatically triggering a build, when the job config changes, is in my opinion irrelevant as long as you do all the job changes manually, since you just hit the build button after you did you changes. When I have major changes to a job, I usually save the job config several times before I run a test build. If I do everything in one big change, I tend to loose changes to often, due to my clumsy way to use browsers. I think a really nice feature is the synchronizing Hudson with SVN. U hope it is possible to change the config of one job without triggering the config reload on server level.
            Hide
            fcamblor Frédéric Camblor added a comment -

            FYI, I have in my todo list (http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin) a functionality allowing the user to check "don't bother me during XXX minutes" in the commit message prompt.

            If checked, message prompt won't reappear (obviously for the current job only) until XXX minutes.
            Particularly useful if, as you say, you're playing with your job configuration and trying to enhance a build execution.
            I admit in these particular case, the commit message prompt is really too intrusive for the user.

            For all the other cases, my point of view is the commit message prompt is a good reminder to detail what has just be done.

            Show
            fcamblor Frédéric Camblor added a comment - FYI, I have in my todo list ( http://wiki.jenkins-ci.org/display/JENKINS/SCM+Sync+configuration+plugin ) a functionality allowing the user to check "don't bother me during XXX minutes" in the commit message prompt. If checked, message prompt won't reappear (obviously for the current job only) until XXX minutes. Particularly useful if, as you say, you're playing with your job configuration and trying to enhance a build execution. I admit in these particular case, the commit message prompt is really too intrusive for the user. For all the other cases, my point of view is the commit message prompt is a good reminder to detail what has just be done.
            Hide
            peter_schuetze peter_schuetze added a comment - - edited

            The commit message would bother me less than the effect, that my build job runs several times before I am done with my configuration work (the implementation that pancake was asking for). Especially, since some of my jobs take 15 minutes and longer and might also trigger other jobs to be build. So the don't bother me is currently nothing of concern for me.

            After thinking about what was said before about triggering a job when only the job config changed. You don't need to bother about it. For Subversion you can configure exceptions, that don't trigger a job. I think this is more an SCM issue that an scm-sync-plugin issue. Another example of the same issue is updating the build number and commiting back to the scm. You don't want to have a build triggered than either.

            Show
            peter_schuetze peter_schuetze added a comment - - edited The commit message would bother me less than the effect, that my build job runs several times before I am done with my configuration work (the implementation that pancake was asking for). Especially, since some of my jobs take 15 minutes and longer and might also trigger other jobs to be build. So the don't bother me is currently nothing of concern for me. After thinking about what was said before about triggering a job when only the job config changed. You don't need to bother about it. For Subversion you can configure exceptions, that don't trigger a job. I think this is more an SCM issue that an scm-sync-plugin issue. Another example of the same issue is updating the build number and commiting back to the scm. You don't want to have a build triggered than either.
            Hide
            peter_schuetze peter_schuetze added a comment -

            I put the synchronization of the configs in a separate issue, to discuss the implementation of the ToDo list item.

            Show
            peter_schuetze peter_schuetze added a comment - I put the synchronization of the configs in a separate issue, to discuss the implementation of the ToDo list item.
            Hide
            peter_schuetze peter_schuetze added a comment -

            fcamblor mentioned that it is complex to have the scm path dependent on the job. I can only come up with one solution, which would be to store a separate synchronization URL on every job. If non is configured the main URL will be used. If the job URL changes, the configuration will be moved to the new location in SCM.

            This will also solve the automatic creation of a job. See following workflow.
            1. read config from scm
            2. check scm sync url for new job, if it exists, move config in scm.
            3. create job.

            I vote for not implementing pancake's logic for the scm URL, since it is highly specific. The next user will come up with a slightly different solution.

            If pancake needs an easy way of using a job template, I would vote for implementing the use of job variables to calculate the job URL. In this case you can change the job name and the job will move in the SCM. This would make it necessary to store the variables used in the URL every time, the job config is commited to the scm.

            Show
            peter_schuetze peter_schuetze added a comment - fcamblor mentioned that it is complex to have the scm path dependent on the job. I can only come up with one solution, which would be to store a separate synchronization URL on every job. If non is configured the main URL will be used. If the job URL changes, the configuration will be moved to the new location in SCM. This will also solve the automatic creation of a job. See following workflow. 1. read config from scm 2. check scm sync url for new job, if it exists, move config in scm. 3. create job. I vote for not implementing pancake's logic for the scm URL, since it is highly specific. The next user will come up with a slightly different solution. If pancake needs an easy way of using a job template, I would vote for implementing the use of job variables to calculate the job URL. In this case you can change the job name and the job will move in the SCM. This would make it necessary to store the variables used in the URL every time, the job config is commited to the scm.

              People

              Assignee:
              fcamblor Frédéric Camblor
              Reporter:
              pancake pancake
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: