Autoconfigure cloud if kubernetes url is not set

[carlossg]

Do it explicitly because kubernetes-client will change behavior

Autoconfigure the kubernetes client for tests
Use the currently enabled context

[marvinthepa]

Looks like a really useful change.

I am a bit worried that someone will just update the client dependency and therefore introduce a breaking change, though.

[marvinthepa]

Not needed - remove?

[marvinthepa]

I guess that comment was changed by an automated IDE refactoring.
What was that comment for in the first place? Can we remove it?

[carlossg]

no, it's just that now the cloud is the default kubernetes one

[marvinthepa]

I have to admit that I don't fully understand this comment.

I guess it means that by 2.4.x, this

new ConfigBuilder().withMasterUrl(serviceAddress)

Will behave differently, i.e. if we move the dependency to 2.4.x we will either introduce a breaking change, or we will have to change that line again?

[carlossg]

it comes from https://github.com/fabric8io/kubernetes-client/blob/master/kubernetes-client/src/main/java/io/fabric8/kubernetes/client/Config.java#L161

  //In future releases (2.4.x) the public constructor will be empty.
  //The current functionality will be provided by autoConfigure().
  //This is a necessary change to allow us distinguish between auto configured values and builder values.

[marvinthepa]

But this will still cause a breaking change if somebody changes the client library to 2.4 and doesn't update this code here, right?

• before 2.4.x, providing a master url means: do autoconfigure for everything but the master url
• after 2.4.x, providing a master url will mean "do not autoconfigure at all".

Is that intended?

[carlossg]

yes, it may be a breaking change to document. Better than the current behavior because your jenkins settings may be ignored
btw client is in 2.6.x and code still there

[marvinthepa]

Better than the current behavior because your jenkins settings may be ignored

Right, I remember we had that problem as well.

The only remaining downside that remains is that as of now, you can't have autoconfigure AND overwrite the kubernetes URL, like it used to work.

One solution for this would be to add a checkbox for autoconfigure to make it explicit...

[marvinthepa]

I guess you should remove the client-side validation for serverUrl:

kubernetes-plugin/src/main/java/org/csanchez/jenkins/plugins/kubernetes/KubernetesCloud.java

Lines 475 to 476 in 40d452f

	if (StringUtils.isBlank(serverUrl))
	return FormValidation.error("URL is required");

[marvinthepa]

I think this is good for merge except for missing documentation of the breaking change and that leaving the URL empty means "autoconfigure", i.e. in README.md and and in help-serverUrl.html.

[vamsi248]

@carlossg one quick question please..
we can use kubernetes-plugin for the free style job where i want to run my jenkins jobs in the kubernetes as making my pod as slave..
is it possible because i nevere see that no one is using this for free style job.. many are saying only pipeline.. if yes
i saw the option in free-style job that select job to run in environment
in that i can mention as groovy script my pod template??

2. i have created my own image by putting From jenkins/jnlp-slave i builed my own dockerfile making jenkin/jnlp-slave as base image.. then it should work right but still i am getting pending jnlp-slave-56gv4 is offline job is not able to pick that container and run.. please can give some idea?

[carlossg]

@vamsi248 you were told that questions must be asked in jenkins-user mailing list. I will not answer questions in the issue tracker no matter how many comments you leave

[vamsi248]

Sry @carlosg . I send email. in that they will send reply as email only..