Adding parent-child job support to the pipeline job.#92
Adding parent-child job support to the pipeline job.#92francisf merged 16 commits intojenkinsci:masterfrom
Conversation
| apiUtil.logToQD(browserStackCredentials, "Finally no artifacts found for jobName: " + jobName + " and buildNumber: " + buildNumber); | ||
| } | ||
| sendBuildDataToQD(run, overallResult, qdS3Url, browserStackCredentials); | ||
| processArtifactsAndSendData(run, overallResult, browserStackCredentials, jobName, buildNumber); |
There was a problem hiding this comment.
Just for clean code.
String jobName = getJobNameFromRun(run, browserStackCredentials);
int buildNumber = run.getNumber();
These 2 lines can be moved inside processArtifactsAndSendData since we are already passing run object to the method.
There was a problem hiding this comment.
Actually, the build name is needed to check whether the pipeline is enabled. Based on that, we call the processArtifactsAndSendData function. The build number is used to improve logging and help uniquely identify the run in the try-catch block.
| * @param browserStackCredentials The credentials required for logging | ||
| * @param message The error message to log | ||
| */ | ||
| private static void logError(BrowserStackCredentials browserStackCredentials, String message) { |
There was a problem hiding this comment.
looks like wrapper over a wrapper. any specific reason of creating this?
There was a problem hiding this comment.
We handle error logging this way to avoid declaring throws JsonProcessingException in every function. Otherwise, we would also need to add extra try-catch blocks at the top level just to log the error when calling the Upstream resolver methods(as seen in QualityDashboardPipelineTracker.java, lines 53–57). This approach reduces repetition and keeps error logging centralized in UpStreamResolver.
| if (cause instanceof Cause.UpstreamCause) { | ||
| return handleUpstreamCause((Cause.UpstreamCause) cause, browserStackCredentials, visitedProjects); | ||
| } else if (cause instanceof hudson.triggers.TimerTrigger.TimerTriggerCause) { | ||
| apiUtil.logToQD(browserStackCredentials, "Build triggered by timer/schedule"); |
There was a problem hiding this comment.
should we just log it on Jenkins side? is this log useful for debugging on server side?
| public static final String QEI_DEFAULT_URL = "https://quality-engineering-insights.browserstack.com"; | ||
| public static String host = QEI_DEFAULT_URL; | ||
| // Cache configuration | ||
| public static final long CACHE_DURATION_MS = 60 * 60 * 1000L; // 1 hour in milliseconds |
There was a problem hiding this comment.
Ok for now but ideally it should be configurable either on client side or server side.
There was a problem hiding this comment.
Noted. As discussed, we will handle this in the future.
agrawalsaurabhs
left a comment
There was a problem hiding this comment.
LGTM! clean code, nicely done.
minor comments added.
karanshah-browserstack
left a comment
There was a problem hiding this comment.
All file changes, except those in common, fall under QD’s ownership, an internal review within QD should be sufficient. Also, can we update the CODEOWNERS file to reflect QD as the owner for these files? I won’t be able to review them as I don’t have enough context.
| } catch (JsonProcessingException e) { | ||
| // Handling the exception and logging an error | ||
| System.err.println("Error processing JSON for job: " + job.getName()); | ||
| LOGGER.info("Error processing JSON for job: " + job.getName() + " - " + e.getMessage()); |
There was a problem hiding this comment.
These should be logger error right? And till will also be displayed to user correct?
There was a problem hiding this comment.
@karanshah-browserstack , yes, the user will be able to see it in the Jenkins System Log. I've changed it to a warning in all places.
| apiUtil.logToQD(browserStackCredentials, "Issue getting Jenkins Instance"); | ||
| } catch (JsonProcessingException e) { | ||
| System.err.println("Error logging issue with Jenkins instance."); | ||
| LOGGER.info("Error logging issue with Jenkins instance."); |
There was a problem hiding this comment.
same error Logger comment as above for all logger related changes
…supporting job and folder item type handling on rename and deletion.
|
@karanshah-browserstack , we’ll review and update the CODEOWNERS for QD related files. |
| apiUtil.logToQD(browserStackCredentials, "Issue getting Jenkins Instance"); | ||
| } catch (JsonProcessingException e) { | ||
| LOGGER.info("Error logging issue with Jenkins instance."); | ||
| LOGGER.warning("Error logging issue with Jenkins instance."); |
There was a problem hiding this comment.
Shouldn't this be error?
There was a problem hiding this comment.
@karanshah-browserstack, We are logging this as a warning instead of an error because the logs appear on the user's Jenkins system. We want to avoid showing error logs to the user.
Testing done
Submitter checklist