-
Notifications
You must be signed in to change notification settings - Fork 1
/
bb.edn
154 lines (125 loc) · 9.89 KB
/
bb.edn
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
{:deps {io.github.FieryCod/holy-lambda-babashka-tasks
{:git/url "https://github.com/FieryCod/holy-lambda"
:deps/root "./modules/holy-lambda-babashka-tasks"
:sha "0d1bfdc0b990ed2993d38a4c3a7a37c54a9e65c6"}}
;; Local repositories should be downloaded to `.holy-lambda` directory
;; This way project artifacts are separated from global ~/.m2 and only project artifacts
;; are deployed to AWS Lambda
:mvn/local-repo ".holy-lambda/.m2"
;; Minimal babashka version which should be used in conjuction with holy-lambda
:min-bb-version "0.3.7"
:holy-lambda/options {
;; User should use docker for local development and use `HL_NO_DOCKER` environment variable
;; set to "true" for CI based deployments.
;; For CI based deployments user should base it's builder image on `fierycod/graalvm-native-image:ce`
:docker {
;; HL runs bb tasks in docker context which means that local libraries will not work out-of-the-box.
;;
;; To make local libraries work with HL you have to:
;; 1. Mount your local library folder as a docker volume.
;; 2. Modify the `deps.edn` to use library path available in docker context.
;; Preferably use `deps.edn` alias and reference it's name in `:build:clj-name`
;; ----------------------------------------------------------------------------
;; Single volume definition:
;;
;; {:docker "/path-where-to-mount-local-library-on-docker"
;; :host "relative-local-library-path"}
:volumes []
;; GraalVM Community holy-lambda compatible docker image
;; You can always build your own GraalVM image with enterprise edition
:image "fierycod/graalvm-native-image:ce"}
:build {;; clj alias might be set via environment variable
;; `HL_CLJ_ALIAS` like: HL_CLJ_ALIAS="dev"
:clj-alias nil
;; Used when either :docker is nil or
;; `HL_NO_DOCKER` environment variable is set to "true"
;; Might be set via `GRAALVM_HOME` environment variable
:graalvm-home "~/.graalvm"}
:stack {
;; Stack name which will be used in cloudformation
:name "cdk-azure-pipelines-115408-stack"
;; Default lambda which is triggered on `stack:invoke` or
;; listen to via `stack:logs`. You can always pass different lambda name via
;; `:name` parameter. Check `bb tasks`
:default-lambda "ExampleLambdaFunction"
;; File which is used for providing envs for functions during
;; `stack:invoke` and `stack:api`
;; Look at: https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-using-invoke.html#serverless-sam-cli-using-invoke-environment-file
:envs "envs.json"
;; Template file which should be used
;; holy-lambda uses AWS SAM under the hood, therefore
;; https://aws.amazon.com/serverless/sam/
;; for more template examples search for AWS SAM templates :)
:template "template.yml"
;; Check https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_CreateStack.html
:capabilities ["CAPABILITY_IAM"]}
:runtime
{
;; Choose one of the supported runtime `:babashka`, `:native`, `:java`
:name :native
;; Runtime `:babashka` provides a way to include native libraries called pods https://github.com/babashka/pods
;; Holy lambda ships code exists to provide fast feedback loop therefore pods should be shipped using AWS Layers
;; Check this template https://github.com/aws-samples/aws-lambda-layers-aws-sam-examples/blob/master/aws-sdk-layer/template.yaml
;; and official docs https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-layers.html
;; CodeUri should be `.holy-lambda/pods`
;; For now pods should be declared in `bb.edn`. See: https://github.com/babashka/babashka/issues/768#issuecomment-825016317
;;
;; `IMPORTANT:` 3rd party babashka compatible libraries should be distributed as a layers (CodeUri: .holy-lambda/bb-clj-deps)
:pods {org.babashka/aws "0.0.6"}
;; Native runtimes have a special environment variable $Entrypoint which is available during code execution
;; :entrypoint should always point to a namespace with includes (native/entrypoint) call
:entrypoint cdk-azure-pipelines.core
;; Flag which indicates that holy-lambda should auto deploy the applications and layers for the corresponding :runtime
;; If set to false holy-lambda will guide you through the steps of dependants deployment.
:self-manage-layers? false
;; For `:native` runtime you can provide your own bootstrap file
:bootstrap-file "bootstrap"
;; For `:native` runtime you can provide some native resources which will be available during lambda execution
;; Resources are packed as is.
:native-deps "resources"
;; Some of the runtimes are versioned. For instance `:babashka` runtime is a versioned layer which ships it's own version of
;; clojure, holy-lambda, default-retriever
:version "0.1.0"
;; Specify custom arguments for native image generation
;; Works only on `:native` runtime.
;; Check https://www.graalvm.org/reference-manual/native-image/Options/
:native-image-args ["--verbose"
"--no-fallback"
"--enable-url-protocols=http,https"
"--report-unsupported-elements-at-runtime"
"-H:+AllowIncompleteClasspath"
"--no-server"
"--initialize-at-build-time"]}
;; Infrastructure properties
:infra
{
;; Prefix for the bucket. Prefix should group multiple stacks
;; A good one would be a company name
:bucket-prefix "holy-lambda"
;; Bucket name for the stack
:bucket-name "cdk-azure-pipelines-115408"
;; If profile is `nil` then default AWS profile is used
:profile "default"
;; Region overrides default region from the AWS profile
:region "eu-central-1"}}
:tasks {:requires ([holy-lambda.tasks])
bucket:create holy-lambda.tasks/bucket:create
bucket:remove holy-lambda.tasks/bucket:remove
docker:run holy-lambda.tasks/docker:run
native:conf holy-lambda.tasks/native:conf
native:executable holy-lambda.tasks/native:executable
stack:sync holy-lambda.tasks/stack:sync
stack:compile holy-lambda.tasks/stack:compile
stack:invoke holy-lambda.tasks/stack:invoke
stack:api holy-lambda.tasks/stack:api
stack:pack holy-lambda.tasks/stack:pack
stack:deploy holy-lambda.tasks/stack:deploy
stack:describe holy-lambda.tasks/stack:describe
stack:doctor holy-lambda.tasks/stack:doctor
stack:purge holy-lambda.tasks/stack:purge
stack:destroy holy-lambda.tasks/stack:destroy
stack:logs holy-lambda.tasks/stack:logs
stack:version holy-lambda.tasks/stack:version
stack:lint holy-lambda.tasks/stack:lint
}
}