Our repository contains a variant of the git-flow branch naming convention, where you will see
      branches such as dev/main or release/3.2

      Using multibranch, strange things happen:

      • dev/main gets displayed as dev%2Fmain, then on restart dev%252Fmain, then dev%25252Fmain and all history seems to be lost.

      This is likely down to / being a dodgy delimiter for a project name. I tried to fix this by adjusting WorkflowBranchProjectFactory thusly:

      -        WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branch.getName());
      +        String branchName = branch.getName().replace("/", "-");
      +        WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branchName);
      

      but it didn't seem to help.

      Happy to try to fix if I can get a pointer as to what to look at.

          [JENKINS-30744] multibranch issues if branch contains /

          magnayn created issue -
          Jesse Glick made changes -
          Labels Original: workflow New: multibranch
          Jesse Glick made changes -
          Description Original: Our repository contains a variant of the git-flow branch naming convention, where you will see
          branches such as dev/main or release/3.2

          Using multibranch, strange things happen:

          - dev/main gets displayed as dev%2Fmain, then on restart dev%252Fmain, then dev%25252Fmain and all history seems to be lost.

          This is likely down to / being a dodgy delimiter for a project name. I tried to fix this by adjusting WorkflowBranchProjectFactory thusly:

          - WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branch.getName());
          +
          + String branchName = branch.getName().replace("/", "-");
          +
          + WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branchName);

          but it didn't seem to help.

          Happy to try to fix if I can get a pointer as to what to look at.
          New: Our repository contains a variant of the git-flow branch naming convention, where you will see
          branches such as {{dev/main}} or {{release/3.2}}

          Using multibranch, strange things happen:

          - {{dev/main}} gets displayed as {{dev%2Fmain}}, then on restart {{dev%252Fmain}}, then {{dev%25252Fmain}} and all history seems to be lost.

          This is likely down to {{/}} being a dodgy delimiter for a project name. I tried to fix this by adjusting {{WorkflowBranchProjectFactory}} thusly:

          {code}
          - WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branch.getName());
          + String branchName = branch.getName().replace("/", "-");
          + WorkflowJob job = new WorkflowJob((WorkflowMultiBranchProject) getOwner(), branchName);
          {code}

          but it didn't seem to help.

          Happy to try to fix if I can get a pointer as to what to look at.

          Jesse Glick added a comment -

          Seems like your proposed patch should have addressed it, though at the expense of potential clashes with branches actually named dev-main or release-3.2. Solving that would require a reversible encoding such as the URL-encoding you observed, but working of course.

          Not sure if this has to be handled in workflow-multibranch, branch-api, or both. Need to think about it, write tests, and perhaps consult with stephenconnolly to see if this ever came up for Literate and how it was handled. I suspect the encoding in MultiBranchProject.getRootDirFor is relevant, but using a / inside an Item.getName is invalid generally (regardless of disk storage location), as that breaks the semantics of Item.getFullName and much else besides.

          Jesse Glick added a comment - Seems like your proposed patch should have addressed it, though at the expense of potential clashes with branches actually named dev-main or release-3.2 . Solving that would require a reversible encoding such as the URL-encoding you observed, but working of course. Not sure if this has to be handled in workflow-multibranch , branch-api , or both. Need to think about it, write tests, and perhaps consult with stephenconnolly to see if this ever came up for Literate and how it was handled. I suspect the encoding in MultiBranchProject.getRootDirFor is relevant, but using a / inside an Item.getName is invalid generally (regardless of disk storage location), as that breaks the semantics of Item.getFullName and much else besides.

          magnayn added a comment - - edited

          Correction - fix did work, but I had to re-create the project. I'll see if it works (I get other oddities with projects with %2F in them, like maven fails in really weird places!)

          It occurred to me that maybe the correct place to fix was in Branch (something like branch.getSafeName() or similar) but I was unsure of the implications of the project name != branch name

          magnayn added a comment - - edited Correction - fix did work, but I had to re-create the project. I'll see if it works (I get other oddities with projects with %2F in them, like maven fails in really weird places!) It occurred to me that maybe the correct place to fix was in Branch (something like branch.getSafeName() or similar) but I was unsure of the implications of the project name != branch name

          Jesse Glick added a comment -

          maven fails in really weird places

          Probably failing to use the correct APIs to encode filenames as file-protocol URLs.

          I was unsure of the implications of the project name != branch name

          Will break the current workarounds for JENKINS-30252 and JENKINS-30595.

          Jesse Glick added a comment - maven fails in really weird places Probably failing to use the correct APIs to encode filenames as file -protocol URLs. I was unsure of the implications of the project name != branch name Will break the current workarounds for JENKINS-30252 and JENKINS-30595 .
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-30252 [ JENKINS-30252 ]
          Jesse Glick made changes -
          Link New: This issue depends on JENKINS-30595 [ JENKINS-30595 ]

          Jesse Glick added a comment -

          FTR I talked with stephenconnolly who said that he was not positive this was ever properly fixed in branch-api + literate. MultiBranchProject.getItem path-decodes the Item.name, allowing Item.fullName etc. to be meaningful, though it has a hack to deal with browsers which double-decode paths or something like that. (Meaning a functional test may not suffice: also need an acceptance test verifying that a real browser + servlet container can deal with the resulting mess!) Given that the Item.name is encoded, I am not sure why getRootDirFor redundantly encodes it; that may have been the source of your problem after restart. Note also calls to Util.rawEncode from LiterateBranchProject.getRootDir and LiterateEnvironmentBuild.getShortUrl. Also CC vlatombe.

          Jesse Glick added a comment - FTR I talked with stephenconnolly who said that he was not positive this was ever properly fixed in branch-api + literate . MultiBranchProject.getItem path-decodes the Item.name , allowing Item.fullName etc. to be meaningful, though it has a hack to deal with browsers which double-decode paths or something like that. (Meaning a functional test may not suffice: also need an acceptance test verifying that a real browser + servlet container can deal with the resulting mess!) Given that the Item.name is encoded, I am not sure why getRootDirFor redundantly encodes it; that may have been the source of your problem after restart. Note also calls to Util.rawEncode from LiterateBranchProject.getRootDir and LiterateEnvironmentBuild.getShortUrl . Also CC vlatombe .

          I don't remember such issues when using literate. so I think it handles it properly.

          Vincent Latombe added a comment - I don't remember such issues when using literate. so I think it handles it properly.

            jglick Jesse Glick
            magnayn magnayn
            Votes:
            14 Vote for this issue
            Watchers:
            47 Start watching this issue

              Created:
              Updated:
              Resolved: