[Fixed JENKINS-23532] Search Folders when trying to find upstream project #108
Conversation
…e upstream project
dalvizu
changed the title
| * @param searchTerm - name of the item that is being looked for | ||
| * @return the project that matched the search term | ||
| */ | ||
| private AbstractProject<?, ?> traverseItemGroupHelper(ItemGroup groupToTraverse, String searchTerm) |
There was a problem hiding this comment.
There is a boundary case here where there can be a job with the same name (say, "Prod Commit") but in separate folders. This will always return the first folder to contain a job named "Prod Commit".
However this is also not where the issue is - we are able to correctly identify the upstream project and upstream build from the information the JS passes us
| LOGGER.fine("Downstream project names: " + downstreamProjectsNames); | ||
| // defect: requires full name in the trigger. But downstream is just fine! | ||
| if (downstreamProjectsNames.contains(project.getFullName())) { | ||
|
|
||
| if (downstreamProjectsNames.contains(project.getName())) { |
There was a problem hiding this comment.
The previous case is not the issue - we correctly identify the project by full name because we require build pipeline trigger to be specified by full name (well, before the change above). The problem is on line line 299 (line 350 in your branch) -- this assumes that the BuildTrigger config is also being specified by full name. This is not a safe assumption - it is in fact always going to be specified by a relative name (i.e admin-api/Prod Build/), which we compare to our full name and the mismatch happens
|
I do not think we want to allow projects to be specified by just their short project name -- this introduces cases where builds with the same name cannot be reliably chosen. The plugin today assumes a full name for a manual trigger, while automatic triggers assume a relative name. The bug we are trying to fix is that automatic trigger will never be found if it ever needs to be manually triggered on the first build (say after a restart or a re-run when history was erased) |
|
This is how BuildTrigger handles lookup - we will want to do the same - |
…e upstream project
| for (String currentDownstreamName : downstreamProjectsNames) { | ||
| final Job downstreamJob = (Job) Jenkins.getInstance().getItem(currentDownstreamName, | ||
| upstreamBuild.getProject().getParent(), Item.class); | ||
| if (downstreamJob != null && downstreamJob.getFullName().equals(project.getFullName())) { |
| view.setBuildCard(new StandardBuildCard()); | ||
| jenkins.buildAndAssertSuccess(upstreamProject); | ||
|
|
||
| view.triggerManualBuild(1, downstreamProject.getFullName(), upstreamProject.getFullName()); |
There was a problem hiding this comment.
Has upstream automatically started to build the downstream? And if so, does this mean that we are triggering a re-run and not a first-run, which had the problem we must reproduce? You can verify this by asserting null on the downstream project's latest build. If it has in fact started, a work-around would be to define the downstream project and configuration in the upstream project after the upstream has been run once.
| // /Folder1 | ||
| final String projUp = "upstream"; | ||
| folder1.createProject(FreeStyleProject.class, projUp); | ||
| //FreeStyleProject upstreamProject = (FreeStyleProject) folder1.getItem(projUp); |
[Fixed JENKINS-23532] Manually triggering build will now search other folders for the upstream project