theonedev/onedev · error · ExplicitException

Unable to access dependency build '" + dependencyBuild.getRe

Error message

Unable to access dependency build '" + dependencyBuild.getReference().toString(null) + "': permission denied

What it means

Thrown by DefaultJobService.doSubmit when a build declares a dependency build that the current login user is not permitted to access in the dependency's project (neither direct AccessProject permission on the dependency project nor an implied ProjectPermission via the authorization subject). OneDev requires the submitting user to be able to read every dependency build so agents and results cannot leak across projects. It surfaces as an ExplicitException attached to the build's failure message.

Source

Thrown at server-core/src/main/java/io/onedev/server/job/DefaultJobService.java:425

						throw new ExplicitException("Unable to access dependency project '"
								+ dependency.getProjectPath() + "': invalid access token");
					}
					subject = accessToken.asSubject();
				} else {
					subject = SecurityUtils.asAnonymous();
				}

				Build dependencyBuild = dependency.getBuildProvider().getBuild(dependencyProject);
				if (dependencyBuild == null) {
					String errorMessage = String.format("Unable to find dependency build in project '"
							+ dependencyProject.getPath() + "'");
					throw new ExplicitException(errorMessage);
				}

				AccessProject projectPermission = new AccessProject();
				if (!dependencyProject.isPermittedByLoginUser(projectPermission)
						&& !subject.isPermitted(new ProjectPermission(dependencyProject, projectPermission))) {
					throw new ExplicitException("Unable to access dependency build '"
							+ dependencyBuild.getReference().toString(null) + "': permission denied");
				}
				
				if (build.getDependencies().stream()
						.anyMatch(it -> it.getDependency().equals(dependencyBuild))) {
					throw new ExplicitException("Duplicate dependency build '"
							+ dependencyBuild.getReference().toString(null) + "'");
				}

				BuildDependence dependence = new BuildDependence();
				dependence.setDependency(dependencyBuild);
				dependence.setDependent(build);
				dependence.setArtifacts(dependency.getArtifacts());
				dependence.setDestinationPath(dependency.getDestinationPath());
				build.getDependencies().add(dependence);
			}

			buildService.create(build);

View on GitHub (pinned to d44925c47c)

Solutions

  1. Grant the submitting user (or the account running the pipeline) Read/Access permission on the project containing the dependency build.
  2. Remove the dependency from the job spec if the dependency is not truly needed.
  3. Reproduce the needed artifact within the same project or an accessible public project instead of cross-project dependency.
  4. If a service account runs the pipeline, add it to a group with access to the dependency project.

Example fix

// before (.onedev-buildspec.yml)
dependencies:
  - build: '@other-project@/builds/latest'

// after: grant the user Read permission on other-project,
// or remove the dependency:
dependencies: []
Defensive patterns

Strategy: validation

Validate before calling

// Java, before submitting
AccessProject p = new AccessProject();
if (!dependencyProject.isPermittedByLoginUser(p)
        && !SecurityUtils.getSubject().isPermitted(new ProjectPermission(dependencyProject, p))) {
    throw new ExplicitException("User cannot access dependency project " + dependencyProject.getPath());
}

Try / catch

try {
    jobService.submit(build);
} catch (ExplicitException e) {
    if (e.getMessage().contains("permission denied")) {
        // prompt user to request access to the dependency project
    }
}

Prevention

When it happens

Trigger: Calling jobService.submit (or adding a dependency via dependencyBuild) for a build whose build spec declares a dependency on a build in another project, while the current user lacks Read/AccessProject permission on that dependency's project.

Common situations: CI pipelines that depend on artifacts from a library project the developer cannot see; permission tightened recently on the dependency project; depending on builds in a private/forked project; service accounts running pipelines without membership in the dependency project.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors


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