Secrets username, password (like image source secrets) require! Annotations. Else: NPE #293
Comments
|
@jomeier Thank you for opening up this issue. Has this issue surfaced only after updating the jenkins sync plugin ? cc @gabemontero |
|
@waveywaves |
|
Hmm ... the second NPE's line number does not line up with the latest version of the code, which would be v1.0.34. That line, Now, the prior version of that file, before my fix, which would have been v1.0.33, does point to the incorrect assumption that the annotation would be non-null. See Now, java stack traces certainly have not been full proof over the years. But it being off by one, say up one, would imply the metadata was null ... that should definitely not be the case. See Down one, at An NPE can't occur from that @jomeier .... are you SURE you were at v1.0.34 when you saw the second NPE? What was the SHA of the openshift/jenkins docker image you pulled ? Certainly the intent of v1.0.34 was to correct the assumption that the annotation map would be there. The first NPE, in isolation, is unrelated to secret annotations altogether. However, maybe the failure from the credential NPEs corrupted sync plugin data structures and caused the first one. They occurred simultaenously, even if they showed up in the log in the order they did. Also, the second was on a BC event, so I could see that correlation. Let's wait on @jomeier 's response to the image sha / confirmation on the plugin version, and we'll go from there. |
|
@gabemontero Now it seems to work fine. Thank you for assisting me! Greetz, Josef |
|
ok good news @jomeier thanks for the update |
|
@gabemontero With the annotation which changes the name I dont get this. There still seems to be a problem.... |
|
An NPE at that line actually speaks to the secret text, not the secret name that is driven by the annotation. I suspect that there is another variable in play, but can't say for sure, in addition to what you observed. See An NPE in the String contstructor means Either does not make much sense given the null checks preceding the line, and what I see in the Base64.decode logic.
Could you possibly provide yaml for
If you need to obfuscate any sensitive data, or course please do. Otherwise, other than putting a try catch around that line for debug, not sure what else I'm would do here. thanks |
|
Hello everyone, I just ran into the same (or a similar, but maybe related) issue and looked into the From my understanding, the method The secret I used to reproduce the backtrace from @jomeier looks like this: apiVersion: v1
data:
SECRET_A: bm9wZS4=
SECRET_B: bm9wZS4=
SECRET_C: bm9wZS4=
SECRET_D: bm9wZS4=
kind: Secret
metadata:
labels:
credential.sync.jenkins.openshift.io: "true"
name: omgsosecret
namespace: my-namespace
type: Opaqueand here's the backtrace I got for completeness: Hope this helps a bit ^^ |
|
@waveywaves - given you being the genesis of the new annotation, how about you see if you can leverage @nilsding 's reproducer secret to generate the same NPE with the latest version of sync plugin. based on the results, we can go from there and see if you can submit a fix. as a reminder, the end to end process is at https://github.com/openshift/jenkins/blob/master/CONTRIBUTING_TO_OPENSHIFT_JENKINS_IMAGE_AND_PLUGINS.md @pradeepto @sthaha @pweil- fyi |
|
@nilsding I was able to reproduce this in v1.0.34 where the annotation feature for changing the secret name has been implemented as well as in v1.0.32 where it wasn't. To ensure that you have a working secret in Jenkins you have to create the openshift secret in the following way. 1> Create a file with you secrets. 2> Create an Openshift Secret using the following command 3> Label the secret Your secret should be usable in your jenkins instance. @gabemontero This doesn't seem to be an issue with the new annotation, but with how the secrets are parsed as @nilsding mentioned. Will look into it further. |
|
bump @waveywaves .... how far along are you with addressing the encoding issue (since the annotation has been proven to be a unrelated thing along the same code path) ? |
|
v1.0.36 of the sync plugin has bee initiated at the jenkins update center it contains the fix from @waveywaves via #304 @nilsding @jomeier if either of you can try v1.0.36 in the near term and let us know what you see that will be great we are still weighing when to update the openshift/jenkins images given our proximity to 4.0/4.1 GA |
Hi,
jenkins-sync-plugin 1.0.34 require this annotation to be set:
Without that I get this NPE:
The text was updated successfully, but these errors were encountered: