feat: Allow the use of third party images to build dependencies #245
Conversation
This file contains 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
antonbabenko
changed the title
antonbabenko
pushed a commit
that referenced
this pull request
Jan 10, 2022
## [2.31.0](v2.30.0...v2.31.0) (2022-01-10) ### Features * Allow the use of third party images to build dependencies ([#245](#245)) ([0a9793e](0a9793e))
|
This PR is included in version 2.31.0 🎉 |
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Description
Allow the use of third party images to build dependencies other that
lambciimages.Motivation and Context
The current implementation requires docker images that have a worker pointing to
/var/task, since it forces the mount point to that location. It prevents the user to user an official image or any other image that does has the working directory in/var/task.If you try to create a lambda for example, using
build_in_docker = trueit will fail because the workdir is empty. And if you try to usepip_requirementsto install the requirements, it will throw an error saying it couldn't findrequirements.txt- because the workdir is not the same as the mount point.With this change we set the workdir to
/var/taskin thedocker runcommand, so no matter which image you use, the mount point and the workdir will be the same.We've been using this change in our company and it works with the the default image and official python images.
It could be a better solution to also allow the user to specify a custom workdir. But this is an easier and safe solution for now.
Breaking Changes
There's no breaking changes. This
How Has This Been Tested?
examples/*projectsI've tested the
container-imageandbuild-packageexamples. We also have been using this code to deploy production code in our company. Using both the default images as well as official images.