theonedev/onedev · error · ExplicitException

Specified workspace provisioner '${provisioner}' is disabled

Error message

Specified workspace provisioner '${provisioner}' is disabled

What it means

When a workspace spec explicitly names a provisioner (spec.getProvisioner()), DefaultWorkspaceService looks it up among configured workspace provisioners and checks it is enabled. A provisioner found by name but with isEnabled()==false throws ExplicitException — the named provisioner is intentionally disabled in settings.

Source

Thrown at server-core/src/main/java/io/onedev/server/workspace/DefaultWorkspaceService.java:742

		for (var discoverer : discoverers) {
			WorkspaceProvisioner provisioner = discoverer.discover();
			if (provisioner != null) {
				provisioner.setName(AUTO_DISCOVERED_PROVISIONER_NAME);
				if (isApplicable(workspace, spec, provisioner))
					return provisioner;
			}
		}
		return null;
	}

	private WorkspaceProvisioner getProvisioner(Workspace workspace, WorkspaceSpec spec, TaskLogger logger) {
		if (spec.getProvisioner() != null) {
			var provisioner = settingService.getWorkspaceProvisioners().stream()
				.filter(it -> it.getName().equals(spec.getProvisioner()))
				.findFirst()
				.orElseThrow(() -> new ExplicitException("Unable to find specified workspace provisioner '" + spec.getProvisioner() + "'"));
			if (!provisioner.isEnabled())
				throw new ExplicitException("Specified workspace provisioner '" + spec.getProvisioner() + "' is disabled");
			else if (!isApplicable(workspace, spec, provisioner))
				throw new ExplicitException("Specified workspace provisioner '" + spec.getProvisioner() + "' is not applicable for current workspace");
			else
				return provisioner;
		} else if (!settingService.getWorkspaceProvisioners().isEmpty()) {
			return settingService.getWorkspaceProvisioners().stream()
				.filter(it -> it.isEnabled() && isApplicable(workspace, spec, it))
				.findFirst()
				.orElseThrow(() -> new ExplicitException("No applicable workspace provisioner"));
		} else {
			logger.log("No workspace provisioner defined, auto-discovering...");
			var provisioner = discoverProvisioner(workspace, spec);
			if (provisioner != null) {
				logger.log("Discovered " + EditableUtils.getDisplayName(provisioner.getClass()).toLowerCase());
				return provisioner;
			}

			if (spec.isRunInContainer()) {

View on GitHub (pinned to d44925c47c)

Solutions

Enable the named provisioner in Administration > Workspace Provisioners.
Or change the job's workspace spec to use an enabled provisioner.
Or remove the explicit provisioner name so auto-discovery picks an applicable enabled one.

Example fix

// before (job YAML)
provisioner: k8s-pool   # disabled in admin settings
// after
provisioner: docker-pool  # or omit to auto-discover

Defensive patterns

Strategy: validation

Validate before calling

// via API: GET workspace provisioners settings; assert named provisioner exists and isEnabled()

Try / catch

try { provision(...); } catch (ExplicitException e) { if (e.getMessage().contains("is disabled")) { /* re-enable or switch provisioner */ } }

Prevention

Keep CI configs and admin provisioner settings in sync.
Audit provisioner enabled state after maintenance windows.
Avoid hardcoding provisioner names when auto-discovery suffices.

When it happens

Trigger: A job/workspace spec sets provisioner: '<name>' while that provisioner exists in Administration > Workspace Provisioners but is disabled.

Common situations: Admin disabled a provisioner temporarily (e.g. k8s outage) while CI configs still reference it; copying job YAML between servers where one has the provisioner disabled; forgetting to re-enable after maintenance.

Related errors

AI-assisted analysis of theonedev/onedev@d44925c47c (2026-09-06). Data as JSON: /api/errors/5e7bddcc006f0b81. Report an issue: GitHub.