fix(ci): add missing dollar signs in SSM parameter path variables#7695
Merged
leandrodamascena merged 1 commit intoaws-powertools:developfrom Nov 15, 2025
Merged
Conversation
Fixes aws-powertools#7689 When adding Python 3.14 support in commit a58cef7, the SSM parameter creation workflow was refactored to use environment variables instead of GitHub Actions expressions. However, 10 out of 12 lines were missing the dollar sign ($) prefix on the PACKAGE_VERSION variable. This caused version 3.23.0 SSM parameters to be created with the literal string 'PACKAGE_VERSION' in the path instead of the actual version number. For example, instead of: /aws/service/powertools/python/x86_64/python3.13/3.23.0 The workflow created: /aws/service/powertools/python/x86_64/python3.13/PACKAGE_VERSION This affected: - ARM64: Python 3.11, 3.12, 3.13, 3.14 (4 versions) - x86_64: Python 3.9, 3.10, 3.11, 3.12, 3.13, 3.14 (6 versions) Only ARM64 Python 3.9 and 3.10 worked correctly. Verified by checking AWS SSM - the incorrectly named parameters exist and the correctly named version parameters are missing.
boring-cyborg
bot
added
the
github-actions
pull-request-size
bot
added
the
size/S
|
leandrodamascena
approved these changes
Nov 15, 2025
Contributor
|
Hey @Iamrodos thanks for sending this PR! I was taking a look on this. I merged this and run the parameter workflow again. |
Contributor
Author
|
@leandrodamascena thanks for the merge and running the update. FYI I found this because dependabot trigger because of the PyPi update. I use the SSM in my CloudFormation to specify the specific layer. However I have a lint check on my CF that verifies that the layer actually exists, due to the "potential 48 hour delay" in it being available. After waiting quite a while, I figured there was something wrong and started to investigate the missing parameter. Love PowerTools! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue number: closes #7689
Summary
Changes
Fixed a typo in
.github/workflows/update_ssm.ymlwhere 10 out of 12 SSM parameter path variables were missing the$prefix onPACKAGE_VERSION.When adding Python 3.14 support in commit a58cef7, the workflow was refactored to use shell environment variables instead of GitHub Actions expressions. However, during this refactor, the
$symbol was accidentally omitted on most lines, causing the literal string "PACKAGE_VERSION" to be used in parameter paths instead of the actual semantic version (e.g., "3.23.0").Lines fixed:
User experience
Before:
Users looking for version-specific SSM parameters for Python 3.11-3.14 (ARM64) and all x86_64 versions cannot find them for release 3.23.0.
For example, querying
aws ssm get-parameter --name "/aws/service/powertools/python/x86_64/python3.13/3.23.0" --region us-east-1returnsParameterNotFoundInstead, incorrectly named parameters exist at
/aws/service/powertools/python/x86_64/python3.13/PACKAGE_VERSIONAfter:
Future releases will create correctly named SSM parameters that users can reference in their CloudFormation templates and infrastructure code.
Note:
This fix prevents the issue in future releases. The v3.23.0 parameters will need to be recreated separately by re-running the update_ssm workflow for that version.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.