Upgrading to the lastest plugin (364.vf5d54b_3dc313) breaks any Org or pipeline that uses with Vault. #326
Comments
|
This issue also effected me |
|
Coming back to say downgrading fixed the issue |
|
I'm no java dev, but think f5d54b3 @bluesliverx Any thoughts? |
|
I also ran into this issue where the folder is visible, but the jobs it contains are not visible. Jobs still execute on their cadence or hooks, which is great but leaves users unable to edit jobs. Upgraded from 360.v0a_1c04cf807d to 363.va_f8c1627db_b_a, a 'compatible' plugin upgrade. Downgrading back to the previous version fixed the issue. |
|
It's been months and no fix. Does anyone have a workaround yet? We have several Jenkins instances, and it only happens on 1 instance. Would prefer not to maintain separate images or reconfigure all those jobs. |
|
Sorry for the long delay here. Not sure exactly what the issue is. Any chance we can get some logs from Jenkins itself or what the actual error is? |
|
@bluesliverx This was the error I was seeing. `THIS IS THE ERROR WHEN I CLICK ON THE OrganizationFolder 2024-02-26 20:05:50.473+0000 [id=92] WARNING h.i.i.InstallUncaughtExceptionHandler#handleException: Caught unhandled exception with ID 1794f616-c655-4f0c-9e9c-41eacde97d1d And from Jenkins console output I would see things like this
|
|
I created a new org on our Jenkins and didn't see any issues, I wonder if this is a problem with an existing org after the upgrade. Looking at the stack trace, it might have something to do with the owner being null, which sounds like the problem identified in #324 that was already fixed in release https://github.com/jenkinsci/hashicorp-vault-plugin/releases/tag/368.v48134f694db_f. Have you tried upgrading again to see if this is fixed? |
|
Thanks @bluesliverx I didn't have the nerve to try the upgrade again as I had way too many people screaming at me to get it back up from the last time. However, other people have come here recently looking for a solution so maybe they can say which version of the plugin they tried without success. @JaminenB @bordenit |
|
@bluesliverx @ScottWatsonWork The last one we installed in production environment that was having this issue is 367.v8a_1ee1cccf3a. I will try the 368... you referenced. That 368... version is already in our engineering environment. We have 6 Jenkins instances and only one production instance has this issue. I will try the 368... version during our next outage window. Thanks. |
|
The serialization compatibility mistake in #223 (changing the type of a serialized field from The fix for the issue was changing the relevant field to be Unfortunately, from some testing locally, it seems that in this particular case where the type was changed to a At this point I see no simple solution that does not require users to manually edit their folder's Note that in general, Jenkins is supposed to handle deserialization errors and mistakes like this a bit more gracefully. The desired behavior is just that the broken value gets skipped, but the overall object otherwise loads fine. In this case, the folder property with the credential should have been removed, but the folder itself should have loaded fine, which would have meant that everyone would have just needed to reconfigure their vault credentials. I am looking a bit more to try to understand what exactly went wrong in this case to see if anything can be improved in Jenkins core. |
|
@jglick reminded me that probably renaming the |
|
#336 should fix the issue. |
|
jenkinsci/jenkins#9653 experiments with some core changes that would have limited the impact of the mistake to simply removing the Vault-related property from the folder rather than corrupting the folder itself. |
|
It is still broken for me. In the jenkins logs I get: |
|
@dwnusbaum will your fix still mean we are stuck forever if we did downgrade in the past to get working again, or will it allow us to update with the changes you are recommending? Either way, that is pretty good detail, and thanks for looking into this. |
|
@dwnusbaum I confirmed that the fix worked for us. I was able to update with your changes and access all folders without issue. |
Jenkins and plugins versions report
Environment
What Operating System are you using (both controller, and any agents involved in the problem)?
I am using a kubernetes cluster to host my jenkins 2.401.1-LTS. No need to run an agent as the controller is the one that is having a problem.
Reproduction steps
Expected Results
Was expecting my jobs to work and be accessible after only updating the vault plugin.
Actual Results
Now if I click on the org or a repo with a pipeline that uses vault I get a stacktrace and cannot access that repo.
I uncovered this when I was trying to upgrade to 2.426.3. From trial and error I have narrowed down the problem to the upgrade to this plugin. So I am not sure if we have something strange in our Jenkinsfile or what but this plugin version is not happy with something.
Anything else?
I am not sure if this is expected or not but the section in my config.xml for my repo is pointing to version 3.60. I am wondering if that is why it is greyed out in the image I uploaded.
</com.datapipe.jenkins.vault.credentials.VaultAppRoleCredential> <com.datapipe.jenkins.vault.credentials.VaultAppRoleCredential plugin="[email protected]_1c04cf807d"> <id>vault_bot_sre</id> <description>https://vault.tools.copr/ui/vault/secrets?namespace=ssc%2Fcxai%2Fsre</description> <tokenExpiry> <time>1675197378315</time> <timezone>Etc/UTC</timezone> </tokenExpiry> <currentClientToken>not Important</currentClientToken> <namespace>ssc/cxai/sre</namespace> <secretId>not important</secretId> <roleId>roleID goes here </roleId> <path>approle</path> </com.datapipe.jenkins.vault.credentials.VaultAppRoleCredential>Are you interested in contributing a fix?
No response
The text was updated successfully, but these errors were encountered: