There are two serious problems with the current implementation of github-organizational plugin and both of them are related to branch names.

Git flow uses branch names like `feature/xxx` or `release/1.0.0` which are translated by Jenkins into into `%2F` by using HTTP escaping. Still, this causes breaks python virtualenv seriously because if the build job is trying to create a virtual environment inside a path that contains percent, it will create a virtualenvironment than works in 50/50, based on luck (we tested with more than 10 top Python packages and at least half of them fail to build or install due to the presence of the percent sign inside the python PATH).

Second problem is the final length of the PATH becomes too long for many build jobs and they start to fail. We found references online that only lengths of branch names up to 16-20 characters are supposed to be safe, others will probably break builds.

To understand the extent of this issue have a look at this PATH:

/var/lib/jenkins/jobs/apache-org/jobs/apache-project-aaa-api/branches/feature%2Fimplement-a-cool-error-page/workspace

Some would argue that the team can decide to introduce a policy for branch names, one that would not use the slash and that would require limited length. Sadly, slash is the default separator used by all the git GUI tools for grouping branches into directories (collapsing). Also, there is no way to enforce a naming convention and branch renaming is a very complex problem, is not just a one click away.

Due to this, I think that it would be the best to deal with these issues inside the github organization plugin. Some of my colleagues proposed the use of a sha1 sum on branch name, but I am not a big fun of this because is very cryptic – if you do an ls in the branches directory, you will not be able to figure out which one is safe to remove or not.