Minor When I try to create jobs like
- foo
- FOO
- Foo
- fOo
- ...
Jenkins will only allow me to create the first one. After that, it complains that a job of this name already exists. (It uses the case of the job, I just try to create)
[I'm mildly surprised, because this is Unix, where case matters]
The bad thing comes, when I try to download the job using
http://<jenkins>:<port>/view/Admin/view/All/job/FOO/config.xml
Here I can use whatever case for 'FOO' (e.g. all of the above) and each of the downloads succeed.
I would expect to only be able to download the job with the correct case. (Yielding an error in all other cases)
[JENKINS-37761] case in spelling of jobname doesn't matter on downloadign using wget
Job names are deliberately case insensitive:
https://github.com/jenkinsci/jenkins/blob/952c5e250ee961af5dddd879323dbb32e3fde41d/core/src/main/java/jenkins/model/Jenkins.java#L452
This has been in there forever. Since Jenkins is a cross-platform tool and creates directories on disk corresponding to job names, the lowest common denominator (case-insensitive file systems) needs to be considered.
Changing it would result in regressions for no real reason, so I'm resolving as Won't Fix.
| Resolution | New: Won't Fix [ 2 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
While this is ok for a case smashing but preserving FS (Windows), it is IMHO still bad for a case sensitive one (Unix).
If the GUI of Jenkins restricts me to the first case-variant I create, I would expect Jenkins to also only allow me to download the job under this name.
On Windows I would not get another name on the local FS, because all case variants are considered equal by the FS.
(And Jenkins also considers all case variants as equal for the sake of these FS; this is fine with me - having just case differences between two jobs would be really confusing.)
On Unix currently I can download 2^n case-variants, but still it is the same job. So for the sake of the case sensitive FS, only the spelling variant actually present in Jenkins should be downloadable. After all Jenkins decided to restrict to this one, so it should do this consistently.
(And this is the change between current behaviour and the one I would expect)
Did I just miss the point ? I'm still surprised by the behaviour. (And colleagues had been too....)
After all Jenkins decided to restrict to this one, so it should do this consistently.
The behavior is identical to what Windows file systems do, and internally consistent. It's case-insensitive ("does not care about letter case"), but case-preserving. Lookup of FOO, foo, and Foo succeeding and returning the same item is the corollary to not being able to create Foo and foo independently.
So what's the bug here? That Jenkins behaves consistently in treating job names case-insensitively?