New Plugins

[sebsto]

This is a set of new plugins to help user to get started: lambda-init, lambda-build, lambda-deploy

Motivation:

See this proposal:
https://github.com/swift-server/swift-aws-lambda-runtime/blob/main/Plugins/Documentation.docc/Proposals/0001-v2-plugins.md

Modifications:

The plugin code is minimal, just a wrapper around a CLI executable defined in a new target.

        //
        // The plugins
        // 'lambda-init' creates a new Lambda function
        // 'lambda-build' packages the Lambda function
        // 'lambda-deploy' deploys the Lambda function
        //
        //  Plugins requires Linux or at least macOS v15
        //

        // plugin to create a new Lambda function, based on a template
        .plugin(name: "AWSLambdaInitializer", targets: ["AWSLambdaInitializer"]),

        // plugin to package the lambda, creating an archive that can be uploaded to AWS
        .plugin(name: "AWSLambdaBuilder", targets: ["AWSLambdaBuilder"]),

        // plugin to deploy a Lambda function
        .plugin(name: "AWSLambdaDeployer", targets: ["AWSLambdaDeployer"]),

        .plugin(
            name: "AWSLambdaInitializer",
            capability: .command(
                intent: .custom(
                    verb: "lambda-init",
                    description:
                        "Create a new Lambda function in the current project directory."
                ),
                permissions: [
                    .writeToPackageDirectory(reason: "Create a file with an HelloWorld Lambda function.")
                ]
            ),
            dependencies: [
                .target(name: "AWSLambdaPluginHelper")
            ]
        ),

(repeated for each plugin)

And a common command line helper

        .executableTarget(
            name: "AWSLambdaPluginHelper",
            dependencies: [
                .product(name: "NIOHTTP1", package: "swift-nio"),
                .product(name: "NIOCore", package: "swift-nio"),
            ]
        ),

Result:

Three new plugins available.
TODO: add plugin output for a full init, build, deploy cycle.

[sebsto]

Issue tracker #566

[tkrajacic]

Could we add the ability to pass build options. Sometimes it is nice to optimize for size and we can use

-Xlinker -s -Xswiftc -Osize

[sebsto]

Could we add the ability to pass build options. Sometimes it is nice to optimize for size and we can use

Thank you @tkrajacic

This is planned. This will be a default setting, with an opt-out possibility --no-strip

We also propose to automatically strip the binary of debug symbols (-Xlinker -s) to reduce the size of the ZIP file. Our tests showed that this can reduce the size by up to 50%. An option to disable stripping will be provided.

I think -Xswiftc -Osize is the default with --release, but I will double check.

UPDATE: It's difficult to get an authoritative list of compiler and linker flags passed with --release. It looks like only -O is given. I'm not sure if -O size should be a default or an opt-in. Depending on the use case, Lambda developers might favor raw performance vs cold start time. It would be interesting to measure the effect of these. We need a basic benchmark suite to measure impact of these flags before taking decisions

[tkrajacic]

It's difficult to get an authoritative list of compiler and linker flags passed with --release

I was thinking more along the lines that you can pass arbitrary flags through to the compiler.
maybe just everything at the end of the invocation and after a -- or so?
I would definitely let the user decide how they want to compile their code.

Alternatively, why not just allow the user to add any -Xswiftc xxx flags and add them to the compiler flags?

[sebsto]

Alternatively, why not just allow the user to add any -Xswiftc xxx flags and add them to the compiler flags?

I think we should provide both. 1/ a sensible default set of options (like -Xlinker -s) by default to allow the best performance for all users and 2/ a possibility to pass any command for advanced users (that will override the default)