The local testing instruction are missing from the hello world example.
The format of the payload is not intuitive or trivial to guess. We need
to make it explicit
When including resources in the package and packaging on Ubuntu,
`FileManager` throws a FilePermission error. The docker daemon runs as
root and files to be copied are owned by `root` while the archiver runs
as the current user (`ubuntu` on EC2 Ubuntu). The `FileManager` manages
to copy the files but throws an error after the copy. We suspect the
`FileManager` to perform some kind of operation after the copy and it
fails because of the `root` permission of the files.
See
https://github.com/swift-server/swift-aws-lambda-runtime/issues/449#issuecomment-2595978246
for a description of the problem.
This PR contains code to reproduce the problem, a very simple
workaround, and an integration test.
The workaround consists of
- trapping all errors
- verify if the error is the permission error (Code = 513)
- verify if the files have been copied or not
- if the two above conditions are met, ignore the error, otherwise
re-throw it
I would rather prefer a solution that solves the root cause rather than
just ignoring the error.
We're still investigating the root cause (see [this
thread](https://forums.swift.org/t/filemanager-copyitem-on-linux-fails-after-copying-the-files/77282)
on the Swift Forum and this issue on Swift Foundation
https://github.com/swiftlang/swift-foundation/issues/1125
Add an example of an APIGateway Lambda Authorizer
### Motivation:
Lambda Authorizers allow developers to write custom logic to validate
HTTP REST requests.
This example shows how to write a Lambda Authorizer in Swift and how to
configure an API Gateway to use a Lambda Authorizer.
This example use a SAM template to deploy the resources.
### Modifications:
- Add `Examples/APIGateway+LambdaAuthorizer` directory with the source
code, a `template.yaml`, and a `README` file.
- Add a reference to the new example in `Examples/README`
- Modify CI to build the new example
### Result:
There is a new example showing how to develop a Lambda authorizer in
Swift and how to attach it to an APIGateway with SAM
Add a note in the deployment guide to inform Linux user they must have
correct permissions to use docker on their system.
### Motivation:
Build instructions fail on a fresh Ubuntu installation. See this error
report.
https://github.com/swift-server/swift-aws-lambda-runtime/issues/449
### Modifications:
Add a note in the deployment guide that Linux user must add their user
in the `docker` group.
### Result:
Hopefully, Linux users will not experience error at first use of `swift
package archive`
Move `AWSLambdaRuntimeCore` as first package because this is where all
the doc lives. This will make `AWSLambdaRuntimeCore` the default on
Swift Package Index
As discussed with @0xTim
This PR
- adds a minimal example of deployment using SAM in the README
- adds a `Deployment.md` Swift Docc file to cover deployment with the
AWS console, CLI, SAM, and CDK. It mentions and contains a call to
contributions to further examples for third-party tools such as the
Serverless Framework, Terraform, or Pulumi.
This new example project show four testing strategies for Swift Lambda
function
- Unit testing the business logic (not specific to Swift Lambda)
- Integration testing the handler method
- Local invocation with the Swift Lambda Runtime
- Local invocation with SAM
**[IMPORTANT]**
To allow testing the handler, I had to change visibility of a method in
the Runtime project. This method is clearly marked for testing only, so
it should not be a problem. Happy to read feedback and discuss however.
This adds a test in the `integration_test.yml` workflow to verify that
`libFoundation.so`, `libFoundationInternationalization.so`, and
`lib_FoundationICU.so` and not linked the the function binary.
This is a follow up from the work make by @t089 to ensure that we don't
accidentally link Foundation again in the future.
Remove Foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/pull/436
Add test in CI to ensure we don't link to foundation :
https://github.com/swift-server/swift-aws-lambda-runtime/issues/402
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
_[One line description of your change]_
### Motivation:
_[Explain here the context, and why you're making that change. What is
the problem you're trying to solve.]_
### Modifications:
_[Describe the modifications you've done.]_
### Result:
_[After your change, what will change.]_
All the `Package.swift` files from the examples use `path: "."` instead
of `path: "Sources"` which triggers error messages when users add a
`Tests` directory.
We want that the runtime only depends on `FoundationEssentials` where
available (ie. on linux) to ensure small binary size.
### Motivation:
Smaller binary size is good for lambda deployment and cold-start times.
The runtime should only depend on `FoundationEssentials`.
### Modifications:
- replace `import Foundation` with `import FoundationEssentials` if
`FoundationEssentials` is available.
- I also applied the same treatment to tests to ensure that catch error
where tests run on linux and we use API that is only available in
`Foundation` which easily happens when you develop on macOS (where
always full `Foundation` is available).
### Result:
This should allow builds without linking full `Foundation`.
Adds default devcontainer configuration from SSWG:
https://github.com/swift-server/swift-devcontainer-template
### Motivation:
Developing for linux can be challenging on macOS because some APIs are
not available on linux. By using VSCode and devcontainer you can
essentially develop "on linux".
### Modifications:
Adds devcontainer config.
### Result:
When working in VSCode, you can now easily open the project inside a
devcontainer.
Sébastien Stormacq
Tobias
Fabian FettandSébastien Stormacq
Franz Busch
