Block options

Every block supports options from the config.jsonfile in the block's directory

Which options are supported is defined by block's implementation. If you are building a custom block, consider exposing the most commonly used configurations as options.

Example of options supported by the standard container block:

{
    "target": "diggerhq/target-ecs-module@dev",
    "task_memory": 512,
    "task_cpu": 256,
    "container_port": 8000,
    "load_balancer": true,
    "internal": false,
    "health_check": "/",
    "health_check_matcher": "200-499",
    "launch_type": "FARGATE",
    "monitoring_enabled": false,
    "lb_monitoring_enabled": false
}

TODO: separate target from other options. Changing the target may completely change the list of supported options, so it doesn't belong in the same list as other options.

TODO: consider moving port and health-check to application-facing config. We haven't yet figured what such config should look like, or whether it should even be separate. The intuition is that it might need to be separate because it is of developer's concern rather than platform / infra and will be owned by different people, especially in larger teams.