-
Notifications
You must be signed in to change notification settings - Fork 2
Target a single Python runtime #35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Target a single Python runtime #35
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This pull request simplifies the Lambda's build configuration to target only a single Python runtime instead of multiple runtimes. The change removes complexity by eliminating the need to manage artifacts for multiple Python versions and updates the tooling to work with a unified approach.
Key changes include:
- Consolidation of Python dependency management to a single configuration
- Replacement of the old version bumping script with an enhanced version
- Update of CI/CD workflows to build for a single Python runtime
Reviewed Changes
Copilot reviewed 23 out of 27 changed files in this pull request and generated 5 comments.
Show a summary per file
File | Description |
---|---|
src/version.txt | Updated version format from Python variable syntax to plain version string |
src/py3.7/Pipfile, src/py3.8/Pipfile | Removed Python version-specific dependency files |
build/Pipfile | Added comment clarifying Python version requirement alignment with Dockerfile |
setup-env | Added comprehensive Python version validation function |
bump-version | New enhanced version bumping script replacing the old one |
bump_version.sh | Removed old version bumping script |
Dockerfile | Simplified to use hardcoded Python 3.9 runtime instead of build arguments |
docker-compose.yml | Updated paths and quote style consistency |
.github/workflows/build.yml | Removed matrix strategy for multiple Python versions |
Various config files | Updated tooling versions and configuration improvements |
I don't plan on addressing any of Copilot's feedback in this pull request. I will open issues referencing the feedback items in cisagov/skeleton-generic once I've verified that they aren't hallucinations and are worth implementing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic!
Instead of building for multiple Lambda runtimes it makes sense to just build targeting a single runtime. When deployed the infrastructure will just need to use the same runtime as supported by the Lambda configuration. Thus we drop support for all but the latest runtime that is specified in the configuration.
Store it in the build/ subdirectory along with the `pipenv` files.
Now that we only build for a single runtime version we can simplify the `build` job's functionality.
The need for this environment variable was removed in #3 but removing the creation of it was missed.
Now that there is only a single dependency configuration we need to update the README's directions for updating Python dependencies.
Add a comment to `build/Pipfile` and another to the Dockerfile that each mention keeping the Python versions specified in sync.
Update the Python dependencies installed for the Lambda by running `pipenv lock` in the `build/` directory.
d59bec0
to
522e0ea
Compare
🗣 Description
This pull request changes and simplifies the Lambda's build configuration to only target a single AWS Lambda Python runtime.
Note
This pull request is built on top of #34. You can find the diff of just these branches here.
💭 Motivation and context
After some thought I decided it doesn't make much sense to target multiple Python runtimes. You already needed to configure the Lambda to use a matching runtime for the artifact you used and there's no reason to use a specific runtime over the others when artifacts were being produced for multiple runtimes. Thus we can simplify the build configuration and make it easier to leverage features in newer Python versions without worry.
🧪 Testing
Automated tests pass.
✅ Pre-approval checklist
bump_version
script if this repository is versioned and the changes in this PR warrant a version bump.✅ Pre-merge checklist
✅ Post-merge checklist