Hi Ethan, could you clarify the last sentence? Not quite sure what it means, but there might be something worth investigating in it.

You are correct that it’s a breaking change. I kept the previous auto-detection strategy going as long as I could, but unfortunately the multi-type credential object this entailed broke fundamental assumptions of important credential consumers, like the Git plugin. So it was a tough call but I had to change it. I’ll add a doc notice as you suggest.

The only in-band mechanism Jenkins currently provides to announce a breaking change is the plugin version number. However per the Semantic Versioning standard, this only really works if you are post version 1 (when you can indicate a breaking change with a major version increment). Therefore I intend to finish the last 2 or 3 minor changes I’m working on, sit on it for a while, then if all looks good release stable version 1.0.0.

Sure, just wanted you to be aware of what made me struggle for the past 24 hrs when I setup a new environment with the latest version of this plugin while my older environments had the previous version.

As far as my final statement, it seemed that after adding that jenkins:credentials:type=string tag into the secret within AWS Secrets Manager and it getting displayed in Jenkins, if I remove the tag, the entry still remains in Jenkins even after the 5 minute mark.  It will only disappear after I initiate a delete to remove the secret altogether, regardless of whether that tag was present or later removed.

Also, a strange thing I noticed previously, if I mark the secret as deleted but it is still recoverable, the secret is still seen in Jenkins. Not sure whether you've tested/coded for this.

Finally, any chance you can parameterize the 5 minute-check. Sometimes I'd like to have it be less (at least initially).

User-configurable cache duration has a ticket: JENKINS-57577. I'll note your interest there.

The soft deletion of secrets is problematic in Moto (the AWS mock I use) because it doesn't have an effective notion of time (at least, not the kind of time frames we have in integration test lifecycles). This makes testing soft deletion very awkward and there could be a mistake there. I'll investigate.

I've logged the soft-deleted secrets problem in JENKINS-61111

I've logged the problem with credentials sticking around after the jenkins:credentials:type tag is removed in JENKINS-61112

I've enabled Release Drafter on the repo, which will automatically write the changelog for each plugin release on the GitHub Releases page. This seems to be the best place to communicate changes in new versions, breaking or otherwise.