chore: enforce that provisioners can only acquire jobs in their own organization #12600
Conversation
It should be made mandatory in the future
| Provisioner: database.ProvisionerTypeEcho, | ||
| StorageMethod: database.ProvisionerStorageMethodFile, | ||
| Type: database.ProvisionerJobTypeTemplateVersionDryRun, | ||
| OrganizationID: pd.OrganizationID, |
There was a problem hiding this comment.
There are a disturbingly large number of tests where we leave the OrgID unset while inserting a provisioner job, which seems like it should be forbidden by the foreign key constraint on the provisioner_jobs table. Unless, somehow, the all-zeros UUID "counts" as NULL by postgres when evaluating the foreign key, or there is an organization with all-zeros UUID being created in these tests.
I didn't see any instances of it not being set in product code, but it seems like database referential integrity is not working the way we want it to, which is worrying.
There was a problem hiding this comment.
I was fixing these 1 by 1, but it was incredibly annoying. So I added this to the dbgen, which is mostly used to generate jobs in tests:
coder/coderd/database/dbgen/dbgen.go
Lines 391 to 394 in a9774df
So by default, we use the org id
Closes: #11932
Organization ids were being correctly set on jobs already, just not used