This PR has been reworked. Instead of silently switching the default
base image based on Swift version, we now:
1. **Keep Amazon Linux 2 as the default** base Docker image for the
packager plugin
2. **Add a prominent deprecation warning** when AL2 is used (either via
Docker or natively), informing developers that AL2 reaches End of Life
on June 30, 2026
3. **Migrate all examples** (READMEs, SAM templates, scripts) to build
and deploy on Amazon Linux 2023 (`provided.al2023` runtime +
`--base-docker-image swift:amazonlinux2023`)
4. **Update documentation** (readme, quick-setup) with migration notes
The warning includes the `--base-docker-image swift:6.3-amazonlinux2023`
flag and reminds developers to use the `provided.al2023` runtime when
deploying.
After June 30, 2026, the default will switch to AL2023.
---
<details>
<summary>Original PR description (superseded)</summary>
~~Now that Docker Hub has official Swift images based on Amazon Linux
2023 (starting with 6.3), the packager plugin picks the right base image
automatically depending on the Swift version:~~
~~- Swift 6.3 and later: `swift:<version>-amazonlinux2023`~~
~~- Earlier versions: `swift:<version>-amazonlinux2` (unchanged
behavior)~~
~~- No version specified (latest): defaults to `amazonlinux2023`~~
~~When only a major version is provided (e.g. `--swift-version 6`
without a minor), we conservatively treat it as 6.0 and use Amazon Linux
2, since we can't be sure it's 6.3+.~~
~~Also added a verbose log line showing the resolved Swift version,
Amazon Linux version, and final base image to help with debugging.~~
~~The `--base-docker-image` flag still overrides everything as before.~~
</details>
---------
Co-authored-by: Sébastien Stormacq <stormacq@amazon.lu>
Drop support fro Swift 6.0 as per ecosystem's policy to support the last
three major versions, now 6.1, 6.2, and 6.3
- CI is updated
- all docs, readme, and examples are updated to 6.3 as default
## Summary
Examples now default to the published `swift-aws-lambda-runtime` package
from GitHub, so they work out of the box when cloned standalone (as
described in the READMEs).
CI scripts swap the dependency to the local path (`../..`) before
building, ensuring we still test against the current branch.
### Changes
- **`Examples/APIGatewayV2/Package.swift`** — Default to remote URL,
local path is commented out with clear instructions.
- **`.github/workflows/scripts/use-local-deps.sh`** (new) — Shared
script that rewrites Package.swift to use the local dependency.
- **`integration_tests.sh`**, **`check-archive-plugin.sh`**,
**`check-link-foundation.sh`** — Source `use-local-deps.sh` before
building.
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>
This PR adds a new example demonstrating how to build a Lambda function
that handles requests from multiple sources (Application Load Balancer
and API Gateway V2) using a single handler.
### What's New
**New Example: `Examples/MultiSourceAPI`**
A Lambda function that:
- Implements `StreamingLambdaHandler` to accept raw `ByteBuffer` events
- Dynamically decodes events as either `ALBTargetGroupRequest` or
`APIGatewayV2Request`
- Returns appropriate responses based on the detected event source
- Demonstrates handling multiple AWS service integrations with a single
function
### Key Features
- **Type-safe event detection**: Uses Swift's `Decodable` to identify
the event source at runtime
- **Streaming response**: Implements `StreamingLambdaHandler` for
efficient response handling
- **Complete deployment**: Includes SAM template with both ALB and API
Gateway V2 infrastructure
- **Production-ready**: Full VPC setup with subnets, security groups,
and load balancer configuration
### Files Added
- `Examples/MultiSourceAPI/Sources/main.swift` - Lambda handler
implementation
- `Examples/MultiSourceAPI/Package.swift` - Swift package configuration
- `Examples/MultiSourceAPI/template.yaml` - SAM deployment template with
ALB and API Gateway V2
- `Examples/MultiSourceAPI/README.md` - Documentation with build,
deploy, and test instructions
- Updated CI to include the new example
### Use Case
This pattern is useful when you want to:
- Expose the same Lambda function through multiple AWS services
- Reduce code duplication by handling similar requests from different
sources
- Maintain a single codebase for multi-channel APIs
---------
Co-authored-by: Sebastien Stormacq <stormacq@amazon.lu>
Co-authored-by: Josh Elkins <jbelkins@users.noreply.github.com>
Sébastien Stormacq