See issue #536
All the examples are now depending on the runtime library located at
`../..`. The `Package.swift` files contain a commented line with the
`.package` to use when user wants to fetch the runtime from GitHub.
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Fix errors in the CI
The script that checks the presence of `libFoundation` in the binary
started to fail.
I can't think about a recent change that would cause this.
This PR change the test script to use the `HelloWorld` example instead
of `APIGAtewayV2`
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Resources are not included in the archive on Linux
https://github.com/swift-server/swift-aws-lambda-runtime/issues/505
In addition, the script that checks if the resources are correctly
included in an archive when building on Linux is not working.
It failed to detected missing resources.
This patch fix both the plugin and the CI script
When we include Traits, we changed the CI container from Swift 6.0
Amazon Linux to Swift 6.1 Nightly on Ubuntu.
This broke the CI because AWS SDK used in the `Examples/S3_AWSSDK`
example depends on `libssl-devel` which is not installed by default on
Jammy images.
This PR reverts back the container used to test all examples to an
Amazon Linux 2, but this time the 6.1-nightly version to allow to
compile the package traits.
This should address
https://github.com/swift-server/swift-aws-lambda-runtime/issues/494
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
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.]_
Sébastien Stormacq