Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## v2 #200 +/- ##
============================================
+ Coverage 91.83% 94.42% +2.58%
- Complexity 97 108 +11
============================================
Files 6 7 +1
Lines 245 269 +24
Branches 26 29 +3
============================================
+ Hits 225 254 +29
+ Misses 18 12 -6
- Partials 2 3 +1 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
Did we consider alternatives, I see the Spring framework does it like this. https://github.com/spring-projects/spring-framework/blob/ce00aac748c194e82704f8069287527f524dcea4/spring-core/src/main/java/org/springframework/core/SpringVersion.java#L45-L64 |
| public static final String USER_AGENT_PREFIX = "AwsSecretCache/"; | ||
|
|
||
| /** Name of the filtered classpath resource holding the version. */ | ||
| static final String VERSION_RESOURCE = "version.properties"; |
There was a problem hiding this comment.
Is there any risk of name collision?
| * @return the resolved version, or {@link #UNKNOWN_VERSION}. | ||
| */ | ||
| private static String resolveVersion() { | ||
| return readVersion(VersionInfo.class.getResourceAsStream(VERSION_RESOURCE)); |
There was a problem hiding this comment.
Have we tested that this indeed picks up the library's version number and not the top level maven package's version number?
Ex: package my-custom-app version 1.0.0 takes a dependency on aws-secretsmanager-caching-java:2.1.0
| <groupId>com.amazonaws.secretsmanager</groupId> | ||
| <artifactId>aws-secretsmanager-caching-java</artifactId> | ||
| <version>2.2.0</version> | ||
| <version>x.y.z</version> |
There was a problem hiding this comment.
Not saying you have to do this but as an alternative we could have a github action whose job is to fetch the latest version number from maven and open a PR to update the readme.
3 participants
Description
Why is this change being made?
pom.xml(2.2.0) and a hardcoded constant inVersionInfo(2.1.0). They had already drifted, so the SDK UserAgent header reported a stale version (AwsSecretCache/2.1.0), causing version misreporting in Secrets Manager service logs.USER_AGENT_SUFFIXon theSecretsManagerClientBuilder, discarding the upstream caller's UserAgent instead of preserving it.What is changing?
pom.xmlis now the single source of truth for the version. A Maven-filteredversion.propertiesresource (version=${project.version}) is read at runtime byVersionInfo, with a safeunknownfallback that never throws.<caller-suffix> AwsSecretCache/<version>.README.mdinstall snippet no longer hardcodes a version, it points to Maven Central.Related Links
Testing
How was this tested?
mvn clean test: BUILD SUCCESS, 46 tests, 0 failures;When testing locally, provide testing artifact(s):
Tests run: 46, Failures: 0, Errors: 0, Skipped: 0Reviewee Checklist
Update the checklist after submitting the PR
If not, why:
If not, why:
If not, why:
If not, why:
If not, why:
If not, why:
If not, why:
If not, why:
Reviewer Checklist
All reviewers please ensure the following are true before reviewing:
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.