-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
-
0.2.1
I created a username/password credentials with the following command:
aws secretsmanager create-secret --name 'DB_USER_XXXXX' --secret-string 'zzzzzz' --tags 'Key=jenkins:credentials:username,Value=uuuuu' --description 'dddddddd'
although this worked and the credentials also show up in jenkins, the credentials have the wrong type icon shown in the credentials list screen:
all four credentials shown in the above screenshot should have the same icon in the first position of each line - all should be of type "UserName with Password". Currently the ones from AWS Provider show a different icon with the tool tip "AWS Secrets Manager secret" (which in fact is the icon for "Secret text"). This is very irritating for a user.
- relates to
-
JENKINS-60766 Credential icon names should be extracted as string constants
-
- Open
-
- links to
[JENKINS-60692] credential type icon not correctly reflected
Not to worry, I've since run the test and the icons are still all pegged to the one used for secret text.
That icon is actually the default icon if the custom credentials descriptor does not implement the method
public String getIconClassName()
The most obvious route to fix this is to copy and paste what the Jenkins default credential implementations return in their descriptors. E.g. "icon-credentials-userpass" for UsernamePasswordCredentialsImpl.
The problem is that I can't find the source of the icon class names they return: I presume a PNG with a matching name exists in some other part of the Jenkins codebase, but didn't find it. So while we could copy-paste the class names into this provider, we would get no warning if the names ever changed, or if we made a typo.
Chris Kilding
added a comment - - edited Not to worry, I've since run the test and the icons are still all pegged to the one used for secret text.
That icon is actually the default icon if the custom credentials descriptor does not implement the method
public String getIconClassName()
The most obvious route to fix this is to copy and paste what the Jenkins default credential implementations return in their descriptors. E.g. "icon-credentials-userpass" for UsernamePasswordCredentialsImpl.
The problem is that I can't find the source of the icon class names they return: I presume a PNG with a matching name exists in some other part of the Jenkins codebase, but didn't find it. So while we could copy-paste the class names into this provider, we would get no warning if the names ever changed, or if we made a typo. Chris Kilding
added a comment - I have requested that the icon names be made available as string constants in the credentials-plugin: JENKINS-60766
Chris Kilding
added a comment - I have requested that the icon names be made available as string constants in the credentials-plugin: JENKINS-60766 Chris Kilding
added a comment - Started work in GitHub PR #19 Chris Kilding
added a comment - Progress on JENKINS-60766 will take some time, so in the meantime the best option was to use the icon class names (and therefore leverage the icons provided by the upstream credentials jars), and to add conformance tests that will fail if the upstream jars ever change their icon class names.
Chris Kilding
added a comment - Progress on JENKINS-60766 will take some time, so in the meantime the best option was to use the icon class names (and therefore leverage the icons provided by the upstream credentials jars), and to add conformance tests that will fail if the upstream jars ever change their icon class names. Chris Kilding
added a comment - This fix will be included in the next plugin release. 
I'm intending to remove the multi-type credential object in PR #10, replacing it with different credential type classes that each implement just one credentials interface.
On initial inspection this seems to be fixing a lot of cosmetic problems like the formatting of names, bringing them in line with how credentials usually appear in the UI.
If you're interested and have the time, I encourage you to check out the git-plugin-username-password-bug branch, test it locally, and see if it is fixing the icon problem as well?