Use one of two paths. Create the runners in the destination organization, or ask Support to transfer the namespace. Both paths need a new resource-class token and a redeploy. They differ in which organization owns the namespace, and in whether both fleets can run at the same time.
The text before the slash is the namespace. A resource class such as my-namespace/linux belongs to the organization that owns my-namespace. An organization owns one namespace. By convention the namespace matches the organization name, but a match is not required.
CircleCI shows a resource-class token once, at creation, and stores a hash of that value. Each path below starts with a new token. A personal API token for the CircleCI CLI is a separate credential. Neither path changes it.
Create the runners in the destination organization
Use this path when the destination organization has its own namespace. The source namespace stays on the source organization. Both fleets can run together, because the resource class names differ.
Create the resource class under the destination organization's namespace.
Create a resource-class token and save the value.
Point
.circleci/config.ymlatdestination-namespace/linux.Install that token on the runner, using the Container Runner or Machine Runner steps below.
Run a pipeline in the destination organization and confirm the new runner claims the job.
Drain the source runners. Delete their tokens, then delete the source resource classes.
Transfer the namespace
Use this path when the destination organization must own the existing namespace name, including the orbs in that namespace. Support performs the transfer. An organization admin on each organization approves the request. The destination organization must not already own a namespace.
Create a new runner token after the transfer, and install it on the runner. The transfer gives the destination organization the namespace name. It leaves the resource class on the source organization, so the previous token cannot claim jobs there. After Support finishes the transfer:
Delete every token on the source resource class, then delete the class. The name is unique, so the destination organization can create it only after that delete.
Create the resource class again under the transferred namespace.
Create a new resource-class token and save the value.
Install that token on the runner, using the steps below.
Run a pipeline in the destination organization and confirm the runner claims the job.
Until that new class exists, a job that still names the old resource class stops with this error:
We cannot run this job using the selected resource class.
This path has a gap for that resource class name. The two organizations cannot claim the same my-namespace/linux at the same time. To avoid that gap, use the first path and keep the source namespace in place until the destination runners are claiming jobs.
Install the new token
Container Runner
Set the new token on the Helm release, then upgrade. The chart reads tokens from agent.resourceClasses, or from the secret named by agent.customSecret.
agent:
resourceClasses:
destination-namespace/linux:
token: In a custom secret, use a period in place of the slash. The key destination-namespace.linux matches the resource class in the chart. Upgrading the release rolls the agent. On the first path, add the destination class beside the source class, or install a second Helm release, so the source fleet stays up.
Machine Runner
Replace api.auth_token in the machine runner configuration with the new token, or set CIRCLECI_RUNNER_API_AUTH_TOKEN. Restart the runner process so it loads the new value. On the first path, run a second machine runner for the destination resource class until you drain the source runner.
Commands
circleci runner token create circleci runner token list circleci runner token delete circleci runner resource-class delete