Closed dev-dsp closed 5 years ago
Other related question is regarding secretBytes format. As I understand, it should be "{" + base64(file_contents) + "}"
?
I've just tried local build scripts with the same configuration. They build and run Docker image and CASC takes secrets from Vault. However, nothing changed and I get same stack trace.
Could you pass the full stack trace? Clearly, incomplete stack traces is no good.
could you try
- file:
id: cert_devopsjenkinsgke
fileName: k8s.crt
description: "kubernetes cert"
secretBytes: ${cert_devopsjenkinsgke_b64:-Tk9UX0FfU0VDUkVU}
scope: GLOBAL
Tk9UX0FfU0VDUkVU
base64 of NOT_A_SECRET
Sure @casz, here is full startup log: https://pastebin.com/FxN6vAMR
Read the stack trace is my pro tip:
Caused by: java.lang.NullPointerException
at org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl.<init>(FileCredentialsImpl.java:157)
~What version of plain credentials plugin are you using?~ In the description :man_facepalming:
As listed above, it is 1.5
I've tried your variant, but nothing changed:
INFO: Setting class org.jenkinsci.plugins.plaincredentials.impl.FileCredentialsImpl.secretBytes = ${cert_devopsjenkinsgke_b64:-Tk9UX0FfU0VDUkVU}
May 17, 2019 11:19:24 AM jenkins.InitReactorRunner$1 onTaskFailed
SEVERE: Failed ConfigurationAsCode.init
java.lang.Error: java.lang.reflect.InvocationTargetException
Oh I see it now, should be fileName, not filename, let me verify
Yep, now it works like a charm. I've read this line before creating issue here, but then I didn't find anything strange there :)
@casz is it possible to implement case-insensitive setters or field existence verification on CASC side?
We could write some complex logic however since Java allows this case:
public static void test(String fileName, String filename) {
System.out.println("Hello World: " + fileName + " " + filename);
}
I see no reason to maintain logic that checks if parameters with case insensitivity and whether one or more parameters conflict with the naming.
Since someone can do this
public static void test(String fileName, String filename, String FILENAME, String fiLENAME, String fileNAME) {
// CRY
}
Ok, case-insensitivity may be not a good choice here. I just would like CASC to be more clear with such errors, if it is possible. Of course, it is just misconfiguration and not related to CASC itself, but such failures may require more time for investigation. Anyway, thanks for your quick help!
We could properly do something better like returning the expected parameters
FYI might be helpful to know that JCasC is getting native support for variable expansion with base64 and file read. See #1408
CWP config sample (there are lots of plugins there, all of them have latest version):
CASC:
I am using K8S secrets to provide credentials to CASC. It works fine for any field (mentioned some of them in config) except of the file credentials' secretBytes. Here is what I get in Jenkins startup logs:
So it is just not replaced for some reason. File representing K8S secret exists in container:
Spent some time investigating it, but with no luck. Could someone help me with that?