Secrets and variables kept from before stay with workflows
Migration 0003 gave existing rows the new default, workflows and deployments, which would have handed every workflow secret to deploy builds and apps. They stay workflows-only; new rows still default to both.
1 file+5−40/1 viewed
| 2 | 2 | -- are: each row is a key, its type (secret or config), the environments it | |
| 3 | 3 | -- applies to and who reads it. A key may have one row per environment, so | |
| 4 | 4 | -- the unique (owner, kind, name) constraint goes; the service keeps a | |
| 5 | − | -- key's rows from overlapping. Existing rows keep working as before: every | |
| 6 | − | -- environment, read by workflows and deployments. | |
| 5 | + | -- key's rows from overlapping. Existing rows keep working exactly as before: | |
| 6 | + | -- every environment, read by workflows alone, so nothing reaches | |
| 7 | + | -- deployments until someone says it should. | |
| 7 | 8 | ||
| 8 | 9 | CREATE TABLE settings_v2 ( | |
| 9 | 10 | id TEXT PRIMARY KEY, | |
| 31 | 32 | updated_by TEXT | |
| 32 | 33 | ); | |
| 33 | 34 | ||
| 34 | − | INSERT INTO settings_v2 (id, scope, owner, kind, name, value, updated_at) | |
| 35 | − | SELECT id, scope, owner, kind, name, value, updated_at FROM settings; | |
| 35 | + | INSERT INTO settings_v2 (id, scope, owner, kind, name, value, updated_at, available_to) | |
| 36 | + | SELECT id, scope, owner, kind, name, value, updated_at, 'workflows' FROM settings; | |
| 36 | 37 | DROP TABLE settings; | |
| 37 | 38 | ALTER TABLE settings_v2 RENAME TO settings; | |
| 38 | 39 | CREATE INDEX settings_by_owner ON settings (owner, name); |