jschoubben
950ebb9e28
Manifests for a provider and a consumer, so the contract can be read rather than only exercised through a lab fixture that stages the grants by hand. Checked as a pair rather than separately, because two manifests that only ever parse alone are two manifests nobody has held against each other. The test asserts the names match, that each side says where it wants to be told, and that the consumer contributes the key the provisioner actually reads. That last one is the trap worth having a test for: a consumer contributing "name" — which is exactly what a database consumer contributes — resolves cleanly, deploys, and then fails on the machine with "asked for a bucket and did not name it". Nothing in that message points back at the manifest that caused it. Both mistakes were made while writing these two files.
30 lines
815 B
JSON
30 lines
815 B
JSON
{
|
|
"module": "photos",
|
|
"version": "1",
|
|
|
|
"requires": ["s3-bucket"],
|
|
|
|
"contributes": {
|
|
"s3-bucket": {"bucket": "photos"}
|
|
},
|
|
|
|
"binds": {"s3-bucket": "/etc/photos/store.json"},
|
|
"secrets": {"s3-bucket": "/etc/photos/store.secret"},
|
|
|
|
"resources": [
|
|
{"id": "config", "type": "directory", "path": "/etc/photos", "mode": "0750"},
|
|
|
|
{"id": "app", "type": "container", "name": "photos",
|
|
"image": "photos@sha256:0000000000000000000000000000000000000000000000000000000000000000",
|
|
"env": {
|
|
"PHOTOS_STORE": "/etc/photos/store.json",
|
|
"PHOTOS_STORE_SECRET_FILE": "/etc/photos/store.secret"
|
|
},
|
|
"volumes": [
|
|
"/etc/photos/store.json:/etc/photos/store.json:ro",
|
|
"/etc/photos/store.secret:/etc/photos/store.secret:ro"
|
|
],
|
|
"restart-on": ["config"]}
|
|
]
|
|
}
|