You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A package is an entry in a `BUILD.yaml` in the `packages` section. All packages share the following fields:
55
-
```YAML
56
-
# name is the component-wide unique name of this package
57
-
name: must-not-contain-spaces
58
-
# Package type must be one of: go, yarn, docker, generic
59
-
type: generic
60
-
# Sources list all sources of this package. Entries can be double-star globs and are relative to the component root.
61
-
# Avoid listing sources outside the component folder.
62
-
srcs:
63
-
- "**/*.yaml"
64
-
- "glob/**/path"
65
-
# Deps list dependencies to other packages which must be built prior to building this package. How these dependencies are made
66
-
# available during build depends on the package type.
67
-
deps:
68
-
- some/other:package
69
-
# Argdeps makes build arguments version relevant. I.e. if the value of a build arg listed here changes, so does the package version.
70
-
argdeps:
71
-
- someBuildArg
72
-
# Env is a list of key=value pair environment variables available during package build
73
-
env:
74
-
- CGO_ENABLED=0
75
-
# Config configures the package build depending on the package type. See below for details
76
-
config:
77
-
...
78
-
```
79
-
80
53
## Script
81
54
Scripts are a great way to automate tasks during development time (think [`yarn scripts`](https://classic.yarnpkg.com/en/docs/package-json#toc-scripts)).
82
55
Unlike packages they do not run in isolation by default, but have access to the original workspace.
@@ -113,13 +86,32 @@ script: |
113
86
echo "build args work to: ${myBuildArg}"
114
87
```
115
88
116
-
### Build arguments
117
-
118
-
In a package definition one can use _build arguments_. Build args have the form of `${argumentName}` and are string-replaced when the package is loaded.
119
-
**It's advisable to use build args only within the `config` section of packages**. Constants and built-in build args do not even work outside of the config section.
120
-
121
-
Leeway supports built-in build arguments:
122
-
- `__pkg_version`resolves to the leeway version hash of a component.
89
+
## Package
90
+
A package is an entry in a `BUILD.yaml` in the `packages` section. All packages share the following fields:
91
+
```YAML
92
+
# name is the component-wide unique name of this package
93
+
name: must-not-contain-spaces
94
+
# Package type must be one of: go, yarn, docker, generic
95
+
type: generic
96
+
# Sources list all sources of this package. Entries can be double-star globs and are relative to the component root.
97
+
# Avoid listing sources outside the component folder.
98
+
srcs:
99
+
- "**/*.yaml"
100
+
- "glob/**/path"
101
+
# Deps list dependencies to other packages which must be built prior to building this package. How these dependencies are made
102
+
# available during build depends on the package type.
103
+
deps:
104
+
- some/other:package
105
+
# Argdeps makes build arguments version relevant. I.e. if the value of a build arg listed here changes, so does the package version.
106
+
argdeps:
107
+
- someBuildArg
108
+
# Env is a list of key=value pair environment variables available during package build
109
+
env:
110
+
- CGO_ENABLED=0
111
+
# Config configures the package build depending on the package type. See below for details
112
+
config:
113
+
...
114
+
```
123
115
124
116
### Go packages
125
117
```YAML
@@ -200,6 +192,87 @@ config:
200
192
- ["sh", "-c", "ls *"]
201
193
```
202
194
195
+
## Dynaimc package scripts
196
+
Packages can be dynamically produced within a component using a dynamic package script named `BUILD.js`. This ECMAScript 5.1 file is executed using [Goja](https://github.com/dop251/goja) and produces a `packages` array which contains the package struct much like they'd exist within the `BUILD.yaml`. For example:
197
+
198
+
199
+
<table>
200
+
<tr>
201
+
<td valign="top">
202
+
203
+
`BUILD.js`file
204
+
205
+
```JavaScript
206
+
let packages = [];
207
+
208
+
let deps = [];
209
+
for(let i = 0; i < 5; i++) {
210
+
const name = "hello-"+i;
211
+
deps.push(name);
212
+
packages.push({
213
+
name: name,
214
+
type: "generic",
215
+
config: {
216
+
commands: [
217
+
["echo", "hello from "+i]
218
+
]
219
+
}
220
+
});
221
+
}
222
+
223
+
packages.push({
224
+
name: "all",
225
+
type: "generic",
226
+
deps: deps.map(d => ":" + d),
227
+
})
228
+
```
229
+
</td>
230
+
<td>
231
+
232
+
Equivalent `BUILD.yaml`
233
+
```YAML
234
+
pacakages:
235
+
- name: all
236
+
type: generic
237
+
deps:
238
+
- hello-1
239
+
- hello-2
240
+
- hello-3
241
+
- hello-4
242
+
- hello-5
243
+
- name: hello-1
244
+
type: generic
245
+
config:
246
+
commands:
247
+
- ["echo", "hello from 1"]
248
+
- name: hello-2
249
+
type: generic
250
+
config:
251
+
commands:
252
+
- ["echo", "hello from 2"]
253
+
- name: hello-3
254
+
type: generic
255
+
config:
256
+
commands:
257
+
- ["echo", "hello from 3"]
258
+
...
259
+
```
260
+
261
+
</td>
262
+
</tr>
263
+
</table>
264
+
265
+
> **Note** that for a `BUILD.js` to become effective/be recodnized there needs to a (possibly empty) `BUILD.yaml` in the same directory.
266
+
267
+
## Build arguments
268
+
269
+
In a package definition one can use _build arguments_. Build args have the form of `${argumentName}` and are string-replaced when the package is loaded.
270
+
**It's advisable to use build args only within the `config` section of packages**. Constants and built-in build args do not even work outside of the config section.
271
+
272
+
Leeway supports built-in build arguments:
273
+
- `__pkg_version`resolves to the leeway version hash of a component.
274
+
- `__git_commit`contains the current Git commit if the build is executed from within a Git working copy. If this variable is used and the build is not executed from within a Git working copy the variable resolution will fail.
275
+
203
276
## Package Variants
204
277
Leeway supports build-time variance through "package variants". Those variants are defined on the workspace level and can modify the list of sources, environment variables and config of packages.
205
278
For example consider a `WORKSPACE.YAML` with this variants section:
0 commit comments