path: root/python-aws-cdk-aws-lambda-go-alpha.spec

%global _empty_manifest_terminate_build 0
Name:		python-aws-cdk.aws-lambda-go-alpha
Version:	2.81.0a0
Release:	1
Summary:	The CDK Construct Library for AWS Lambda in Golang
License:	Apache-2.0
URL:		https://github.com/aws/aws-cdk
Source0:	https://mirrors.nju.edu.cn/pypi/web/packages/1a/39/2d13bb75fec2ab385249e86054aba62ab1ecb8bf84d09e0f7c841014b8b1/aws-cdk.aws-lambda-go-alpha-2.81.0a0.tar.gz
BuildArch:	noarch

Requires:	python3-aws-cdk-lib
Requires:	python3-constructs
Requires:	python3-jsii
Requires:	python3-publication
Requires:	python3-typeguard

%description
<!--END STABILITY BANNER-->
This library provides constructs for Golang Lambda functions.
To use this module you will either need to have `Go` installed (`go1.11` or later) or `Docker` installed.
See [Local Bundling](#local-bundling)/[Docker Bundling](#docker-bundling) for more information.
This module also requires that your Golang application is
using a Go version >= 1.11 and is using [Go modules](https://golang.org/ref/mod).
## Go Function
Define a `GoFunction`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api"
)
```
By default, if `entry` points to a directory, then the construct will assume there is a Go entry file (i.e. `main.go`).
Let's look at an example Go project:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
├── pkg
│   ├── auth
│   │   └── auth.go
│   └── middleware
│       └── middleware.go
└── vendor
    ├── github.com
    │   └── aws
    │       └── aws-lambda-go
    └── modules.txt
```
With the above layout I could either provide the `entry` as `lambda-app/cmd/api` or `lambda-app/cmd/api/main.go`, either will work.
When the construct builds the golang binary this will be translated `go build ./cmd/api` & `go build ./cmd/api/main.go` respectively.
The construct will figure out where it needs to run the `go build` command from, in this example it would be from
the `lambda-app` directory. It does this by determining the [mod file path](#mod-file-path), which is explained in the
next section.
### mod file path
The `GoFunction` tries to automatically determine your project root, that is
the root of your golang project. This is usually where the top level `go.mod` file or
`vendor` folder of your project is located. When bundling in a Docker container, the
`moduleDir` is used as the source (`/asset-input`) for the volume mounted in
the container.
The CDK will walk up parent folders starting from
the current working directory until it finds a folder containing a `go.mod` file.
Alternatively, you can specify the `moduleDir` prop manually. In this case you
need to ensure that this path includes `entry` and any module/dependencies used
by your function. Otherwise bundling will fail.
## Runtime
The `GoFunction` can be used with either the `GO_1_X` runtime or the provided runtimes (`PROVIDED`/`PROVIDED_AL2`).
By default it will use the `PROVIDED_AL2` runtime. The `GO_1_X` runtime does not support things like
[Lambda Extensions](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html), whereas the provided runtimes do.
The [aws-lambda-go](https://github.com/aws/aws-lambda-go) library has built in support for the provided runtime as long as
you name the handler `bootstrap` (which we do by default).
## Dependencies
The construct will attempt to figure out how to handle the dependencies for your function. It will
do this by determining whether or not you are vendoring your dependencies. It makes this determination
by looking to see if there is a `vendor` folder at the [mod file path](#mod-file-path).
With this information the construct can determine what commands to run. You will
generally fall into two scenarios:
1. You are using vendoring (indicated by the presence of a `vendor` folder)
   In this case `go build` will be run with `-mod=vendor` set
2. You are not using vendoring (indicated by the absence of a `vendor` folder)
   If you are not vendoring then `go build` will be run without `-mod=vendor`
   since the default behavior is to download dependencies
All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-lambda).
## Environment
By default the following environment variables are set for you:
* `GOOS=linux`
* `GOARCH`: based on the target architecture of the Lambda function
* `GO111MODULE=on`
Use the `environment` prop to define additional environment variables when go runs:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        environment={
            "HELLO": "WORLD"
        }
    )
)
```
## Local Bundling
If `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-go1.x) with the Docker platform based on the target architecture of the Lambda function.
For macOS the recommended approach is to install `Go` as Docker volume performance is really poor.
`Go` can be installed by following the [installation docs](https://golang.org/doc/install).
## Docker
To force bundling in a docker container even if `Go` is available in your environment, set the `forceDockerBundling` prop to `true`. This is useful if you want to make sure that your function is built in a consistent Lambda compatible environment.
Use the `buildArgs` prop to pass build arguments when building the bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        build_args={
            "HTTPS_PROXY": "https://127.0.0.1:3001"
        }
    )
)
```
Use the `bundling.dockerImage` prop to use a custom bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        docker_image=DockerImage.from_build("/path/to/Dockerfile")
    )
)
```
Use the `bundling.goBuildFlags` prop to pass additional build flags to `go build`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_build_flags=["-ldflags \"-s -w\""]
    )
)
```
By default this construct doesn't use any Go module proxies. This is contrary to
a standard Go installation, which would use the Google proxy by default. To
recreate that behavior, do the following:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_proxies=[go.GoFunction.GOOGLE_GOPROXY, "direct"]
    )
)
```
You can set additional Docker options to configure the build environment:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        network="host",
        security_opt="no-new-privileges",
        user="user:group",
        volumes_from=["777f7dc92da7"],
        volumes=[DockerVolume(host_path="/host-path", container_path="/container-path")]
    )
)
```
## Command hooks
It is  possible to run additional commands by specifying the `commandHooks` prop:
```text
// This example only available in TypeScript
// Run additional commands on a GoFunction via `commandHooks` property
new go.GoFunction(this, 'handler', {
  bundling: {
    commandHooks: {
      // run tests
      beforeBundling(inputDir: string): string[] {
        return ['go test ./cmd/api -v'];
      },
      // ...
    },
  },
});
```
The following hooks are available:
* `beforeBundling`: runs before all bundling commands
* `afterBundling`: runs after all bundling commands
They all receive the directory containing the `go.mod` file (`inputDir`) and the
directory where the bundled asset will be output (`outputDir`). They must return
an array of commands to run. Commands are chained with `&&`.
The commands will run in the environment in which bundling occurs: inside the
container for Docker bundling or on the host OS for local bundling.
## Additional considerations
Depending on how you structure your Golang application, you may want to change the `assetHashType` parameter.
By default this parameter is set to `AssetHashType.OUTPUT` which means that the CDK will calculate the asset hash
(and determine whether or not your code has changed) based on the Golang executable that is created.
If you specify `AssetHashType.SOURCE`, the CDK will calculate the asset hash by looking at the folder
that contains your `go.mod` file. If you are deploying a single Lambda function, or you want to redeploy
all of your functions if anything changes, then `AssetHashType.SOURCE` will probably work.
For example, if my app looked like this:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    └── auth
        └── auth.go
```
With this structure I would provide the `entry` as `cmd/api` which means that the CDK
will determine that the protect root is `lambda-app` (it contains the `go.mod` file).
Since I only have a single Lambda function, and any update to files within the `lambda-app` directory
should trigger a new deploy, I could specify `AssetHashType.SOURCE`.
On the other hand, if I had a project that deployed multiple Lambda functions, for example:
```bash
lamda-app
├── cmd
│   ├── api
│   │   └── main.go
│   └── anotherApi
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    ├── auth
    │   └── auth.go
    └── middleware
        └── middleware.go
```
Then I would most likely want `AssetHashType.OUTPUT`. With `OUTPUT`
the CDK will only recognize changes if the Golang executable has changed,
and Go only includes dependencies that are used in the executable. So in this case
if `cmd/api` used the `auth` & `middleware` packages, but `cmd/anotherApi` did not, then
an update to `auth` or `middleware` would only trigger an update to the `cmd/api` Lambda
Function.
## Docker based bundling in complex Docker configurations
By default the input and output of Docker based bundling is handled via bind mounts.
In situtations where this does not work, like Docker-in-Docker setups or when using a remote Docker socket, you can configure an alternative, but slower, variant that also works in these situations.
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        bundling_file_access=BundlingFileAccess.VOLUME_COPY
    )
)
```

%package -n python3-aws-cdk.aws-lambda-go-alpha
Summary:	The CDK Construct Library for AWS Lambda in Golang
Provides:	python-aws-cdk.aws-lambda-go-alpha
BuildRequires:	python3-devel
BuildRequires:	python3-setuptools
BuildRequires:	python3-pip
%description -n python3-aws-cdk.aws-lambda-go-alpha
<!--END STABILITY BANNER-->
This library provides constructs for Golang Lambda functions.
To use this module you will either need to have `Go` installed (`go1.11` or later) or `Docker` installed.
See [Local Bundling](#local-bundling)/[Docker Bundling](#docker-bundling) for more information.
This module also requires that your Golang application is
using a Go version >= 1.11 and is using [Go modules](https://golang.org/ref/mod).
## Go Function
Define a `GoFunction`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api"
)
```
By default, if `entry` points to a directory, then the construct will assume there is a Go entry file (i.e. `main.go`).
Let's look at an example Go project:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
├── pkg
│   ├── auth
│   │   └── auth.go
│   └── middleware
│       └── middleware.go
└── vendor
    ├── github.com
    │   └── aws
    │       └── aws-lambda-go
    └── modules.txt
```
With the above layout I could either provide the `entry` as `lambda-app/cmd/api` or `lambda-app/cmd/api/main.go`, either will work.
When the construct builds the golang binary this will be translated `go build ./cmd/api` & `go build ./cmd/api/main.go` respectively.
The construct will figure out where it needs to run the `go build` command from, in this example it would be from
the `lambda-app` directory. It does this by determining the [mod file path](#mod-file-path), which is explained in the
next section.
### mod file path
The `GoFunction` tries to automatically determine your project root, that is
the root of your golang project. This is usually where the top level `go.mod` file or
`vendor` folder of your project is located. When bundling in a Docker container, the
`moduleDir` is used as the source (`/asset-input`) for the volume mounted in
the container.
The CDK will walk up parent folders starting from
the current working directory until it finds a folder containing a `go.mod` file.
Alternatively, you can specify the `moduleDir` prop manually. In this case you
need to ensure that this path includes `entry` and any module/dependencies used
by your function. Otherwise bundling will fail.
## Runtime
The `GoFunction` can be used with either the `GO_1_X` runtime or the provided runtimes (`PROVIDED`/`PROVIDED_AL2`).
By default it will use the `PROVIDED_AL2` runtime. The `GO_1_X` runtime does not support things like
[Lambda Extensions](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html), whereas the provided runtimes do.
The [aws-lambda-go](https://github.com/aws/aws-lambda-go) library has built in support for the provided runtime as long as
you name the handler `bootstrap` (which we do by default).
## Dependencies
The construct will attempt to figure out how to handle the dependencies for your function. It will
do this by determining whether or not you are vendoring your dependencies. It makes this determination
by looking to see if there is a `vendor` folder at the [mod file path](#mod-file-path).
With this information the construct can determine what commands to run. You will
generally fall into two scenarios:
1. You are using vendoring (indicated by the presence of a `vendor` folder)
   In this case `go build` will be run with `-mod=vendor` set
2. You are not using vendoring (indicated by the absence of a `vendor` folder)
   If you are not vendoring then `go build` will be run without `-mod=vendor`
   since the default behavior is to download dependencies
All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-lambda).
## Environment
By default the following environment variables are set for you:
* `GOOS=linux`
* `GOARCH`: based on the target architecture of the Lambda function
* `GO111MODULE=on`
Use the `environment` prop to define additional environment variables when go runs:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        environment={
            "HELLO": "WORLD"
        }
    )
)
```
## Local Bundling
If `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-go1.x) with the Docker platform based on the target architecture of the Lambda function.
For macOS the recommended approach is to install `Go` as Docker volume performance is really poor.
`Go` can be installed by following the [installation docs](https://golang.org/doc/install).
## Docker
To force bundling in a docker container even if `Go` is available in your environment, set the `forceDockerBundling` prop to `true`. This is useful if you want to make sure that your function is built in a consistent Lambda compatible environment.
Use the `buildArgs` prop to pass build arguments when building the bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        build_args={
            "HTTPS_PROXY": "https://127.0.0.1:3001"
        }
    )
)
```
Use the `bundling.dockerImage` prop to use a custom bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        docker_image=DockerImage.from_build("/path/to/Dockerfile")
    )
)
```
Use the `bundling.goBuildFlags` prop to pass additional build flags to `go build`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_build_flags=["-ldflags \"-s -w\""]
    )
)
```
By default this construct doesn't use any Go module proxies. This is contrary to
a standard Go installation, which would use the Google proxy by default. To
recreate that behavior, do the following:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_proxies=[go.GoFunction.GOOGLE_GOPROXY, "direct"]
    )
)
```
You can set additional Docker options to configure the build environment:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        network="host",
        security_opt="no-new-privileges",
        user="user:group",
        volumes_from=["777f7dc92da7"],
        volumes=[DockerVolume(host_path="/host-path", container_path="/container-path")]
    )
)
```
## Command hooks
It is  possible to run additional commands by specifying the `commandHooks` prop:
```text
// This example only available in TypeScript
// Run additional commands on a GoFunction via `commandHooks` property
new go.GoFunction(this, 'handler', {
  bundling: {
    commandHooks: {
      // run tests
      beforeBundling(inputDir: string): string[] {
        return ['go test ./cmd/api -v'];
      },
      // ...
    },
  },
});
```
The following hooks are available:
* `beforeBundling`: runs before all bundling commands
* `afterBundling`: runs after all bundling commands
They all receive the directory containing the `go.mod` file (`inputDir`) and the
directory where the bundled asset will be output (`outputDir`). They must return
an array of commands to run. Commands are chained with `&&`.
The commands will run in the environment in which bundling occurs: inside the
container for Docker bundling or on the host OS for local bundling.
## Additional considerations
Depending on how you structure your Golang application, you may want to change the `assetHashType` parameter.
By default this parameter is set to `AssetHashType.OUTPUT` which means that the CDK will calculate the asset hash
(and determine whether or not your code has changed) based on the Golang executable that is created.
If you specify `AssetHashType.SOURCE`, the CDK will calculate the asset hash by looking at the folder
that contains your `go.mod` file. If you are deploying a single Lambda function, or you want to redeploy
all of your functions if anything changes, then `AssetHashType.SOURCE` will probably work.
For example, if my app looked like this:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    └── auth
        └── auth.go
```
With this structure I would provide the `entry` as `cmd/api` which means that the CDK
will determine that the protect root is `lambda-app` (it contains the `go.mod` file).
Since I only have a single Lambda function, and any update to files within the `lambda-app` directory
should trigger a new deploy, I could specify `AssetHashType.SOURCE`.
On the other hand, if I had a project that deployed multiple Lambda functions, for example:
```bash
lamda-app
├── cmd
│   ├── api
│   │   └── main.go
│   └── anotherApi
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    ├── auth
    │   └── auth.go
    └── middleware
        └── middleware.go
```
Then I would most likely want `AssetHashType.OUTPUT`. With `OUTPUT`
the CDK will only recognize changes if the Golang executable has changed,
and Go only includes dependencies that are used in the executable. So in this case
if `cmd/api` used the `auth` & `middleware` packages, but `cmd/anotherApi` did not, then
an update to `auth` or `middleware` would only trigger an update to the `cmd/api` Lambda
Function.
## Docker based bundling in complex Docker configurations
By default the input and output of Docker based bundling is handled via bind mounts.
In situtations where this does not work, like Docker-in-Docker setups or when using a remote Docker socket, you can configure an alternative, but slower, variant that also works in these situations.
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        bundling_file_access=BundlingFileAccess.VOLUME_COPY
    )
)
```

%package help
Summary:	Development documents and examples for aws-cdk.aws-lambda-go-alpha
Provides:	python3-aws-cdk.aws-lambda-go-alpha-doc
%description help
<!--END STABILITY BANNER-->
This library provides constructs for Golang Lambda functions.
To use this module you will either need to have `Go` installed (`go1.11` or later) or `Docker` installed.
See [Local Bundling](#local-bundling)/[Docker Bundling](#docker-bundling) for more information.
This module also requires that your Golang application is
using a Go version >= 1.11 and is using [Go modules](https://golang.org/ref/mod).
## Go Function
Define a `GoFunction`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api"
)
```
By default, if `entry` points to a directory, then the construct will assume there is a Go entry file (i.e. `main.go`).
Let's look at an example Go project:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
├── pkg
│   ├── auth
│   │   └── auth.go
│   └── middleware
│       └── middleware.go
└── vendor
    ├── github.com
    │   └── aws
    │       └── aws-lambda-go
    └── modules.txt
```
With the above layout I could either provide the `entry` as `lambda-app/cmd/api` or `lambda-app/cmd/api/main.go`, either will work.
When the construct builds the golang binary this will be translated `go build ./cmd/api` & `go build ./cmd/api/main.go` respectively.
The construct will figure out where it needs to run the `go build` command from, in this example it would be from
the `lambda-app` directory. It does this by determining the [mod file path](#mod-file-path), which is explained in the
next section.
### mod file path
The `GoFunction` tries to automatically determine your project root, that is
the root of your golang project. This is usually where the top level `go.mod` file or
`vendor` folder of your project is located. When bundling in a Docker container, the
`moduleDir` is used as the source (`/asset-input`) for the volume mounted in
the container.
The CDK will walk up parent folders starting from
the current working directory until it finds a folder containing a `go.mod` file.
Alternatively, you can specify the `moduleDir` prop manually. In this case you
need to ensure that this path includes `entry` and any module/dependencies used
by your function. Otherwise bundling will fail.
## Runtime
The `GoFunction` can be used with either the `GO_1_X` runtime or the provided runtimes (`PROVIDED`/`PROVIDED_AL2`).
By default it will use the `PROVIDED_AL2` runtime. The `GO_1_X` runtime does not support things like
[Lambda Extensions](https://docs.aws.amazon.com/lambda/latest/dg/using-extensions.html), whereas the provided runtimes do.
The [aws-lambda-go](https://github.com/aws/aws-lambda-go) library has built in support for the provided runtime as long as
you name the handler `bootstrap` (which we do by default).
## Dependencies
The construct will attempt to figure out how to handle the dependencies for your function. It will
do this by determining whether or not you are vendoring your dependencies. It makes this determination
by looking to see if there is a `vendor` folder at the [mod file path](#mod-file-path).
With this information the construct can determine what commands to run. You will
generally fall into two scenarios:
1. You are using vendoring (indicated by the presence of a `vendor` folder)
   In this case `go build` will be run with `-mod=vendor` set
2. You are not using vendoring (indicated by the absence of a `vendor` folder)
   If you are not vendoring then `go build` will be run without `-mod=vendor`
   since the default behavior is to download dependencies
All other properties of `lambda.Function` are supported, see also the [AWS Lambda construct library](https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/aws-lambda).
## Environment
By default the following environment variables are set for you:
* `GOOS=linux`
* `GOARCH`: based on the target architecture of the Lambda function
* `GO111MODULE=on`
Use the `environment` prop to define additional environment variables when go runs:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        environment={
            "HELLO": "WORLD"
        }
    )
)
```
## Local Bundling
If `Go` is installed locally and the version is >= `go1.11` then it will be used to bundle your code in your environment. Otherwise, bundling will happen in a [Lambda compatible Docker container](https://gallery.ecr.aws/sam/build-go1.x) with the Docker platform based on the target architecture of the Lambda function.
For macOS the recommended approach is to install `Go` as Docker volume performance is really poor.
`Go` can be installed by following the [installation docs](https://golang.org/doc/install).
## Docker
To force bundling in a docker container even if `Go` is available in your environment, set the `forceDockerBundling` prop to `true`. This is useful if you want to make sure that your function is built in a consistent Lambda compatible environment.
Use the `buildArgs` prop to pass build arguments when building the bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        build_args={
            "HTTPS_PROXY": "https://127.0.0.1:3001"
        }
    )
)
```
Use the `bundling.dockerImage` prop to use a custom bundling image:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        docker_image=DockerImage.from_build("/path/to/Dockerfile")
    )
)
```
Use the `bundling.goBuildFlags` prop to pass additional build flags to `go build`:
```python
go.GoFunction(self, "handler",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_build_flags=["-ldflags \"-s -w\""]
    )
)
```
By default this construct doesn't use any Go module proxies. This is contrary to
a standard Go installation, which would use the Google proxy by default. To
recreate that behavior, do the following:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        go_proxies=[go.GoFunction.GOOGLE_GOPROXY, "direct"]
    )
)
```
You can set additional Docker options to configure the build environment:
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        network="host",
        security_opt="no-new-privileges",
        user="user:group",
        volumes_from=["777f7dc92da7"],
        volumes=[DockerVolume(host_path="/host-path", container_path="/container-path")]
    )
)
```
## Command hooks
It is  possible to run additional commands by specifying the `commandHooks` prop:
```text
// This example only available in TypeScript
// Run additional commands on a GoFunction via `commandHooks` property
new go.GoFunction(this, 'handler', {
  bundling: {
    commandHooks: {
      // run tests
      beforeBundling(inputDir: string): string[] {
        return ['go test ./cmd/api -v'];
      },
      // ...
    },
  },
});
```
The following hooks are available:
* `beforeBundling`: runs before all bundling commands
* `afterBundling`: runs after all bundling commands
They all receive the directory containing the `go.mod` file (`inputDir`) and the
directory where the bundled asset will be output (`outputDir`). They must return
an array of commands to run. Commands are chained with `&&`.
The commands will run in the environment in which bundling occurs: inside the
container for Docker bundling or on the host OS for local bundling.
## Additional considerations
Depending on how you structure your Golang application, you may want to change the `assetHashType` parameter.
By default this parameter is set to `AssetHashType.OUTPUT` which means that the CDK will calculate the asset hash
(and determine whether or not your code has changed) based on the Golang executable that is created.
If you specify `AssetHashType.SOURCE`, the CDK will calculate the asset hash by looking at the folder
that contains your `go.mod` file. If you are deploying a single Lambda function, or you want to redeploy
all of your functions if anything changes, then `AssetHashType.SOURCE` will probably work.
For example, if my app looked like this:
```bash
lamda-app
├── cmd
│   └── api
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    └── auth
        └── auth.go
```
With this structure I would provide the `entry` as `cmd/api` which means that the CDK
will determine that the protect root is `lambda-app` (it contains the `go.mod` file).
Since I only have a single Lambda function, and any update to files within the `lambda-app` directory
should trigger a new deploy, I could specify `AssetHashType.SOURCE`.
On the other hand, if I had a project that deployed multiple Lambda functions, for example:
```bash
lamda-app
├── cmd
│   ├── api
│   │   └── main.go
│   └── anotherApi
│       └── main.go
├── go.mod
├── go.sum
└── pkg
    ├── auth
    │   └── auth.go
    └── middleware
        └── middleware.go
```
Then I would most likely want `AssetHashType.OUTPUT`. With `OUTPUT`
the CDK will only recognize changes if the Golang executable has changed,
and Go only includes dependencies that are used in the executable. So in this case
if `cmd/api` used the `auth` & `middleware` packages, but `cmd/anotherApi` did not, then
an update to `auth` or `middleware` would only trigger an update to the `cmd/api` Lambda
Function.
## Docker based bundling in complex Docker configurations
By default the input and output of Docker based bundling is handled via bind mounts.
In situtations where this does not work, like Docker-in-Docker setups or when using a remote Docker socket, you can configure an alternative, but slower, variant that also works in these situations.
```python
go.GoFunction(self, "GoFunction",
    entry="app/cmd/api",
    bundling=go.BundlingOptions(
        bundling_file_access=BundlingFileAccess.VOLUME_COPY
    )
)
```

%prep
%autosetup -n aws-cdk.aws-lambda-go-alpha-2.81.0a0

%build
%py3_build

%install
%py3_install
install -d -m755 %{buildroot}/%{_pkgdocdir}
if [ -d doc ]; then cp -arf doc %{buildroot}/%{_pkgdocdir}; fi
if [ -d docs ]; then cp -arf docs %{buildroot}/%{_pkgdocdir}; fi
if [ -d example ]; then cp -arf example %{buildroot}/%{_pkgdocdir}; fi
if [ -d examples ]; then cp -arf examples %{buildroot}/%{_pkgdocdir}; fi
pushd %{buildroot}
if [ -d usr/lib ]; then
	find usr/lib -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/lib64 ]; then
	find usr/lib64 -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/bin ]; then
	find usr/bin -type f -printf "/%h/%f\n" >> filelist.lst
fi
if [ -d usr/sbin ]; then
	find usr/sbin -type f -printf "/%h/%f\n" >> filelist.lst
fi
touch doclist.lst
if [ -d usr/share/man ]; then
	find usr/share/man -type f -printf "/%h/%f.gz\n" >> doclist.lst
fi
popd
mv %{buildroot}/filelist.lst .
mv %{buildroot}/doclist.lst .

%files -n python3-aws-cdk.aws-lambda-go-alpha -f filelist.lst
%dir %{python3_sitelib}/*

%files help -f doclist.lst
%{_docdir}/*

%changelog
* Wed May 31 2023 Python_Bot <Python_Bot@openeuler.org> - 2.81.0a0-1
- Package Spec generated