Type: Enhancement
Affected Version: 16.8.6
Priority: Normal

Problem

We use a centralized project to maintain reusable CI/CD jobs, which are imported into multiple application projects through .onedev-buildspec.yml.

However, imported jobs cannot be manually executed from the project's Builds page. Attempting to run them results in a "Job not found" error.

These jobs are available and can be executed from Code → Files or Code → Commits.

Use Case

Our development workflow separates developers and testers:

• Developers have code read access and can manage CI/CD configurations.
• Testers only have permissions to view and execute builds, along with managing issues.
• Testers do not have code read permission for security reasons.
• CI/CD jobs are centrally maintained and imported by application projects.

Currently, testers cannot manually trigger imported build jobs from the Builds page.

As a workaround, we must either:

1. Let testers use artifacts generated by automatically triggered builds.
2. Duplicate the same job definition in every application project.

The second option defeats the purpose of centralized CI/CD job management and introduces unnecessary maintenance overhead.

Expected Behavior

1. The Builds page should recognize all available jobs, including those imported from other projects.
2. Users with build execution permission should be able to manually run imported jobs without requiring code read permission.
3. Imported jobs should behave the same as locally defined jobs when manually triggered.
4. Job visibility and execution should respect the existing build permissions without exposing source code or sensitive CI/CD configurations.

Actual Behavior

• Imported jobs work from Code → Files / Commits.
• Imported jobs cannot be manually started from Builds.
• The interface reports "Job not found".
• Testers without code read permission cannot access the alternative execution entry points.

Suggested Improvement

Please allow the Builds page to discover and execute imported jobs based on the selected branch or commit, while maintaining the existing permission model.

This would make centralized CI/CD job management practical for teams that separate development and testing responsibilities.