Limit pod name to 63 characters, and shorten randomly generated string

[austinmoore-]

This PR has two small changes. Hope that it's alright that they're both in one PR. They're closely related.

The first fixes a bug where the plugin fails to use a pod if the pod's name is over 63 characters. I believe this is due to the fact that the JNLP container has a max hostname of 64 bytes (including the null terminator).

$ getconf HOST_NAME_MAX
64

As as a result, when workspace.child(HOSTNAME_FILE).readToString() is executed, it returns the first 63 characters of the pod name, which causes the plugin to look for the wrong pod.

The second change makes the random string appended to the end of the pod name more like Kubernetes' string generation. With this PR, only 5 characters are appended (or replaced if it exceeds the max length) to the end of the string.

[iocanel]

Thanks!

[austinmoore-]

@iocanel: Hey, sorry you're seeing problems with the PR. I'm happy to help fix these issues. I haven't had time to dive into code looking for you've said yet but wanted to get some clarification from things off the top of my head.

Two builds using podTemplates with the same name can get in each other way

I frequently launch jobs with the same name, but a different label. Also, if left unspecified the name "kubernetes" is chosen by default. As long as the label is unique it works. In what ways are you seeing the names conflict?

Also, what specific part of the commit are you thinking of reverting? Some context might help me understand these problems.

Thanks!

[iocanel]

No worries. It was a step to the right direction, with just some minor details that needed to be addressed.

Instantiating the template is usually done via node that uses a label, so no issues there. But when we are nesting podTemplates or use the inheritFrom that is done by name. And here's where possible issues may spawn. Also for the duration of the podTemplate scope, the podTemplate is added to the Jenkins configuration (as if it was done by hand) and I think that there we could also have issues with name conflicts (not 100% sure about the last part).

Anyway, I pushed a fix into the master which I think resolves the issue: bf245fe