fix(server): process runs with project account

What

This changes the build and test run creation endpoints to attach the selected project’s account to the run params instead of the authenticated user’s account. It also adds regression coverage for organization-owned projects so the processing workers are enqueued with the organization account and the storage key under that organization/project namespace.

Why

The upload routes already resolve storage through the selected project’s account. The create/enqueue path needs to preserve that same account context so server-side processing reads artifacts from the same storage backend that received them.

Root Cause

For organization projects, the authenticated subject can be a user whose personal account differs from the project’s owning account. The build/test create endpoints were using that authenticated subject account when creating the run params.

That account id then flowed into processing worker args, which meant workers could resolve storage through the wrong account backend even though the artifacts had been uploaded through the project owner’s storage backend.

Approach

Both create endpoints now use selected_project.account, matching the upload routes and keeping the account context consistent from upload through processing. The regression tests simulate a user creating processing runs for an organization-owned project and assert that both the create attrs and worker args use the organization account.

Impact

New build and test runs for organization projects with account-specific storage should process against the same account-backed storage where their artifacts were uploaded. Existing failed-processing runs may still need a retry or requeue after deploy.

Validation

• Ran mix format on the touched files.
• Ran focused controller coverage:
  • mix test test/tuist_web/controllers/api/builds_controller_test.exs test/tuist_web/controllers/api/tests_controller_test.exs
  • Result: 46 tests, 0 failures

No GitHub comments yet.