-
New Feature
-
Resolution: Unresolved
-
Minor
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
- is blocking
-
JENKINS-15830 Error: Unable to infer the new branch name from XXX
-
- Open
-
- is related to
-
JENKINS-15615 Feature Branch does not copy all modules
-
- Open
-
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.