-
Notifications
You must be signed in to change notification settings - Fork 113
packaging plugin #254
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
packaging plugin #254
Conversation
9866b0b
to
4d09892
Compare
27dece5
to
c75825c
Compare
cc @abertelrud - this requires escaping the sandbox because of docker. would appreciate your feedback on the direction here |
c5963ad
to
907da4e
Compare
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.
Great start. Love to see this arriving! A couple of quick thoughts.
cd04fc7
to
a882987
Compare
eb9923a
to
ab8c681
Compare
@fabianfett I think this is ready to merge as iteration 1. next iteration we can explore how to integrate ziplib |
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.
As part of my review, I tried to run it in the EchoHandler... However I got the following output:
➜ Echo git:(feature/packaging-plugin) ✗ swift package archive
-------------------------------------------------------------------------
building "echo" in docker
-------------------------------------------------------------------------
error: processFailed(126)
I think we should at least print the processes output, in the error case. This error is undebugable for me.
fixed |
Interesting, just pulled the newest version and tried to rerun: ➜ Echo git:(feature/packaging-plugin) ✗ swift package archive
-------------------------------------------------------------------------
building "echo" in docker
-------------------------------------------------------------------------
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create": dial unix /var/run/docker.sock: connect: operation not permitted.
See 'docker run --help'.
error: /usr/local/bin/docker run --rm -v /Users/fabian/Developer/swift-server/swift-aws-lambda-runtime/Examples/Echo:/workspace -w /workspace swift:amazonlinux2 bash -cl swift build -c release --show-bin-path failed with code 126
➜ Echo git:(feature/packaging-plugin) ✗ docker container create swift:5.6-focal
98decac8da409010202c45428d18e06f9761f1b130c649afc14778b6d74aa72b
➜ Echo git:(feature/packaging-plugin) ✗ Apparently from the plugin I don't have enough rights to create a new container, but just from the shell I have. Do you have any idea what this might be related to @tomerd. |
I think the reason’s here: Wonder if we can surpass the restriction. |
right, this is because talking to docker is networking which is denied by the sandbox. for local testing I have been using the plugin without the sandbox, e.g: @abertelrud would be interesting to see if we can poke a hole for docker in the sandbox, or be able to express it as a plugin requirement that the user can approve |
motivation: add an easy wasy for lambda users to package their lambda and upload it to AWS changes: * add SwiftPM plugin with the verb "archive" * use docker to build and package the lambda(s)
Co-authored-by: Yim Lee <[email protected]>
da7f95f
to
0ddf8fb
Compare
89a4ba9
to
ebd3f27
Compare
ebd3f27
to
b2842ba
Compare
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.
Looks good and works for me!
// rename artifact to "bootstrap" | ||
let relocatedArtifactPath = workingDirectory.appending(artifactPath.lastComponent) | ||
let symbolicLinkPath = workingDirectory.appending("bootstrap") | ||
try FileManager.default.copyItem(atPath: artifactPath.string, toPath: relocatedArtifactPath.string) | ||
try FileManager.default.createSymbolicLink(atPath: symbolicLinkPath.string, withDestinationPath: relocatedArtifactPath.lastComponent) |
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.
Code comment does not match behavior. I wonder if just renaming the executable (like the code comment says), is actually the better alternative here. What do we gain through the symlink indirection?
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.
I cant remember tbh, I think I tired it and it caused some issue, will need to try again. in either case its the same end result
Co-authored-by: Fabian Fett <[email protected]>
e08db84
to
936eb8f
Compare
6664486
to
03ff066
Compare
motivation: an easy way to archive lambda for uploading to AWS
changes: