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

new field in the "feature branch" creation form, to manage multi-project repository layout

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When creating a new feature branch, the current version asks the user for the branch name and an optional commit message.
      In the case of a single-project repository layout, that works just fine: a new branch is created under "/branches" using the provided name, and the source code is copied directly into the new branch; besides, a new job is created with a name composed by concatenating the original job name with the name of the new branch.

      In case of a multi-project repository layout (http://svnbook.red-bean.com/en/1.0/ch05s04.html), the location of the new branch must be composed by concatenating the branch name and the sub-project name. This can be achieved using a simple workaround: specifing the complete location of the new branch in the "branch name" input field, e.g. "mynewbranch/projX". This approach is error prone and one drawback is the name of the new job which results in a long and possibly non-intuitive name that must be changed manually. (e.g. "projX-mynewbranch-projX")

      In addition, since we've adopted a development process that forbids direct development in trunk, we need to tag the trunk version when creating a new branch, to track back the state of the trunk in the moment the new branch is created. In particular, we have a tags/dev folder in our repo for that kind of tags, and a tags/rel folder for the effective released versions.

      To address the needs of this scenario, I suggest to implement more fields in the "new feature branch creation" page, to give the user the means to control the newly created job in a more fine-grained way, including the opportunity to create a tag while creating the branch.
      Let me know if this feature can be useful for the community, I'm going on with the analysis to provide a more concrete proposal.
      I'm available to take in charge the development.
      Cheers

      Verny

        Attachments

          Issue Links

            Activity

            verny Verny Quartara Gutierrez created issue -
            verny Verny Quartara Gutierrez made changes -
            Field Original Value New Value
            Attachment adv_options.png [ 25656 ]
            Hide
            verny Verny Quartara Gutierrez added a comment -

            I did a little more analysis on the feature: I'm thinking about something like in the attached picture (adv_options.png).

            If "Single Project Repository Layout" is selected, everything works as is now.

            If "Multi Project Repository Layout" is selected, the user can optionally specify a "subproject name" (that is the actual subfolder under /branches/branchname).

            If "Create a development tag" is checked, a tag will be created and the user can optionally specify a "Tag subfolder" value (that is the actual subfolder under /tags).

            Some examples, given job name = "testproject" and Branch Name = 1.6.0
            a) with "Single Project Repository Layout" selected, a new branch will be created in /branches/1.6.0 and the new job name will be "testproject-1.6.0
            b) with "Multi Project Repository Layout" selected, a new branch will be created in /branches/1.6.0/testproject (unless the user specify another name using the "Subproject name" text input) and the new job name will be "testproject-1.6.0"
            c) with "Create a development tag" checked, a new tag will be created in /tags/dev/1.6.0 (unless the user specify another name using the "Tag subfolder" text input)

            I hope this proposal is not too tied to my current development environment, in that case you should provide others scenarios to merge with.

            Show
            verny Verny Quartara Gutierrez added a comment - I did a little more analysis on the feature: I'm thinking about something like in the attached picture (adv_options.png). If "Single Project Repository Layout" is selected, everything works as is now. If "Multi Project Repository Layout" is selected, the user can optionally specify a "subproject name" (that is the actual subfolder under /branches/branchname). If "Create a development tag" is checked, a tag will be created and the user can optionally specify a "Tag subfolder" value (that is the actual subfolder under /tags). Some examples, given job name = "testproject" and Branch Name = 1.6.0 a) with "Single Project Repository Layout" selected, a new branch will be created in /branches/1.6.0 and the new job name will be "testproject-1.6.0 b) with "Multi Project Repository Layout" selected, a new branch will be created in /branches/1.6.0/testproject (unless the user specify another name using the "Subproject name" text input) and the new job name will be "testproject-1.6.0" c) with "Create a development tag" checked, a new tag will be created in /tags/dev/1.6.0 (unless the user specify another name using the "Tag subfolder" text input) I hope this proposal is not too tied to my current development environment, in that case you should provide others scenarios to merge with.
            Hide
            hugueschabot Hugues Chabot added a comment -

            The Multi Project Layout is documented in the Subversion Book. I think it should be well supported by the plugin.

            However, is it possible to handle that directory structure in a general way? For instance, given a SVN path prefix/(trunk|branches)(/suffix)? and a branch name feature, we could create the new branch in prefix/branches/feature/suffix. In the case of a multi projects layout, suffix is the sub-project name, isn't it?

            In the end, the advanced options could be the complete path of the branch/tag with default values based on your proposal.

            Show
            hugueschabot Hugues Chabot added a comment - The Multi Project Layout is documented in the Subversion Book . I think it should be well supported by the plugin. However, is it possible to handle that directory structure in a general way? For instance, given a SVN path prefix /(trunk|branches)(/ suffix )? and a branch name feature , we could create the new branch in prefix /branches/ feature / suffix . In the case of a multi projects layout, suffix is the sub-project name, isn't it? In the end, the advanced options could be the complete path of the branch/tag with default values based on your proposal.
            hugueschabot Hugues Chabot made changes -
            Link This issue is blocking JENKINS-15830 [ JENKINS-15830 ]
            Hide
            verny Verny Quartara Gutierrez added a comment -

            Yes, the directory structure should be handled in a general way, and yes the suffix in your example is the sub-project name.
            What should be the caption of the form input fields, in your opinion? As in your example?

            Show
            verny Verny Quartara Gutierrez added a comment - Yes, the directory structure should be handled in a general way, and yes the suffix in your example is the sub-project name. What should be the caption of the form input fields, in your opinion? As in your example?
            Hide
            hugueschabot Hugues Chabot added a comment -

            Suppose one create a new feature branch named feature. Here are some examples of the default branch URL based on the upstream URL.

            Upstream SVN URL Branch SVN URL (default)
            http://svnserver/trunk http://svnserver/branches/feature
            http://svnserver/branches/other http://svnserver/branches/feature
            http://svnserver/trunk/subproject http://svnserver/branches/subproject/feature
            http://svnserver/branches/subproject/other http://svnserver/branches/subproject/feature
            http://svnserver/project/trunk http://svnserver/project/branches/feature
            http://svnserver/project/branches/other http://svnserver/project/branches/feature

            These examples differ from what is proposed in this issue's first comment. I am used to see the feature branch name at the end of the URL but it may be a matter of personal taste.

            Show
            hugueschabot Hugues Chabot added a comment - Suppose one create a new feature branch named feature . Here are some examples of the default branch URL based on the upstream URL. Upstream SVN URL Branch SVN URL (default) http://svnserver/trunk http://svnserver/branches/ feature http://svnserver/branches/other http://svnserver/branches/ feature http://svnserver/trunk/subproject http://svnserver/branches/subproject/ feature http://svnserver/branches/subproject/other http://svnserver/branches/subproject/ feature http://svnserver/project/trunk http://svnserver/project/branches/ feature http://svnserver/project/branches/other http://svnserver/project/branches/ feature These examples differ from what is proposed in this issue's first comment. I am used to see the feature branch name at the end of the URL but it may be a matter of personal taste.
            Hide
            verny Verny Quartara Gutierrez added a comment -

            In the case of multi project layout, more than a matter of personal taste, it can depends on how much related the subprojects are: look at this question that refers to the CollabNet Subversion blog.

            I agree that it's common to have the feature branch name at the of the URL, so I suggest to support these kind of URLs in addition to that listed above:

            Upstream SVN URL Branch SVN URL(default)
            http://svnserver/project/trunk/subproject http://svnserver/project/branches/feature/subproject
            http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/anotherfeature/subproject

            This lead to have the feature branch creation form a little bit more complex, but this way we'll be able to handle the three cases:

            • single project layout
            • multi project layout with non-related projects or loosely-related projects
            • multi project layout with closely related project
            Show
            verny Verny Quartara Gutierrez added a comment - In the case of multi project layout, more than a matter of personal taste, it can depends on how much related the subprojects are: look at this question that refers to the CollabNet Subversion blog. I agree that it's common to have the feature branch name at the of the URL, so I suggest to support these kind of URLs in addition to that listed above: Upstream SVN URL Branch SVN URL(default) http://svnserver/project/trunk/subproject http://svnserver/project/branches/ feature /subproject http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/ anotherfeature /subproject This lead to have the feature branch creation form a little bit more complex, but this way we'll be able to handle the three cases: single project layout multi project layout with non-related projects or loosely-related projects multi project layout with closely related project
            Hide
            hugueschabot Hugues Chabot added a comment -

            I understand, it makes a lot of sense to support the "multi project layout with closely related project" too.

            Show
            hugueschabot Hugues Chabot added a comment - I understand, it makes a lot of sense to support the "multi project layout with closely related project" too.
            verny Verny Quartara Gutierrez made changes -
            Affects Version/s current [ 10162 ]
            Due Date 2014-05-03 2014-05-11
            verny Verny Quartara Gutierrez made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            verny Verny Quartara Gutierrez added a comment -

            latest proposal of the new branch creation form

            Show
            verny Verny Quartara Gutierrez added a comment - latest proposal of the new branch creation form
            verny Verny Quartara Gutierrez made changes -
            Attachment adv_options_v2.png [ 25767 ]
            Hide
            verny Verny Quartara Gutierrez added a comment -

            Updated the screenshot of my proposal.

            The use of regular expressions simplifies the repository layout detection (based on the upstream svn url) and in most cases can detect automatically the new branch location, without the need to manually provide the subproject name (if any). When the repository layout does not follows standard conventions, as mentioned in JENKINS-15830, the user is needed to manually provide the new branch url.

            In conclusion, I changed my initial idea and now I believe that doing a little bit more advanced use of regex we can support a good range of repository layouts, substantially resolving the other mentioned issue as well.

            It's important to point that using regex these urls

            cannot be distinguished, so we have to assume a convention for the multi layout case.
            I assumed the branch name always follows the "branches" folder, so for example for the following upstream svn url

            the default new branch location will be: http://svnserver/branches/<new_branch_name>/other/

            Here is the complete list of the different upstream URL supported:

            Upstream SVN URL Branch SVN URL (default) Tag SVN URL (default, optional)
            http://svnserver/trunk http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name>
            http://svnserver/branches/other http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name>
            http://svnserver/trunk/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject
            http://svnserver/branches/other/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject
            http://svnserver/project/trunk http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name>
            http://svnserver/project/branches/other http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name>
            http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject
            http://svnserver/project/trunk/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject
            http://svnserver.com/FolderTrunk/Folder2/Folder3/Folder4/ProjectName unable to infer, user must provide the url unable to infer, user must provide the url
            http://svnserver.com/FolderBranches/Folder2/A/B/C/FeatureBranch unable to infer, user must provide the url unable to infer, user must provide the url
            Show
            verny Verny Quartara Gutierrez added a comment - Updated the screenshot of my proposal. The use of regular expressions simplifies the repository layout detection (based on the upstream svn url) and in most cases can detect automatically the new branch location, without the need to manually provide the subproject name (if any). When the repository layout does not follows standard conventions, as mentioned in JENKINS-15830 , the user is needed to manually provide the new branch url. In conclusion, I changed my initial idea and now I believe that doing a little bit more advanced use of regex we can support a good range of repository layouts, substantially resolving the other mentioned issue as well. It's important to point that using regex these urls http://svnserver/branches/subproject/branchname http://svnserver/branches/branchname/subproject cannot be distinguished, so we have to assume a convention for the multi layout case. I assumed the branch name always follows the "branches" folder, so for example for the following upstream svn url http://svnserver/branches/subproject/other the default new branch location will be: http://svnserver/branches/ <new_branch_name>/other/ Here is the complete list of the different upstream URL supported: Upstream SVN URL Branch SVN URL (default) Tag SVN URL (default, optional) http://svnserver/trunk http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name> http://svnserver/branches/other http://svnserver/branches/<new_branch_name> http://svnserver/tags/dev/<new_branch_name> http://svnserver/trunk/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject http://svnserver/branches/other/subproject http://svnserver/branches/<new_branch_name>/subproject http://svnserver/tags/dev/<new_branch_name>/subproject http://svnserver/project/trunk http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name> http://svnserver/project/branches/other http://svnserver/project/branches/<new_branch_name> http://svnserver/project/tags/dev/<new_branch_name> http://svnserver/project/branches/feature/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject http://svnserver/project/trunk/subproject http://svnserver/project/branches/<new_branch_name>/subproject http://svnserver/project/tags/dev/<new_branch_name>/subproject http://svnserver.com/FolderTrunk/Folder2/Folder3/Folder4/ProjectName unable to infer, user must provide the url unable to infer, user must provide the url http://svnserver.com/FolderBranches/Folder2/A/B/C/FeatureBranch unable to infer, user must provide the url unable to infer, user must provide the url
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Hugues Chabot
            Path:
            .gitignore
            src/main/java/jenkins/plugins/svnmerge/IntegratableProjectAction.java
            src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutEnum.java
            src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutInfo.java
            src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.groovy
            src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.properties
            src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.groovy
            src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.properties
            src/test/java/jenkins/plugins/svnmerge/RepositoryLayoutInfoTest.java
            http://jenkins-ci.org/commit/svnmerge-plugin/6598e037fd58781bbc0c1965e322219cca2c535d
            Log:
            Merge pull request #13 from hugueschabot/jenkins-22284

            [FIXED JENKINS-22284] Improve branch creation
            [FIXED JENKINS-15830] Error: Unable to infer the new branch name from XXX

            Compare: https://github.com/jenkinsci/svnmerge-plugin/compare/ca285ed64c31...6598e037fd58

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Hugues Chabot Path: .gitignore src/main/java/jenkins/plugins/svnmerge/IntegratableProjectAction.java src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutEnum.java src/main/java/jenkins/plugins/svnmerge/RepositoryLayoutInfo.java src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.groovy src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/_attach.properties src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.groovy src/main/resources/jenkins/plugins/svnmerge/IntegratableProjectAction/index.properties src/test/java/jenkins/plugins/svnmerge/RepositoryLayoutInfoTest.java http://jenkins-ci.org/commit/svnmerge-plugin/6598e037fd58781bbc0c1965e322219cca2c535d Log: Merge pull request #13 from hugueschabot/jenkins-22284 [FIXED JENKINS-22284] Improve branch creation [FIXED JENKINS-15830] Error: Unable to infer the new branch name from XXX Compare: https://github.com/jenkinsci/svnmerge-plugin/compare/ca285ed64c31...6598e037fd58
            Hide
            alex_ouzounis Alex Ouzounis added a comment -

            related if not duplicate

            Show
            alex_ouzounis Alex Ouzounis added a comment - related if not duplicate
            alex_ouzounis Alex Ouzounis made changes -
            Link This issue is related to JENKINS-15615 [ JENKINS-15615 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 154365 ] JNJira + In-Review [ 185499 ]

              People

              Assignee:
              kohsuke Kohsuke Kawaguchi
              Reporter:
              verny Verny Quartara Gutierrez
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated: