[camielvs]

Human Words

Welcome to the top of the stack for the Workspaces x Secrets feature.

How it works

This stack builds on top of the Team Impersonation system to allow users to create Workspace-level secrets and execute Pipeline Runs using them.

Workspaces are now associated 1:1 with a Team and through a static config on the backend that Team grants basic roles to users based on their Team membership. Users with Team permissions are then able to create, edit and manage secrets on the entire Workspace, and add them to pipelines within that Workspace.

When a pipeline is submitted with a Workspace secret the initiating user must have team permissions. That Run will then be Attributed to the team and utilise its secrets. It is not possible to mix user-personal secrets and workspace secrets in one pipeline. Additionally, for runs that do not use secrets the user will have a choice of submitting as themselves or the team. It is also not possible to run a pipeline that uses Workspace secrets from outside of that Workspace.

Note: agents cannot use or read workspace secrets locally due to known tangent-shell limitations in the existing agent workflow.

Screenshots

Testing

1. Set up a Workspace with a team id you have permissions in
2. Create a project in the workspace
3. You should now see a new window for "Workspace Secrets"
4. Confirm you can add/edit/delete workspace secrets
5. Make a pipeline inside the Project
6. Confirm you can add the Workspace secrets to the pipeline and run it

Agent Words

Description

A run's team is the team of the projects it's filed under, read from its annotations by the new useRunTeam. The run page now uses it in three places.

• Cancel and run notes. The backend only lets a run's creator annotate it, and only its creator or someone with wider rights, such as an admin, cancel it. A run the team created can now be cancelled, and its notes edited, by a member who can write to the team, and both requests carry the team header. A run you created keeps working as before, without the header, even when it's filed under a team's project. The rule lives in runManagement.
• Rerun. A rerun keeps the identity of the run it repeats. A run the team created reruns as the team, straight away, so its secrets resolve the same way. Someone who can't act as the team, because they aren't in it or can't impersonate it, can't rerun it: the rerun button and the run menus are disabled and say why. Any other run reruns by the same rule as a submit (feat(runs): submit as yourself or as the project's team #2943): as you, unless only the team has a secret it uses. A rerun whose arguments use secrets missing for whoever it goes as, or whose secrets are split, asks first, says why and offers the same Run as choice. Rerun waits for the team and the secrets check, and is refused for projects on different teams. When the run's team can't be checked, only the run's creator can rerun it.
• One rerun implementation. The rerun button and the run menus had two copies of the rerun logic. The button now uses the menus' useRerunPipelineRun, so the team rules live in one place. The button's unused runId prop is gone.

Cancel and annotation failures now show the backend's reason instead of "Access denied (403)". They read the response the way creating a run does. As before, a request a sign-in redirect intercepted fails rather than passing for a success. A failed notes save used to be silent and now shows a toast.

useTeamForRunAnnotations (#2929) had no callers. useRunTeam replaces it, and also waits for the annotations and reports when they can't be read. Without the team header configured, it's none straight away and reads no annotations, so cancel, notes and rerun behave as on master.

Related Issue and Pull requests

• Stacked on feat(runs): submit as yourself or as the project's team #2943.
• Closes the follow-up noted in feat(runs): submit and manage runs as a team #2929 about fetchWithErrorHandling dropping the backend's detail.

Type of Change

• New feature
• Cleanup/Refactor

Line Breakdown

Category	Added	Removed
Production code	365	168
Comments	0	1
Tests	808	37
Config / CI / tooling	2	0
Total	1175	206

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Screenshots (if applicable)

None yet.

Test Instructions

pnpm vitest run src/components/PipelineRun src/routes/v2/pages/RunView src/services/teams src/services/pipelineRunService.test.ts

With the same setup as #2941, open a run submitted as the team (#2943):

1. While it runs, cancel it from the Run menu or the Run Tools window. The cancel goes through.
2. Edit its run notes in Details. They save.
3. When it's done, rerun it. The new run's "Created by" is the team's id.
4. Open the same run as someone outside the team, or as a member who can't act as it. There's no cancel, the notes are read-only, and Rerun is disabled, saying "Only someone who can act as the workspace can rerun it."
5. Open a run you submitted yourself. It behaves as on master.

Additional Comments

• The v1 run page (RunToolbar, RunDetails) isn't routed. It only picks up the shared rerun button.
• RerunBlockedReason and RerunReviewDialog are added to react-compiler.config.js.

🤖 Generated with Claude Code

[github-actions]

🎩 Preview

A preview build has been created at: cvs/team-run-page/d6f8ee7