[JIRA] (JENKINS-58710) Classes with Same name and Different Packages are being triggered JCASC

andreilhicas@gmail.com (JIRA)

unread,

Jul 29, 2019, 12:11:03 PM7/29/19

to jenkinsc...@googlegroups.com

André Ilhicas Santos created an issue

Jenkins /

JENKINS-58710

Classes with Same name and Different Packages are being triggered JCASC

Issue Type:	Bug
Assignee:	Jie Shen
Components:	azure-credentials-plugin, configuration-as-code-plugin, windows-azure-storage-plugin
Created:	2019-07-29 16:10
Environment:	Jenkins version 2.187 (Docker - Alpine based) windows-azure-storage:1.1.0 azure-credentials:1.6.1 configuration-as-code:1.24 configuration-as-code-support:1.18
Priority:	Major
Reporter:	André Ilhicas Santos

When using Azure Credentials with CASC references to Azure Credentials ( plugin azure-credentials:1.6.1 ) get caught by a different package

Example for CASC confs

```

azure:
clientId: "${azure_clientId}"
clientSecret: "${azure_clientSecret}"
description: "Azure Credentials"
id: "X"
scope: GLOBAL
subscriptionId: "${azure_subscriptionId}"
azureEnvironmentName: "Azure"
```

This results in:

```
jenkins_1 | io.jenkins.plugins.casc.ConfiguratorException: Invalid configuration elements for type class com.microsoftopentechnologies.windowsazurestorage.helper.AzureCredentials : azureEnvironmentName,clientId,clientSecret,subscriptionId,tenant.
jenkins_1 | Available attributes : blobEndpointURL, description, id, scope, storageAccountName, storageKey
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.handleUnknown(BaseConfigurator.java:378)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:367)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:277)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.configure(DataBoundConfigurator.java:83)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$doConfigure$16668e2$1(HeteroDescribableConfigurator.java:278)
jenkins_1 | at io.vavr.CheckedFunction0.lambda$unchecked$52349c75$1(CheckedFunction0.java:201)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.doConfigure(HeteroDescribableConfigurator.java:278)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$null$2(HeteroDescribableConfigurator.java:86)
jenkins_1 | at io.vavr.control.Option.map(Option.java:373)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.lambda$configure$3(HeteroDescribableConfigurator.java:86)
jenkins_1 | at io.vavr.Tuple2.apply(Tuple2.java:239)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.configure(HeteroDescribableConfigurator.java:83)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.HeteroDescribableConfigurator.configure(HeteroDescribableConfigurator.java:55)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.tryConstructor(DataBoundConfigurator.java:153)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.instance(DataBoundConfigurator.java:77)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:268)
jenkins_1 | at io.jenkins.plugins.casc.impl.configurators.DataBoundConfigurator.check(DataBoundConfigurator.java:101)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:345)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.check(BaseConfigurator.java:288)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.configure(BaseConfigurator.java:353)
jenkins_1 | at io.jenkins.plugins.casc.BaseConfigurator.check(BaseConfigurator.java:288)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.lambda$checkWith$6(ConfigurationAsCode.java:684)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:646)
jenkins_1 | Caused: io.jenkins.plugins.casc.ConfiguratorException: credentials: error configuring 'credentials' with class com.cloudbees.plugins.credentials.casc.CredentialsRootConfigurator configurator
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.invokeWith(ConfigurationAsCode.java:652)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.checkWith(ConfigurationAsCode.java:684)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:668)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.configureWith(ConfigurationAsCode.java:567)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.configure(ConfigurationAsCode.java:280)
jenkins_1 | at io.jenkins.plugins.casc.ConfigurationAsCode.init(ConfigurationAsCode.java:272)
jenkins_1 | Caused: java.lang.reflect.InvocationTargetException
jenkins_1 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
jenkins_1 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
jenkins_1 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
jenkins_1 | at java.lang.reflect.Method.invoke(Method.java:498)
jenkins_1 | at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:104)
jenkins_1 | Caused: java.lang.Error
jenkins_1 | at hudson.init.TaskMethodFinder.invoke(TaskMethodFinder.java:110)
jenkins_1 | at hudson.init.TaskMethodFinder$TaskImpl.run(TaskMethodFinder.java:175)
jenkins_1 | at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:296)
jenkins_1 | at jenkins.model.Jenkins$5.runTask(Jenkins.java:1118)
jenkins_1 | at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:214)
jenkins_1 | at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
jenkins_1 | at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
jenkins_1 | at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
jenkins_1 | at java.lang.Thread.run(Thread.java:748)
```

The same is valid if we set *Azure Storage Credentials*

```

azureStorageAccount:
blobEndpointURL: "https://blob.core.windows.net/"
id: "X-Storage"
scope: GLOBAL
storageAccountName: "${azure_storageAccountName}"
storageKey: "${azure_storageKey}"
azure:
clientId: "${azure_clientId}"
clientSecret: "${azure_clientSecret}"
description: "Azure Credentials"
id: "X"
scope: GLOBAL
subscriptionId: "${azure_subscriptionId}"
azureEnvironmentName: "Azure"

```

The values for azureStorageAccount have been exported from CASC to check if setting it would not trigger this bug.

The above results in triggering twice the Same StackTrace as set above.

Notice the package used:
*com.microsoftopentechnologies.windowsazurestorage.helper.AzureCredentials*

It should in fact call the one below:
*com.microsoft.azure.util.AzureCredentials*

An issue was created at JCASC github: https://github.com/jenkinsci/configuration-as-code-plugin/issues/963

However, from comments in the issue referenced above, the problem lies on how both Azure-Credentials and windows-azure-storage reference the same class on different packages.

Add Comment

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

andreilhicas@gmail.com (JIRA)

unread,

Jul 29, 2019, 12:20:02 PM7/29/19

to jenkinsc...@googlegroups.com

André Ilhicas Santos updated an issue

Jenkins /

JENKINS-58710

Classes with Same name and Different Packages are being triggered JCASC

Change By:	André Ilhicas Santos

When using Azure Credentials with CASC references to Azure Credentials ( plugin azure-credentials:1.6.1 ) get caught by a different package

Example for CASC confs

```

-
{code:java}

azure:
clientId: "${azure_clientId}"
clientSecret: "${azure_clientSecret}"
description: "Azure Credentials"
id: "X"
scope: GLOBAL
subscriptionId: "${azure_subscriptionId}"

azureEnvironmentName: "Azure" {code}
```

This results in:

```
{code:java}

jenkins_1 | at java.lang.Thread.run(Thread.java:748) {code}

```

The same is valid if we set **Azure Storage Credentials**

```
- {code:java}

azureStorageAccount:
blobEndpointURL: "https://blob.core.windows.net/"
id: "X-Storage"
scope: GLOBAL
storageAccountName: "${azure_storageAccountName}"
storageKey: "${azure_storageKey}"

- azure:

clientId: "${azure_clientId}"
clientSecret: "${azure_clientSecret}"
description: "Azure Credentials"
id: "X"
scope: GLOBAL
subscriptionId: "${azure_subscriptionId}"

azureEnvironmentName: "Azure" {code}

```

The values for azureStorageAccount have been exported from CASC to check if setting it would not trigger this bug.

The above results in triggering twice the Same StackTrace as set above.

Notice the package used:

**com.microsoftopentechnologies.windowsazurestorage.helper.AzureCredentials**

It should in fact call the one below:

**com.microsoft.azure.util.AzureCredentials**

An issue was created at JCASC github: [https://github.com/jenkinsci/configuration-as-code-plugin/issues/963]

However, from comments in the issue referenced above, the problem lies on how both Azure-Credentials and windows-azure-storage reference the same class on different packages.

Add Comment

andreilhicas@gmail.com (JIRA)

unread,

Jul 29, 2019, 12:22:03 PM7/29/19

to jenkinsc...@googlegroups.com

{code:java}

- azureStorageAccount:

blobEndpointURL: "https://blob.core.windows.net/"
id: "X-Storage"
scope: GLOBAL
storageAccountName: "${azure_storageAccountName}"

storageKey: "${azure_storageKey}" azure:

clientId: "${azure_clientId}"
clientSecret: "${azure_clientSecret}"
description: "Azure Credentials"

- azure:

id: "X"
scope: GLOBAL
subscriptionId: "${azure_subscriptionId}"
azureEnvironmentName: "Azure" {code}
```

The values for azureStorageAccount have been exported from CASC to check if setting it would not trigger this bug.

The above results in triggering twice the Same StackTrace as set above.

Notice the package used:
**com.microsoftopentechnologies.windowsazurestorage.helper.AzureCredentials**

It should in fact call the one below:
**com.microsoft.azure.util.AzureCredentials**

An issue was created at JCASC github: [https://github.com/jenkinsci/configuration-as-code-plugin/issues/963]

However, from comments in the issue referenced above, the problem lies on how both Azure-Credentials and windows-azure-storage reference the same class on different packages.

Add Comment

andreilhicas@gmail.com (JIRA)

unread,

Jul 29, 2019, 12:23:02 PM7/29/19

to jenkinsc...@googlegroups.com

- azure :
   id: " ${azure_clientId} X "
    clientSecret    scope : GLOBAL
   subscriptionId: "${ azure_clientSecret azure_subscriptionId }"
    description    azureEnvironmentName : "Azure Credentials "
- azure
   clientId :
   id: " X ${azure_clientId} "
   scope    clientSecret : GLOBAL
   subscriptionId: "${ azure_subscriptionId azure_clientSecret }"
   azureEnvironmentName    description : "Azure Credentials " {code}

```

The values for azureStorageAccount have been exported from CASC to check if setting it would not trigger this bug.

The above results in triggering twice the Same StackTrace as set above.

Notice the package used:
**com.microsoftopentechnologies.windowsazurestorage.helper.AzureCredentials**

It should in fact call the one below:
**com.microsoft.azure.util.AzureCredentials**

An issue was created at JCASC github: [https://github.com/jenkinsci/configuration-as-code-plugin/issues/963]

However, from comments in the issue referenced above, the problem lies on how both Azure-Credentials and windows-azure-storage reference the same class on different packages.

Add Comment

jieshe@microsoft.com (JIRA)

unread,

Jul 30, 2019, 2:07:02 AM7/30/19

to jenkinsc...@googlegroups.com

Jie Shen commented on

JENKINS-58710

Re: Classes with Same name and Different Packages are being triggered JCASC

The naming conflicts in different plugins seem to cause this issue. I think CASC should somehow support isolate classes from different environments. But it may need big effort to achieve that. I will check if it is possible to change the class name to temporarily fix this. It may have some potential risk to do this since the class is a public one.