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
An itest_service is a binary that is intended to run for the duration of the integration test. Examples include databases, HTTP/RPC servers, queue consumers, external service mocks, etc.
35
35
36
+
All [common binary attributes](https://bazel.build/reference/be/common-definitions#common-attributes-binaries) are supported including `args`.
37
+
36
38
**ATTRIBUTES**
37
39
38
40
@@ -48,7 +50,7 @@ An itest_service is a binary that is intended to run for the duration of the int
48
50
| <aid="itest_service-health_check_args"></a>health_check_args | Arguments to pass to the health_check binary. The various defined ports will be substituted prior to being given to the health_check binary. | List of strings | optional | <code>[]</code> |
49
51
| <aid="itest_service-health_check_interval"></a>health_check_interval | The duration between each health check. The syntax is based on common time duration with a number, followed by the time unit. For example, <code>200ms</code>, <code>1s</code>, <code>2m</code>, <code>3h</code>, <code>4d</code>. | String | optional | <code>"200ms"</code> |
50
52
| <aid="itest_service-health_check_timeout"></a>health_check_timeout | The timeout to wait for the health check. The syntax is based on common time duration with a number, followed by the time unit. For example, <code>200ms</code>, <code>1s</code>, <code>2m</code>, <code>3h</code>, <code>4d</code>. If empty or not set, the health check will not have a timeout. | String | optional | <code>""</code> |
51
-
| <aid="itest_service-hot_reloadable"></a>hot_reloadable | If set to True, the service manager will propagate ibazel's reload notificaiton over stdin instead of restarting the service. See the ruleset docstring for more info on using ibazel | Boolean | optional | <code>False</code> |
53
+
| <aid="itest_service-hot_reloadable"></a>hot_reloadable | If set to True, the service manager will propagate ibazel's reload notification over stdin instead of restarting the service. See the ruleset docstring for more info on using ibazel | Boolean | optional | <code>False</code> |
52
54
| <aid="itest_service-http_health_check_address"></a>http_health_check_address | If set, the service manager will send an HTTP request to this address to check if the service came up in a healthy state. This check will be retried until it returns a 200 HTTP code. When used in conjunction with autoassigned ports, <code>$${@@//label/for:service:port_name}</code> can be used in the address. Example: <code>http_health_check_address = "http://127.0.0.1:$${@@//label/for:service:port_name}",</code> | String | optional | <code>""</code> |
53
55
| <aid="itest_service-named_ports"></a>named_ports | For each element of the list, the service manager will pick a free port and assign it to the service. The port's fully-qualified name is the service's fully-qualified label and the port name, separated by a colon. For example, a port assigned with <code>names_ports = ["http_port"]</code> will be assigned a fully-qualified name of <code>@@//label/for:service:http_port</code>.<br><br> Named ports are accessible through the service-port mapping. For more details, see <code>autoassign_port</code>. | List of strings | optional | <code>[]</code> |
54
56
| <aid="itest_service-so_reuseport_aware"></a>so_reuseport_aware | If set, the service manager will not release the autoassigned port. The service binary must use SO_REUSEPORT when binding it. This reduces the possibility of port collisions when running many service_tests in parallel, or when code binds port 0 without being aware of the port assignment mechanism.<br><br> Must only be set when autoassign_port is enabled. | Boolean | optional | <code>False</code> |
doc="The timeout to wait for the health check. The syntax is based on common time duration with a number, followed by the time unit. For example, `200ms`, `1s`, `2m`, `3h`, `4d`. If empty or not set, the health check will not have a timeout.",
230
230
),
231
231
"hot_reloadable": attr.bool(
232
-
doc="""If set to True, the service manager will propagate ibazel's reload notificaiton over stdin instead of restarting the service.
232
+
doc="""If set to True, the service manager will propagate ibazel's reload notification over stdin instead of restarting the service.
233
233
See the ruleset docstring for more info on using ibazel""",
This reduces the possibility of port collisions when running many service_tests in parallel, or when code binds port 0 without being
243
243
aware of the port assignment mechanism.
244
244
245
-
Must only be set when autoassign_port is enabled.""",
245
+
Must only be set when `autoassign_port` is enabled or `named_ports` are used.""",
246
246
),
247
247
}
248
248
249
249
itest_service=rule(
250
250
implementation=_itest_service_impl,
251
251
attrs=_itest_service_attrs,
252
252
executable=True,
253
-
doc="An itest_service is a binary that is intended to run for the duration of the integration test. Examples include databases, HTTP/RPC servers, queue consumers, external service mocks, etc.",
253
+
doc="""An itest_service is a binary that is intended to run for the duration of the integration test. Examples include databases, HTTP/RPC servers, queue consumers, external service mocks, etc.
254
+
255
+
All [common binary attributes](https://bazel.build/reference/be/common-definitions#common-attributes-binaries) are supported including `args`.""",
254
256
)
255
257
256
258
def_itest_task_impl(ctx):
@@ -262,8 +264,10 @@ itest_task = rule(
262
264
implementation=_itest_task_impl,
263
265
attrs=_itest_binary_attrs,
264
266
executable=True,
265
-
doc="""A task is a one-shot (not long-running binary) that is intended to be executed as part of the itest scenario creation.
266
-
Examples include: filesystem setup, dynamic config file generation (especially if it depends on ports), DB migrations or seed data creation""",
267
+
doc="""A task is a one-shot execution of a binary that is intended to run as part of the itest scenario creation.
268
+
Examples include: filesystem setup, dynamic config file generation (especially if it depends on ports), DB migrations or seed data creation.
269
+
270
+
All [common binary attributes](https://bazel.build/reference/be/common-definitions#common-attributes-binaries) are supported including `args`.""",
267
271
)
268
272
269
273
def_itest_service_group_impl(ctx):
@@ -302,7 +306,7 @@ itest_service_group = rule(
302
306
It serves as a convenient way for a downstream target to depend on multiple services with a single label, without
303
307
forcing the services within the group to define a specific startup ordering with their `deps`.
304
308
305
-
It is also useful to bring up multiple services with a single `bazel run` command, which is useful for creating
309
+
It can bring up multiple services with a single `bazel run` command, which is useful for creating
306
310
dev environments.""",
307
311
)
308
312
@@ -397,7 +401,9 @@ service_test(
397
401
)
398
402
```
399
403
400
-
Typically this would be wrapped into a macro.""",
404
+
Typically this would be wrapped into a macro.
405
+
406
+
All [common binary attributes](https://bazel.build/reference/be/common-definitions#common-attributes-binaries) are supported including `args`.""",
0 commit comments