backstage / backstage/community-plugins

jenkins-backend: any way to support jobs from different named instances on the same entity?

Open
#10,301 6 comments 0 reactions 1 assignee Claimed by @alvaroc20 View on GitHub
enhancement help wanted workspace/jenkins
Dominant language
TypeScript
Stars
422
Forks
697
Avg merge
2d 6h
Merged PRs (30d)
286

Description

### Workspace

jenkins

### 🔖 Feature description

Allow an entity's jenkins.io/job-full-name annotation to reference jobs from more than one named Jenkins instance, so a single component can show/trigger CI status across instances instead of being locked to just one.

### 🎤 Context

We run a few named Jenkins instances behind one Backstage (jenkins.instances[]) — say prod and dev to keep it generic. A project's jobs are genuinely spread across instances (some run on prod, others on dev), and we'd like one entity to reflect all of them.

Right now, listing jobs from more than one instance — jenkins.io/job-full-name: prod:jobX,dev:jobY — throws straight out of DefaultJenkinsInfoProvider.getInstance():

More than one Jenkins instance found: (prod,dev) on entity with name: ... Please use the same instance for all jobs.

That's not just an overzealous validation: getInstance() returns a single JenkinsInfo with one baseUrl and one set of auth headers for the whole fullJobNames list, so there's nowhere to hang per-job instance info even if the check were removed. The only workarounds we see today are forking the plugin or splitting the component into multiple catalog entities just to fake a unified view.

### ✌️ Possible Implementation

Not wedded to a specific approach, wanted to check direction before writing any code, but roughly:

- Keep the per-job instance prefix job-full-name already supports (instance:job), but instead of grouping jobs by instance and rejecting when more than one shows up, have the info provider return a per-instance breakdown (baseUrl + auth + its own job list) rather than one flat JenkinsInfo.
- Downstream consumers (build listing, the getBuild/getBuildLogs/triggerBuild actions, the CI/CD tab) would need to loop over that instead of assuming a single instance — probably the bulk of the work.

### 👀 Have you spent some time to check if this feature request has been raised before?

- [x] I checked and didn't find similar issue

### 🏢 Have you read the Code of Conduct?

- [x] I have read the [Code of Conduct](https://github.com/backstage/community-plugins/blob/main/CODE_OF_CONDUCT.md)

### Are you willing to submit PR?

None

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.