[CI] issue: 4705805 Add Blackduck to release job #1143
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
Integrated Blackduck security scanning into the LibVMA release pipeline as an optional step controlled by the do_blackduck parameter (default: false).
Key changes:
- Added
do_blackduckboolean parameter to release job configuration - Configured credentials for Blackduck API token and SSH key access
- Added blackduck docker container definition with
bducktarget - Created new Blackduck step that clones scanning tools and runs signature scan
- Archives scan logs and PDF reports as build artifacts
Notes:
- Redundant if-check exists within Blackduck step (already controlled by
enabledirective) - All required infrastructure (
.ci/blackduck_source.sh, Dockerfile bduck target) is present - Step executes after release build completes
Confidence Score: 4/5
- This PR is safe to merge with minimal risk - adds optional CI scanning without affecting existing release workflow
- Score reflects well-structured integration with proper credentials management and optional execution. Minor style improvement suggested for redundant conditional check, but no functional issues present.
- No files require special attention - changes are straightforward CI configuration additions
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | Added optional do_blackduck boolean parameter (default: false) to control Blackduck scanning |
| .ci/pipeline/release_matrix_job.yaml | 4/5 | Added Blackduck integration: credentials, docker container, and step with conditional execution and redundant if-check |
Sequence Diagram
sequenceDiagram
participant User
participant Jenkins
participant ReleaseStep
participant BlackduckStep
participant BlackduckServer
User->>Jenkins: Trigger release job with do_blackduck parameter
Jenkins->>Jenkins: Load credentials (SSH key, Blackduck API token)
Jenkins->>ReleaseStep: Execute in rhel8.6 container
ReleaseStep->>ReleaseStep: Run .ci/do_release.sh
ReleaseStep->>Jenkins: Archive build logs and RPM packages
alt do_blackduck == true
Jenkins->>BlackduckStep: Execute in blackduck container
BlackduckStep->>BlackduckStep: Clone blackduck tools repo
BlackduckStep->>BlackduckServer: Authenticate with API token
BlackduckStep->>BlackduckServer: Run signature scan
BlackduckServer->>BlackduckStep: Return scan results
BlackduckStep->>Jenkins: Archive logs and PDF report
else do_blackduck == false
Jenkins->>Jenkins: Skip Blackduck step
end
Jenkins->>User: Send notification email with results
2 files reviewed, 1 comment
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
ba424fd to
dfdbd84
Compare
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
Added optional Blackduck security scanning to the release pipeline by introducing a new boolean parameter do_blackduck (defaults to false) and a dedicated pipeline step.
Key Changes:
- New parameter in
release_jjb.yamlallows users to opt-in to Blackduck scanning - Blackduck step runs in dedicated container with required credentials and tools
- Conditional execution via
enable: ${do_blackduck}ensures step only runs when requested - Archives scan logs and PDF reports for security review
- Release step now explicitly specifies container selector for clarity
Integration:
The Blackduck step executes .ci/blackduck_source.sh which clones scanning tools, authenticates with the Blackduck server, and runs signature-based security scans on the source code. Results are archived as artifacts for compliance tracking.
Confidence Score: 4/5
- Safe to merge - adds optional CI feature with minimal risk to existing release process
- The changes are well-isolated and non-breaking since
do_blackduckdefaults to false. The implementation follows existing patterns in the pipeline. Minor issue: one credential may be unused due to hardcoded SSH key path in the script. .ci/pipeline/release_matrix_job.yaml- verify SSH credential usage aligns with script implementation
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | Added do_blackduck boolean parameter to control Blackduck scanning execution - straightforward addition with no issues |
| .ci/pipeline/release_matrix_job.yaml | 4/5 | Added Blackduck step with credentials, container config, and conditional execution - includes unused credential binding |
Sequence Diagram
sequenceDiagram
participant User
participant Jenkins
participant ReleaseContainer as Release Container (rhel8.6)
participant BlackduckContainer as Blackduck Container (bduck)
participant BlackduckServer as Blackduck Server
participant GitRepo as Git Repository (DevOps/Tools/blackduck)
participant ArtifactStore as Artifact Storage
User->>Jenkins: Trigger release job with parameters
Note over User,Jenkins: do_blackduck=true/false<br/>release_tag, revision, etc.
Jenkins->>Jenkins: Load credentials<br/>(SSH key, Blackduck API token)
Jenkins->>ReleaseContainer: Start Release step
ReleaseContainer->>ReleaseContainer: Execute .ci/do_release.sh
ReleaseContainer->>ArtifactStore: Archive build logs & RPM packages
alt do_blackduck == true
Jenkins->>BlackduckContainer: Start Blackduck step
BlackduckContainer->>BlackduckContainer: Validate WORKSPACE & BLACKDUCK_API_TOKEN
BlackduckContainer->>BlackduckContainer: Create JSON auth config
BlackduckContainer->>GitRepo: Clone blackduck tools via SSH
BlackduckContainer->>BlackduckContainer: Run ./run_bd_scan.sh signature
BlackduckContainer->>BlackduckServer: Perform security scan
BlackduckServer-->>BlackduckContainer: Return scan results
BlackduckContainer->>BlackduckContainer: Generate logs & PDF report
BlackduckContainer->>ArtifactStore: Archive logs/ directory
else do_blackduck == false
Note over Jenkins,BlackduckContainer: Blackduck step skipped
end
Jenkins->>User: Send email notification with results
Additional Comments (1)
-
.ci/pipeline/release_matrix_job.yaml, line 28 (link)style: The script
.ci/blackduck_source.shuses hardcoded SSH key path~/.ssh/id_ed25519instead of theGERRIT_SSH_KEYenvironment variable. Either update the script to use$GERRIT_SSH_KEYor this credential binding is unnecessary.
2 files reviewed, 1 comment
Author
|
bot:retest |
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
dfdbd84 to
6e6338c
Compare
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
Integrated Blackduck security scanning into the release pipeline as an optional step controlled by the do_blackduck parameter (defaults to false).
Key changes:
- Added
do_blackduckboolean parameter inrelease_jjb.yamlto enable/disable Blackduck scanning - Configured Blackduck step in
release_matrix_job.yamlwith dedicated container, credentials, and script execution - Added
failFast: trueto stop pipeline immediately on failure - Configured Blackduck-specific credentials (
blackduck_api_tokenandswx-jenkins2-svc-gerrit-ssh-key) for authentication - Integrated with existing
.ci/blackduck_source.shscript that clones Blackduck tools and performs source code scanning
Minor issues:
- Redundant credential declarations at step level (already defined globally)
- Previous comment noted redundant if-check in script (line 60) since
enable: ${do_blackduck}controls execution
Confidence Score: 4/5
- This PR is safe to merge with minor style improvements recommended
- The changes follow established patterns from the recent antivirus integration (commit 2e7eb28), properly configure credentials and containers, and integrate with existing infrastructure. The
failFast: trueaddition appropriately stops execution on critical failures. Score is 4 instead of 5 due to redundant credential declarations at the step level that could be cleaned up for better maintainability - No files require special attention - changes are straightforward CI configuration updates
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | Added do_blackduck boolean parameter to control Blackduck execution - straightforward change |
| .ci/pipeline/release_matrix_job.yaml | 4/5 | Added Blackduck step with credentials, docker config, and failFast: true setting - credentials are duplicated at both global and step levels |
Sequence Diagram
sequenceDiagram
participant JJB as Jenkins Job Builder
participant Pipeline as Release Pipeline
participant ReleaseContainer as RHEL8.6 Container
participant BlackduckContainer as Blackduck Container
participant BlackduckServer as Blackduck Server
participant Artifacts as Artifact Storage
JJB->>Pipeline: Trigger release with do_blackduck param
Pipeline->>Pipeline: Load release_matrix_job.yaml config
Pipeline->>ReleaseContainer: Execute Release step
ReleaseContainer->>ReleaseContainer: Run .ci/do_release.sh
ReleaseContainer->>Artifacts: Archive build logs and RPMs
alt do_blackduck=true
Pipeline->>BlackduckContainer: Execute Blackduck step
BlackduckContainer->>BlackduckContainer: Load BLACKDUCK_API_TOKEN credential
BlackduckContainer->>BlackduckContainer: Load GERRIT_SSH_KEY credential
BlackduckContainer->>BlackduckContainer: Run .ci/blackduck_source.sh
BlackduckContainer->>BlackduckContainer: Clone blackduck tools repo via SSH
BlackduckContainer->>BlackduckContainer: Execute run_bd_scan.sh signature
BlackduckContainer->>BlackduckServer: Scan source code and upload results
BlackduckServer-->>BlackduckContainer: Return scan results
BlackduckContainer->>Artifacts: Archive scan logs and PDF report
else do_blackduck=false
Pipeline->>Pipeline: Skip Blackduck step
end
Pipeline->>Pipeline: Complete release process
2 files reviewed, 1 comment
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
6e6338c to
74e62d1
Compare
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
This PR integrates Blackduck security scanning into the LibVMA release pipeline. A new optional boolean parameter do_blackduck (default: false) was added to control whether the Blackduck scan runs during releases.
Key Changes:
- Added
do_blackduckparameter to Jenkins job configuration - Configured Blackduck credentials (API token and SSH key) at the global level
- Added new Blackduck container configuration using existing Dockerfile target
- Created conditional Blackduck step that executes
.ci/blackduck_source.shwhen enabled - Added
failFast: trueto stop pipeline on first failure - Added explicit
containerSelectorto Release step for consistency
Integration Details:
The Blackduck step runs in a separate container after the release build, clones the Blackduck tools repository, performs a signature scan, and archives the resulting logs and PDF reports. The scan is gated by the do_blackduck parameter, allowing teams to enable it selectively.
Confidence Score: 5/5
- This PR is safe to merge - it adds optional security scanning functionality without affecting existing release workflows
- The changes are well-isolated and non-breaking: Blackduck integration is opt-in (default: false), runs in a separate container after the main release step, and leverages existing infrastructure (script and Dockerfile already in repo). The implementation follows the existing CI patterns, properly configures credentials, and includes appropriate error handling
- No files require special attention - both configuration files have straightforward, isolated changes
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | Added do_blackduck boolean parameter (default: false) to control Blackduck execution |
| .ci/pipeline/release_matrix_job.yaml | 4/5 | Added Blackduck step with credentials, container config, and script execution; enabled failFast and added containerSelector to Release step |
Sequence Diagram
sequenceDiagram
participant User
participant Jenkins
participant JenkinsJob as Jenkins Job Config
participant Matrix as Matrix Pipeline
participant ReleaseContainer as RHEL 8.6 Release Container
participant BlackduckContainer as Blackduck Container
participant BlackduckServer as Blackduck Server
User->>Jenkins: Trigger release job with do_blackduck param
Jenkins->>JenkinsJob: Load release_jjb.yaml config
JenkinsJob->>Matrix: Load release_matrix_job.yaml
Matrix->>Matrix: Setup credentials (SSH key, Blackduck API token)
Matrix->>Matrix: Build/pull container images
par Release Step
Matrix->>ReleaseContainer: Execute Release step
ReleaseContainer->>ReleaseContainer: Run .ci/do_release.sh
ReleaseContainer->>Matrix: Archive build logs and RPM packages
end
alt do_blackduck == true
Matrix->>BlackduckContainer: Execute Blackduck step
BlackduckContainer->>BlackduckContainer: Run .ci/blackduck_source.sh
BlackduckContainer->>BlackduckContainer: Clone blackduck tools repo
BlackduckContainer->>BlackduckServer: Run signature scan via run_bd_scan.sh
BlackduckServer-->>BlackduckContainer: Return scan results
BlackduckContainer->>BlackduckContainer: Generate PDF report
BlackduckContainer->>Matrix: Archive logs and PDF report
end
Matrix->>User: Send notification email with build status
2 files reviewed, no comments
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
74e62d1 to
bf91ef6
Compare
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
Added Blackduck security scanning integration to the release pipeline. The changes introduce a new boolean parameter do_blackduck (default: false) to control execution, along with necessary credentials and a dedicated Docker container for running scans.
Key changes:
- New
do_blackduckparameter in JJB configuration with default false - Added
failFast: trueto pipeline configuration - Configured two credentials:
swx-jenkins2-svc-gerrit-ssh-key(SSH key) andblackduck_api_token(API token) - Added containerSelector to Release step (previously missing)
- New Blackduck step that runs
.ci/blackduck_source.shin dedicated container - New blackduck Docker image definition using rhel8.6 base with bduck target
Critical issue identified:
The Blackduck step's SSH key setup appears broken - the script tries to use ~/.ssh/id_ed25519 but the GERRIT_SSH_KEY credential (which provides the key via file path) is never copied or referenced in the git clone command at .ci/blackduck_source.sh:28.
Confidence Score: 2/5
- Not safe to merge - the Blackduck step will fail at runtime due to SSH authentication issues
- While the parameter and credential setup are correct, there's a critical logic error where the SSH key credential is defined but never actually used in the script - the git clone command hardcodes
~/.ssh/id_ed25519without setting it up from$GERRIT_SSH_KEY. This will cause authentication failures whendo_blackduck=true. Since the default is false, existing workflows won't break, but the new feature won't work when enabled. .ci/pipeline/release_matrix_job.yaml- SSH key setup needs to reference the credential properly, and.ci/blackduck_source.sh- git clone command needs to use$GERRIT_SSH_KEYinstead of hardcoded path
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | Added do_blackduck boolean parameter with default false - straightforward and safe |
| .ci/pipeline/release_matrix_job.yaml | 3/5 | Added Blackduck integration with credentials and Docker container, but SSH key setup may not work correctly at runtime |
Sequence Diagram
sequenceDiagram
participant User
participant Jenkins
participant ReleaseStep
participant BlackduckStep
participant BlackduckDocker
participant GitServer
participant BlackduckServer
User->>Jenkins: Trigger release job with do_blackduck=true
Jenkins->>Jenkins: Load credentials (BLACKDUCK_API_TOKEN, GERRIT_SSH_KEY)
Jenkins->>ReleaseStep: Execute Release step
ReleaseStep->>ReleaseStep: Run .ci/do_release.sh
ReleaseStep-->>Jenkins: Archive packages
alt do_blackduck enabled
Jenkins->>BlackduckDocker: Start blackduck container
BlackduckDocker->>BlackduckDocker: Mount volumes & inject credentials
Jenkins->>BlackduckStep: Execute Blackduck step
BlackduckStep->>BlackduckStep: Validate WORKSPACE & BLACKDUCK_API_TOKEN
BlackduckStep->>BlackduckStep: Create JSON config for Blackduck
BlackduckStep->>GitServer: git clone blackduck tools repo via SSH
Note over BlackduckStep,GitServer: Uses ~/.ssh/id_ed25519<br/>(may fail if key not set up)
GitServer-->>BlackduckStep: Clone complete
BlackduckStep->>BlackduckStep: Run run_bd_scan.sh signature
BlackduckStep->>BlackduckServer: Scan source code
BlackduckServer-->>BlackduckStep: Scan results
BlackduckStep->>BlackduckStep: Generate reports (PDF, logs)
BlackduckStep-->>Jenkins: Archive logs/ directory
end
Jenkins-->>User: Job complete
Additional Comments (1)
-
.ci/pipeline/release_matrix_job.yaml, line 28 (link)logic: the script
.ci/blackduck_source.sh:28usesssh -i ~/.ssh/id_ed25519but theGERRIT_SSH_KEYcredential (which provides the key file path viakeyFileVariable) is never referenced or copied to~/.ssh/id_ed25519- the git clone will fail with "Permission denied (publickey)"either reference
$GERRIT_SSH_KEYin the ssh command or set up the key before cloning
2 files reviewed, 1 comment
Author
|
bot:retest |
NirWolfer
suggested changes
Nov 6, 2025
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
bf91ef6 to
41e0799
Compare
There was a problem hiding this comment.
Greptile Overview
Greptile Summary
This PR adds Blackduck security scanning to the LibVMA release pipeline by introducing a new conditional Blackduck step that runs after the Release step completes.
Key Changes:
- Added
do_blackduckboolean parameter (default: true) to control Blackduck execution - Configured new blackduck docker container with required dependencies (Java 11, jq, git)
- Added global credentials binding for
blackduck_api_token - Created new Blackduck step that executes
.ci/blackduck_source.shscript - Added
failFast: truesetting which changes pipeline behavior to stop immediately on any step failure - Added
containerSelectorto Release step (specifies rhel8.6 container)
Issues Found:
- The addition of
containerSelectorto the Release step is not mentioned in the PR description and could potentially affect the existing release workflow's container selection behavior - The
failFast: truesetting is a global change that affects all steps, meaning if the Release step fails, the Blackduck step won't run at all
Confidence Score: 3/5
- Safe to merge after verifying the container selector and failFast behavior changes don't break the release workflow
- The Blackduck integration itself is well-structured with proper credential handling and conditional execution. However, two undocumented changes (
failFast: trueandcontainerSelectoraddition to Release step) could affect existing release pipeline behavior and should be verified before merging .ci/pipeline/release_matrix_job.yaml- verify thecontainerSelectoraddition andfailFastsetting work correctly with existing release workflow
Important Files Changed
File Analysis
| Filename | Score | Overview |
|---|---|---|
| .ci/pipeline/release_jjb.yaml | 5/5 | added do_blackduck parameter to control Blackduck execution - straightforward and safe |
| .ci/pipeline/release_matrix_job.yaml | 3/5 | added Blackduck step with credentials, docker config, and failFast: true; also added containerSelector to Release step which could affect existing behavior |
Sequence Diagram
sequenceDiagram
participant Jenkins as Jenkins Job
participant JJB as JJB Config
participant Release as Release Step
participant Blackduck as Blackduck Step
participant Script as blackduck_source.sh
participant BD_Server as Blackduck Server
Jenkins->>JJB: Start release job with do_blackduck=true
JJB->>Release: Execute Release step
Note over Release: Uses rhel8.6 container<br/>with containerSelector
Release->>Release: Run .ci/do_release.sh
Release->>Release: Build and package RPMs
alt failFast enabled and Release fails
Release-->>Jenkins: Exit entire pipeline
end
Release->>Blackduck: Proceed to Blackduck step
Note over Blackduck: Conditional: enable=${do_blackduck}
Blackduck->>Blackduck: Load blackduck container
Blackduck->>Blackduck: Inject BLACKDUCK_API_TOKEN credential
Blackduck->>Script: Execute .ci/blackduck_source.sh
Script->>Script: Clone blackduck tools repo
Script->>BD_Server: Run signature scan
BD_Server-->>Script: Return scan results
Script->>Blackduck: Archive logs and PDF report
Blackduck->>Jenkins: Complete pipeline
2 files reviewed, 2 comments
Author
|
bot:retest |
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
41e0799 to
7677d86
Compare
Greptile OverviewGreptile SummaryThis PR integrates Blackduck security scanning into the release pipeline by adding a new pipeline step that runs after the release build completes. Key Changes:
Configuration:
Confidence Score: 4/5
Important Files ChangedFile Analysis
Sequence DiagramsequenceDiagram
participant J as Jenkins Job
participant R as Release Container (rhel8.6)
participant B as Blackduck Container
participant BD as Blackduck Server
participant FS as File System
J->>J: Start Release Pipeline
Note over J: Parameters: release_tag, do_release, do_blackduck
J->>R: Execute Release Step
R->>R: Run .ci/do_release.sh
R->>FS: Build & Package RPMs
R->>FS: Archive artifacts (pkg/build_pkg.log, *.rpm)
R->>J: Release Complete
alt do_blackduck == true
J->>B: Execute Blackduck Step
Note over B: Container runs as user 6213 (swx-jenkins)
B->>B: Run .ci/blackduck_source.sh
B->>B: Load BLACKDUCK_API_TOKEN credential
B->>B: git clone DevOps/Tools/blackduck to /tmp/blackduck
Note over B: Uses SSH key at ~/.ssh/id_ed25519
B->>BD: ./run_bd_scan.sh signature
Note over B,BD: Timeout: 3600 seconds
BD->>B: Scan results & PDF report
B->>FS: Archive logs/ directory
B->>J: Blackduck Complete
else do_blackduck == false
Note over J,B: Skip Blackduck step
end
J->>J: Send notification email
J->>J: Pipeline Complete
|
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
7677d86 to
d6ea20a
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
d6ea20a to
741fc5e
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
2 times, most recently
from
c29dab5 to
7f11a20
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
7f11a20 to
c3dd0d3
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
c3dd0d3 to
05f9d74
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
05f9d74 to
ce9718a
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
ce9718a to
8c8559d
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
8c8559d to
18db5d4
Compare
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
18db5d4 to
8783d85
Compare
Signed-off-by: Noam Tsemah <[email protected]>
ntsemah
force-pushed
the
HPCINFRA-3964
branch
from
8783d85 to
21bdc3d
Compare
NirWolfer
approved these changes
Nov 13, 2025
dpressle
approved these changes
Nov 13, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
What
Add Blackduck to release job
Why ?
HPCINFRA-3964
How ?
It is optional but for complex PRs please provide information about the design,
architecture, approach, etc.
Change type
What kind of change does this PR introduce?
Check list