202411-rc add #2
Conversation
Reviewer's Guide by SourceryThis PR updates repository references throughout the codebase, replacing 'intel/pcm' with 'khulnasoft/pcm' in URLs, workflow conditions, and documentation links. No diagrams generated as the changes look simple and do not need a visual representation. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
WalkthroughThe pull request introduces several changes across multiple GitHub Actions workflow files and documentation, primarily focusing on updating conditional execution checks to exclude the repository Changes
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey @NxPKG - I've reviewed your changes - here's some feedback:
Overall Comments:
- Please provide context for this repository rename from intel/pcm to khulnasoft/pcm. Is this an authorized fork/transfer? The PR description should explain the motivation for these changes.
- Some references to intel/pcm remain in wiki image URLs and other resources. These should be updated for consistency if this is intended to be a complete migration.
Here's what I looked at during the review
- 🟡 General issues: 1 issue found
- 🟢 Security: all looks good
- 🟢 Testing: all looks good
- 🟢 Complexity: all looks good
- 🟢 Documentation: all looks good
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| [](https://github.com/intel/pcm/security/code-scanning/tools/CodeQL/status) | ||
| [](https://securityscorecards.dev/viewer/?uri=github.com/intel/pcm) | ||
| [](https://github.com/khulnasoft/pcm/security/code-scanning/tools/CodeQL/status) | ||
| [](https://securityscorecards.dev/viewer/?uri=github.com/intel/pcm) |
There was a problem hiding this comment.
issue (bug_risk): Inconsistent repository reference in OpenSSF Scorecard link
The badge URL has been updated to use khulnasoft/pcm, but the viewer URL still points to intel/pcm. This should be updated for consistency.
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
PR Code Suggestions ✨No code suggestions found for the PR. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🧹 Outside diff range and nitpick comments (10)
.github/workflows/ci-cov-linux.yml (1)
Line range hint
1-35: Security measures look good, consider adding documentationThe workflow implements security best practices:
- Uses pinned action versions
- Implements runner hardening
- Has appropriate permission scoping
Consider adding a brief comment explaining why this job should skip the main repository (assuming the condition is intentional).
name: coverity-linux on: push: branches: [ '**' ] pull_request: branches: [ '**' ] permissions: contents: read jobs: build: runs-on: ci-kw-linux + # Skip main repository as Coverity analysis is handled differently there if: ${{ github.repository != 'khulnasoft/pcm' }}🧰 Tools
🪛 actionlint (1.7.4)
15-15: label "ci-kw-linux" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-cppcheck.yml (1)
16-16: Remove trailing spacesThere are trailing spaces at the end of line 16 that should be removed.
- if: ${{ github.repository != 'khulnasoft/pcm' }} + if: ${{ github.repository != 'khulnasoft/pcm' }}🧰 Tools
🪛 yamllint (1.35.1)
[error] 16-16: trailing spaces
(trailing-spaces)
.github/workflows/ci-cov-linux-report.yml (1)
Missing shell scripts referenced in CI workflows
The verification reveals that the shell scripts
ci-cov-python.sh,ci-cov-linux.sh, andci-cov-linux-report.share referenced in the CI workflow files but do not exist in the repository. This is a critical issue as these scripts are essential for the workflow's execution.
.github/workflows/ci-cov-python.ymlreferences missing script.github/workflows/ci-cov-linux.ymlreferences missing script.github/workflows/ci-cov-linux-report.ymlreferences missing script🔗 Analysis chain
Line range hint
29-30: Verify the shell scripts existence and permissionsThe workflow references several shell scripts (
ci-cov-python.sh,ci-cov-linux.sh,ci-cov-linux-report.sh) that are not visible in the provided context. These scripts are critical for the workflow's functionality.Let's verify these scripts exist and have proper permissions:
Also applies to: 34-37, 39-40
Let me try a different search strategy to locate these scripts.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check if the required shell scripts exist and are executable # Expected: Find the scripts and verify their permissions # Find the scripts echo "Searching for required scripts:" fd "ci-cov-(python|linux|linux-report)\.sh$" # Check if found scripts are executable fd "ci-cov-(python|linux|linux-report)\.sh$" -x stat -c "%a %n" {}Length of output: 190
Script:
#!/bin/bash # Try searching with ripgrep for any references to these scripts echo "Searching for script references in workflow files:" rg -l "ci-cov-(python|linux|linux-report)\.sh" .github/workflows/ echo -e "\nSearching for the actual script files in the entire repo:" rg -l "ci-cov-(python|linux|linux-report)\.sh$" echo -e "\nListing all shell scripts in the repo for context:" fd ".+\.sh$"Length of output: 1135
🧰 Tools
🪛 actionlint (1.7.4)
11-11: label "ci-kw-linux" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-fuzz.yml (1)
14-14: Consider using GitHub-hosted runners for better maintainability.The workflow uses a custom runner (
ci-test). While this might be intentional for specific requirements, consider using GitHub-hosted runners (e.g.,ubuntu-latest) if possible, as they:
- Are automatically maintained with latest security patches
- Provide consistent and clean environments
- Reduce maintenance overhead
.github/workflows/ci-cmake-options.yml (1)
16-16: Consider adding a comment explaining the skip conditionTo improve maintainability, consider adding a comment explaining why this workflow is skipped on the main repository. This will help future maintainers understand the reasoning behind this condition.
+ # Skip on main repository as these tests are intended for forks/PRs only if: ${{ github.repository != 'khulnasoft/pcm' }}pcm-kubernetes.yaml.experimental (1)
Line range hint
156-159: Consider adjusting the scrape interval and adding resource limits
A 1-second scrape interval might be too aggressive and could:
- Impact performance
- Generate excessive data
- Overwhelm Prometheus storage
The container specification is missing resource limits and requests.
Add resource limits to the container spec:
- name: intel-pcm + resources: + limits: + cpu: "1" + memory: "512Mi" + requests: + cpu: "200m" + memory: "256Mi"Consider adjusting the scrape interval:
port: pcm-metrics - interval: 1s + interval: 15s # Adjust based on your monitoring requirementsdoc/LATENCY-OPTIMIZED-MODE.md (1)
26-27: Repository URLs updated correctly, but formatting can be improved.The URLs have been correctly updated to reflect the new repository location. However, there are some formatting improvements that can be made:
- Use angle brackets for URLs
- Replace hard tabs with spaces
- Improve table formatting for better readability
Apply these changes:
-|Linux/FreeBSD/UNIX|bash | https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.sh | -|Windows |powershell | https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.ps1 | +| Linux/FreeBSD/UNIX | bash | <https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.sh> | +| Windows | powershell | <https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.ps1> |🧰 Tools
🪛 Markdownlint (0.35.0)
27-27: Column: 9
Hard tabs(MD010, no-hard-tabs)
26-26: null
Bare URL used(MD034, no-bare-urls)
27-27: null
Bare URL used(MD034, no-bare-urls)
doc/PCM_ACCEL_README.md (1)
Line range hint
1-117: Consider updating the Intel® trademark symbols.The document uses both
Intel®andIntelinconsistently. Consider standardizing the trademark usage throughout the document.🧰 Tools
🪛 Markdownlint (0.35.0)
115-115: null
Bare URL used(MD034, no-bare-urls)
src/pcm-sensor-server.cpp (2)
Line range hint
1183-1196: Consider enhancing error handling and messagesThe driver dependency checks could be improved:
- Error messages could be more specific about required driver versions
- Kernel version check logic could be extracted into a separate function
- Consider adding logging of successful driver checks
Example refactor for kernel version check:
+ bool isKernelVersionSupported(uint32_t& major, uint32_t& minor) { + struct utsname sys_info; + if (uname(&sys_info) != 0) return false; + + std::vector<std::string> version = split(sys_info.release, '.'); + if (version.size() < 2) return false; + + std::istringstream(version[0]) >> std::setbase(0) >> major; + std::istringstream(version[1]) >> std::setbase(0) >> minor; + + return true; + } - if (!uname(&sys_info)) - { - std::string krel_str; - uint32 krel_major_ver=0, krel_minor_ver=0; - // ... existing version parsing code - } + uint32_t major = 0, minor = 0; + if (isKernelVersionSupported(major, minor)) { + // Use major and minor for version checks + }
Line range hint
1292-1321: Improve SSL configuration robustnessThe SSL configuration handling could be enhanced:
- Define error codes as named constants
- Add more thorough certificate/key file validation
- Consider adding certificate expiration checks
Example improvements:
+ enum SSLConfigError { + CERT_FILE_MISSING = 3, + KEY_FILE_MISSING = 4, + SSL_CONFIG_ERROR = 5 + }; + bool validateSSLFile(const std::string& path, bool isCertificate) { + std::ifstream fp(path); + if (!fp.is_open()) return false; + + // Add basic format validation + std::string line; + if (isCertificate) { + if (!std::getline(fp, line) || line.find("-----BEGIN CERTIFICATE-----") == std::string::npos) + return false; + } else { + if (!std::getline(fp, line) || line.find("-----BEGIN PRIVATE KEY-----") == std::string::npos) + return false; + } + return true; + } - if (!fp.is_open()) { - std::cerr << "Cannot open certificate file \"" << argv[i] << "\".\n"; - printHelpText(argv[0]); - exit(3); - } + if (!validateSSLFile(argv[i], true)) { + std::cerr << "Invalid certificate file \"" << argv[i] << "\".\n"; + printHelpText(argv[0]); + exit(SSLConfigError::CERT_FILE_MISSING); + }
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (29)
.github/workflows/ci-clang-scan.yml(1 hunks).github/workflows/ci-cmake-options.yml(1 hunks).github/workflows/ci-cov-linux-report.yml(1 hunks).github/workflows/ci-cov-linux.yml(1 hunks).github/workflows/ci-cov-python.yml(1 hunks).github/workflows/ci-cov-windows-report.yml(1 hunks).github/workflows/ci-cov-windows.yml(1 hunks).github/workflows/ci-cpack.yml(2 hunks).github/workflows/ci-cppcheck.yml(1 hunks).github/workflows/ci-fuzz-micro.yml(1 hunks).github/workflows/ci-fuzz-short.yml(1 hunks).github/workflows/ci-fuzz.yml(1 hunks).github/workflows/ci-gcc10.yml(1 hunks).github/workflows/ci-gcc7.yml(1 hunks).github/workflows/ci-gcc9.yml(1 hunks).github/workflows/ci-test.yml(1 hunks).github/workflows/ci-windows-ip.yml(1 hunks).github/workflows/ci-windows.yml(1 hunks)CONTRIBUTING.md(1 hunks)README.md(4 hunks)_service(1 hunks)doc/DOCKER_README.md(1 hunks)doc/LATENCY-OPTIMIZED-MODE.md(1 hunks)doc/LINUX_HOWTO.txt(1 hunks)doc/PCM-EXPORTER.md(1 hunks)doc/PCM_ACCEL_README.md(1 hunks)pcm-kubernetes.yaml.experimental(1 hunks)scripts/grafana/README.md(1 hunks)src/pcm-sensor-server.cpp(2 hunks)
✅ Files skipped from review due to trivial changes (5)
- CONTRIBUTING.md
- _service
- doc/LINUX_HOWTO.txt
- doc/PCM-EXPORTER.md
- scripts/grafana/README.md
🧰 Additional context used
🪛 yamllint (1.35.1)
.github/workflows/ci-cppcheck.yml
[error] 16-16: trailing spaces
(trailing-spaces)
🪛 LanguageTool
README.md
[uncategorized] ~37-~37: A comma may be missing after the conjunctive/linking adverb ‘Also’.
Context: ...format (how-to). Also available as a [docker container](doc/D...
(SENT_START_CONJUNCTIVE_LINKING_ADVERB_COMMA)
🪛 Markdownlint (0.35.0)
doc/DOCKER_README.md
8-8: null
Bare URL used
(MD034, no-bare-urls)
13-13: null
Bare URL used
(MD034, no-bare-urls)
doc/LATENCY-OPTIMIZED-MODE.md
27-27: Column: 9
Hard tabs
(MD010, no-hard-tabs)
26-26: null
Bare URL used
(MD034, no-bare-urls)
27-27: null
Bare URL used
(MD034, no-bare-urls)
🔇 Additional comments (30)
.github/workflows/ci-windows-ip.yml (1)
12-12:
Verify the intended condition logic
The current condition prevents this workflow from running on the 'khulnasoft/pcm' repository. This seems counterintuitive as typically you'd want workflows to run on your own repository. Should this condition be inverted?
Let's check if this pattern is consistent across other workflow files:
Consider inverting the condition if the workflow should run on 'khulnasoft/pcm':
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}✅ Verification successful
Repository condition is consistent across all workflows
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} appears consistently across all GitHub Actions workflow files in the repository. This pattern is deliberately used in 19 different workflow files, indicating it's an intentional design choice rather than a mistake. The condition prevents these workflows from running in the main repository while allowing them to run in forks, which is a common pattern for open-source projects to manage CI resources.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the repository conditions in other workflow files
# Expected: Find similar conditions to understand the intended behavior
# Search for repository conditions in workflow files
rg -A 1 "github.repository !=" .github/workflows/
Length of output: 2453
.github/workflows/ci-cov-python.yml (2)
16-16: LGTM: Repository name update is consistent with rebranding
The change from 'intel/pcm' to 'khulnasoft/pcm' aligns with the repository rebranding effort.
16-16: Verify the intended workflow behavior
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} means this coverage analysis workflow will NOT run on the main repository, but only on forks. Please verify if this is the intended behavior.
Run the following script to check if this pattern is consistent across other workflow files:
✅ Verification successful
The condition is consistently applied across all workflow files
After analyzing the output, I can confirm that the condition if: ${{ github.repository != 'khulnasoft/pcm' }} is consistently applied across all CI workflow files in the repository, including coverage analysis workflows. This is an intentional pattern where these workflows are designed to run only on forks and not on the main repository.
This is a common practice for security-sensitive workflows like coverage analysis, where you want to prevent potentially malicious code from running in the context of the main repository.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check repository conditions across all workflow files
# Expected: Consistent pattern of excluding 'khulnasoft/pcm' in coverage workflows
# Search for repository conditions in workflow files
echo "Checking repository conditions in workflow files:"
rg -A 1 "if: \${{ github.repository" .github/workflows/
# Check specifically for coverage-related workflows
echo -e "\nChecking coverage workflow patterns:"
fd "ci-cov.*yml" .github/workflows/ --exec rg -A 1 "if: \${{ github.repository"
Length of output: 1133
Script:
#!/bin/bash
# Let's try a different approach by directly looking at the workflow files content
echo "Content of coverage workflow files:"
fd "ci-cov.*yml" .github/workflows/ --exec cat {}
echo -e "\nChecking all workflow files for repository conditions:"
fd ".*yml$" .github/workflows/ --exec grep -l "github.repository" {} \; --exec cat {}
Length of output: 29905
.github/workflows/ci-cov-linux.yml (1)
16-16:
Review the job condition logic
The current condition if: ${{ github.repository != 'khulnasoft/pcm' }} means this Coverity analysis will run on all repositories EXCEPT 'khulnasoft/pcm'. This seems counterintuitive as typically we want CI checks to run ON the main repository, not skip it.
Please verify if this is the intended behavior. If not, consider inverting the condition:
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}Let's verify this pattern across other workflow files:
.github/workflows/ci-clang-scan.yml (2)
Line range hint 1-38: LGTM for the rest of the file
The workflow follows security best practices:
- Uses pinned action versions
- Implements minimal permissions
- Uses harden-runner for security
- Correctly configures scan-build with appropriate exclusions
🧰 Tools
🪛 actionlint (1.7.4)
15-15: label "ci-clang-scan" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
16-16:
Critical: The condition will prevent the workflow from running in this repository
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} will prevent this workflow from running in the khulnasoft/pcm repository. This effectively disables the clang static analysis for this repository, which could lead to undetected code quality issues.
If the intention is to run this workflow in the khulnasoft/pcm repository, apply this fix:
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}If there's a specific reason to disable this workflow, please document it in the workflow file or consider removing the workflow entirely.
Let's verify the impact of this condition:
.github/workflows/ci-gcc9.yml (1)
16-16: Verify conditions in other workflow files
The AI summary indicates similar changes were made to other workflow files. Let's verify if they have the same issue.
✅ Verification successful
Let me check the actual conditions in these files to verify if they have the same issue.
Consistent condition found across all workflow files
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} is consistently present across all GitHub workflow files. This appears to be an intentional configuration to control workflow execution based on the repository context, and not an issue that needs to be fixed.
- Found in all 18 workflow files with identical syntax and repository reference
- The condition is used consistently to skip certain workflow steps when running in the main repository
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check conditions in other workflow files
# Expected: Find similar conditions that might need to be fixed
echo "Checking conditions in other workflow files:"
rg -l "github.repository.*khulnasoft/pcm" .github/workflows/
Length of output: 787
Script:
#!/bin/bash
# Check the actual conditions in the workflow files
rg "if:.*github\.repository.*khulnasoft/pcm" .github/workflows/ -A 1
Length of output: 2472
.github/workflows/ci-gcc7.yml (3)
18-18: LGTM: Security measures are properly implemented
The workflow includes appropriate security measures:
- Uses harden-runner with a pinned version
- Has minimal permissions (contents: read)
Also applies to: 19-19, 20-20, 21-21, 22-22, 23-23
Line range hint 1-1: Review runner and compiler version mismatch
The workflow is named "g++ 7 build" but runs on a runner labeled 'ci-gcc9'. While this might work if both GCC versions are installed, it could lead to confusion or issues if GCC 7 is not available on the runner.
Let's verify the GCC 7 availability on the runner:
Consider either:
- Using a runner name that matches the GCC version being used (e.g., 'ci-gcc7')
- Adding explicit steps to verify GCC 7 availability before the build
Also applies to: 2-2, 3-3, 4-4, 5-5, 6-6, 7-7, 8-8, 9-9, 10-10, 11-11, 12-12, 13-13, 14-14
🧰 Tools
🪛 actionlint (1.7.4)
15-15: label "ci-gcc9" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
16-16: Verify the intended behavior of the repository condition
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} means this workflow will skip running on the main repository but run on forks. Please confirm if this is the intended behavior.
Let's check if this pattern is consistent across other workflow files:
✅ Verification successful
Repository condition is consistent across CI workflows
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} is consistently used across multiple workflow files in the repository, including:
- ci-clang-scan.yml
- ci-cmake-options.yml
- ci-cov-linux.yml
- ci-cov-python.yml
- ci-cov-windows.yml
- ci-gcc7.yml
- ci-gcc9.yml
- ci-gcc10.yml
- ci-test.yml
- ci-windows.yml
This is an intentional pattern where CI jobs are designed to run only on forks and not on the main repository, likely for security or resource optimization reasons.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check repository conditions across all workflow files
# Expected: Consistent pattern of excluding 'khulnasoft/pcm'
echo "Checking repository conditions in workflow files:"
rg -A 1 "if: \$\{\{ github\.repository" .github/workflows/
Length of output: 168
Script:
#!/bin/bash
# Let's try a different approach to find repository conditions
# Using grep with simpler pattern and showing all workflow files content
echo "Checking all workflow files for repository conditions:"
for file in $(find .github/workflows -type f -name "*.yml"); do
echo "=== $file ==="
cat "$file"
echo -e "\n"
done
Length of output: 48893
.github/workflows/ci-gcc10.yml (2)
16-16: LGTM - Repository reference updated correctly
The condition has been properly updated to reflect the repository's new ownership under khulnasoft/pcm.
16-16: Verify CI execution strategy for the main repository
The condition github.repository != 'khulnasoft/pcm' will prevent this workflow from running on the main repository. Please confirm if this is intentional (e.g., if you're using different CI workflows or self-hosted runners for the main repository).
Let's check if there are other CI workflows specifically for the main repository:
✅ Verification successful
CI workflows are correctly configured for repository-specific execution
The condition github.repository != 'khulnasoft/pcm' is intentional and part of a consistent CI strategy. The search results show:
- Most CI workflows using custom runners (ci-gcc10, ci-windows, etc.) are configured to run only on forks (repositories other than khulnasoft/pcm)
- The main repository (khulnasoft/pcm) uses different workflows:
clang_scan.ymlexplicitly runs on the main repo withgithub.repository == 'intel/pcm'- Standard GitHub-hosted runners (ubuntu-latest, macOS) are used for workflows like scorecard, codeql, dependency-review without repository restrictions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for other CI workflows that might be specific to the main repository
# Expected: Find workflows that run specifically on khulnasoft/pcm
# Search for workflow files containing repository conditions
echo "Checking for workflows with repository conditions:"
rg -l "github.repository" .github/workflows/
# Search for alternative CI configurations
echo -e "\nChecking for repository-specific CI patterns:"
rg -A 3 "runs-on:" .github/workflows/
Length of output: 9194
.github/workflows/ci-fuzz-short.yml (1)
Line range hint 1-43: Review security and best practices
The workflow configuration looks good in terms of:
- Proper permissions setting with minimal
contents: read - Using pinned versions for all GitHub Actions
- Using the Harden Runner for security
- Proper artifact handling
🧰 Tools
🪛 actionlint (1.7.4)
13-13: label "ci-test" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-cov-linux-report.yml (1)
12-12: Verify the repository condition logic
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} means this workflow will run on all repositories EXCEPT khulnasoft/pcm. This seems counterintuitive as we typically want CI workflows to run on our own repository. Please verify if this is the intended behavior.
Let's check if this pattern is consistent across other workflow files:
✅ Verification successful
Repository condition is consistent across all workflows
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} is consistently used across all GitHub Actions workflow files in the repository. This appears to be an intentional pattern where these workflows are designed to run only on forks of the repository, not on the main repository itself. This is a valid and sometimes used approach when the main repository has different CI/CD requirements or uses a different set of workflows.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check repository conditions in other workflow files
# Expected: Find similar conditions to verify if this is a consistent pattern
rg -l "github.repository.*khulnasoft/pcm" .github/workflows/
Length of output: 688
Script:
#!/bin/bash
# Let's check the actual conditions in these files to understand the pattern
rg "if:.*github.repository.*khulnasoft/pcm" .github/workflows/ -A 1
Length of output: 2471
.github/workflows/ci-fuzz-micro.yml (2)
15-15: Review security implications of the condition
The inverted condition (!=) means this fuzzing job runs on all repositories except khulnasoft/pcm. This could potentially allow the job to run in forks, which might not be intended.
Consider adding additional conditions to restrict execution:
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository != 'khulnasoft/pcm' && (github.event_name == 'push' || github.event_name == 'pull_request') && github.actor != 'dependabot[bot]' }}15-15: Verify repository condition consistency across workflows
The condition change from intel/pcm to khulnasoft/pcm aligns with the repository transfer. However, let's verify this change is consistent across all workflow files.
.github/workflows/ci-cov-windows.yml (2)
16-16: LGTM! Repository condition updated correctly.
The condition change aligns with the repository migration from Intel to Khulnasoft.
Line range hint 34-37: Verify the referenced PowerShell scripts for repository migration changes.
The workflow references external PowerShell scripts. We should ensure these scripts have been updated to reflect the repository migration.
Also applies to: 39-42, 44-47
🧰 Tools
🪛 actionlint (1.7.4)
15-15: label "ci-kw-windows" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-fuzz.yml (2)
17-17: LGTM! Condition updated correctly as part of repository migration.
The change from intel/pcm to khulnasoft/pcm aligns with the repository migration effort and matches similar changes in other workflow files.
Line range hint 19-23: Verify security measures across related workflows.
The workflow implements good security practices with pinned action versions and the Harden Runner. Let's verify this is consistent across related workflows.
Also applies to: 25-27
✅ Verification successful
Security measures are consistently implemented across all workflows
The verification confirms that all workflows consistently implement strong security practices:
- All GitHub Actions are pinned to specific commit hashes
- The Harden Runner is used across all workflows with consistent configuration
- No unpinned action versions were found (all use
@{commit-hash}format) - Even the FreeBSD workflows use an updated version of Harden Runner (v2.10.0)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check security measures in other workflow files
# Expected results: All workflows should use pinned versions and Harden Runner
# Check for workflows using Harden Runner
echo "Checking Harden Runner usage:"
rg -l "step-security/harden-runner" .github/workflows/
# Check for unpinned action versions (should not find any)
echo -e "\nChecking for unpinned actions:"
rg -l "uses: [^@]+" .github/workflows/ | while read -r file; do
echo "=== $file ==="
rg "uses: [^@]+" "$file" || true
done
Length of output: 15164
🧰 Tools
🪛 actionlint (1.7.4)
16-16: label "ci-test" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-cov-windows-report.yml (1)
Line range hint 4-45: Security measures look good!
The workflow implements security best practices:
- Uses pinned versions for all actions
- Implements runner hardening
- Has minimal permissions (read-only)
- Uses secure artifact handling
🧰 Tools
🪛 actionlint (1.7.4)
11-11: label "ci-kw-windows" is unknown. available labels are "windows-latest", "windows-latest-8-cores", "windows-2022", "windows-2019", "ubuntu-latest", "ubuntu-latest-4-cores", "ubuntu-latest-8-cores", "ubuntu-latest-16-cores", "ubuntu-24.04", "ubuntu-22.04", "ubuntu-20.04", "macos-latest", "macos-latest-xl", "macos-latest-xlarge", "macos-latest-large", "macos-15-xlarge", "macos-15-large", "macos-15", "macos-14-xl", "macos-14-xlarge", "macos-14-large", "macos-14", "macos-13-xl", "macos-13-xlarge", "macos-13-large", "macos-13", "macos-12-xl", "macos-12-xlarge", "macos-12-large", "macos-12", "self-hosted", "x64", "arm", "arm64", "linux", "macos", "windows". if it is a custom label for self-hosted runner, set list of labels in actionlint.yaml config file
(runner-label)
.github/workflows/ci-cpack.yml (1)
43-43: LGTM: Repository condition updated consistently
The condition update in job-build2 matches the change in job-build1, maintaining consistency within the workflow.
.github/workflows/ci-test.yml (1)
16-16:
Verify the conditional execution logic
The current condition if: ${{ github.repository != 'khulnasoft/pcm' }} will skip the build job on the main repository ('khulnasoft/pcm') and only run it on forks. This seems counterintuitive as we typically want CI tests to run on the main repository to ensure code quality.
If this was unintentional, consider changing it to:
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}Let's verify the impact of this condition across all workflow files:
✅ Verification successful
Let me generate additional verification scripts to check if there are any other workflow files or configurations that might provide context for this pattern:
This will help us understand if there's any documented reason for this setup or if there are other configurations that might explain why the CI is set up to run only on forks.
Let me check one more thing to see if there are other workflow files that might be handling the main repository's CI:
This will help us verify if there's a separate set of workflows handling the CI for the main repository, as suggested by the README badges.
The CI workflow configuration is correct and intentional
The verification reveals a well-structured CI setup where:
- The main repository (khulnasoft/pcm) uses dedicated workflows (linux_make.yml, freebsd_build.yml, macosx_build.yml, docker.yml, codeql.yml) that run on standard GitHub-hosted runners
- The workflows with condition
if: ${{ github.repository != 'khulnasoft/pcm' }}are specifically for running on custom self-hosted runners (e.g., ci-gcc9, ci-test, ci-windows) and are intentionally skipped for the main repository
This is a common pattern when:
- The main repository uses standard GitHub-hosted runners for security and reliability
- Forks use custom runners for specialized testing environments
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check all workflow files for similar conditions and their impact
# Expected: Find all workflow files and their conditional execution patterns
echo "Checking all workflow files for repository conditions:"
fd -e yml -e yaml . .github/workflows/ --exec grep -l "github.repository" {} \; | while read -r file; do
echo -e "\nFile: $file"
grep -A 2 "github.repository" "$file" || true
done
Length of output: 4939
Script:
#!/bin/bash
# Check for any documentation or configuration that might explain this setup
echo "Checking README and docs for workflow explanations:"
rg -i "workflow|github action|ci|test" README.md || true
echo -e "\nChecking for any special branch protection rules or settings:"
fd -e yml -e yaml . .github/ --exec grep -A 2 "protect" {} \; || true
echo -e "\nChecking for any environment or deployment specific conditions:"
fd -e yml -e yaml . .github/workflows/ --exec grep -A 2 "environment\|deploy" {} \; || true
Length of output: 4210
Script:
#!/bin/bash
# Check for other CI workflow files that might be handling the main repository
echo "Checking all workflow files:"
fd -e yml -e yaml . .github/workflows/ -x cat {} \; | grep -B2 -A2 "khulnasoft/pcm\|linux_make\|freebsd_build\|macosx_build"
echo -e "\nChecking for workflow files mentioned in README badges:"
for file in linux_make.yml freebsd_build.yml macosx_build.yml docker.yml codeql.yml; do
echo -e "\nChecking $file:"
cat ".github/workflows/$file" 2>/dev/null || echo "File not found"
done
Length of output: 12903
.github/workflows/ci-cmake-options.yml (1)
16-16: Verify the workflow skip condition for the main repository
The condition has been updated to skip this workflow when running on 'khulnasoft/pcm'. Please confirm if this is the intended behavior, as it means these CMake option tests won't run on the main repository.
✅ Verification successful
Skip condition is consistent across all workflows
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} is consistently implemented across all workflow files in the repository. This appears to be an intentional pattern to prevent these workflows from running on the main repository while allowing them to run on forks, which is a common practice for open-source projects to manage CI resources. The change from 'intel/pcm' to 'khulnasoft/pcm' is correctly aligned with the repository transfer.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other workflows have similar conditions
echo "Checking other workflow files for consistent repository conditions..."
rg -l "github.repository.*khulnasoft/pcm" .github/workflows/
Length of output: 837
Script:
#!/bin/bash
# Check the actual conditions in these workflows to verify consistency
echo "Checking the specific conditions in workflows..."
rg "if:.*github.repository.*khulnasoft/pcm" .github/workflows/
Length of output: 1843
pcm-kubernetes.yaml.experimental (2)
Line range hint 69-82: Security configuration follows best practices
The security context is well-configured with:
- Minimal required capabilities
- Read-only root filesystem
- Appropriate seccomp profile
- Read-only volume mounts where possible
Line range hint 108-109: Verify node feature discovery label compatibility
The node selector uses the label feature.node.kubernetes.io/cpu-model.vendor_id for Intel CPU detection. Let's verify this is the standard label used by Node Feature Discovery.
✅ Verification successful
Node selector configuration is appropriate for Intel PCM deployment
The node selector configuration is correct and appropriate for this deployment because:
- The repository is specifically for Intel Performance Counter Monitor (Intel PCM) which only works with Intel processors
- The manifest uses the standard Node Feature Discovery (NFD) label
feature.node.kubernetes.io/cpu-model.vendor_idto ensure pods only run on Intel CPU nodes - The configuration is consistent with the tool's requirements as documented in the README, which explicitly states it's for monitoring Intel processors (Core, Xeon, Atom, and Xeon Phi)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other node selector patterns in the codebase
rg -l "feature.node.kubernetes.io/cpu-model"
# Search for any documentation or examples of node feature discovery
fd -t f "README|CONTRIBUTING|docs" -x rg -l "feature.node.kubernetes.io"
Length of output: 150
Script:
#!/bin/bash
# Let's search for any kubernetes manifests or configuration files
fd -e yaml -e yml -x rg -l "nodeSelector|feature.node.kubernetes.io"
# Search for any documentation about CPU requirements or hardware specifications
fd "README|INSTALL|REQUIREMENTS" -x rg -l "cpu|intel|hardware"
# Look for any comments or documentation in the yaml file itself
rg -A 5 -B 5 "^[[:space:]]*#.*cpu|intel" pcm-kubernetes.yaml.experimental
Length of output: 2475
Script:
#!/bin/bash
# Let's check the README for any specific Intel CPU requirements
rg -A 5 -B 5 "requirement|prerequisite|cpu|intel" README.md
# Let's look at the complete node selector configuration in the yaml
rg -A 5 -B 5 "nodeSelector|tolerations" pcm-kubernetes.yaml.experimental
# Check if there are any other similar deployments or examples
fd -e yaml -e yml -x rg -l "feature.node.kubernetes.io/cpu"
Length of output: 4096
doc/LATENCY-OPTIMIZED-MODE.md (1)
26-27: Verify script availability in the new repository.
Let's ensure the referenced scripts exist and are accessible in the new repository location.
✅ Verification successful
Scripts are present and maintain power mode functionality
Both scripts exist in the correct location (scripts/ directory) and contain the expected power mode functionality:
- Both implement default and latency-optimized modes
- Both handle IO and compute dies appropriately
- Both maintain the same TPMI register configurations
- Both provide identical functionality across bash and PowerShell implementations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the existence of power mode scripts in the new repository
# Check if the scripts exist
for script in "bhs-power-mode.sh" "bhs-power-mode.ps1"; do
echo "Checking for $script..."
if fd -t f "^${script}$" ; then
echo "✓ Found $script"
else
echo "✗ Missing $script"
fi
done
Length of output: 511
Script:
#!/bin/bash
# Let's verify the content of these scripts to ensure they maintain power mode functionality
echo "=== Content of bhs-power-mode.sh ==="
cat scripts/bhs-power-mode.sh
echo -e "\n=== Content of bhs-power-mode.ps1 ==="
cat scripts/bhs-power-mode.ps1
Length of output: 9134
🧰 Tools
🪛 Markdownlint (0.35.0)
27-27: Column: 9
Hard tabs
(MD010, no-hard-tabs)
26-26: null
Bare URL used
(MD034, no-bare-urls)
27-27: null
Bare URL used
(MD034, no-bare-urls)
doc/PCM_ACCEL_README.md (1)
117-117: Verify the updated GitHub URL reference.
The URL update from intel/pcm to khulnasoft/pcm is consistent with the repository transition.
Let's verify the URL reference:
src/pcm-sensor-server.cpp (2)
720-722: LGTM: URL reference updated correctly
The issue reference has been updated from intel/pcm to khulnasoft/pcm to reflect the new repository location.
Line range hint 766-772: LGTM: URL reference updated consistently
The issue reference has been updated from intel/pcm to khulnasoft/pcm, maintaining consistency with the repository migration.
| @@ -13,7 +13,7 @@ jobs: | |||
| build: | |||
|
|
|||
| runs-on: ci-cppcheck | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
💡 Codebase verification
Repository reference inconsistency found in workflow files
The repository name change is not consistent across all workflow files. While most workflows have been updated to 'khulnasoft/pcm', the following issue was found:
.github/workflows/clang_scan.ymlstill contains the old reference 'intel/pcm' in its condition:if: ${{ github.repository == 'intel/pcm' }}
🔗 Analysis chain
Verify repository name consistency across workflows
The repository name change from 'intel/pcm' to 'khulnasoft/pcm' aligns with the project rebranding. Let's verify this change is consistent across all workflow files.
Let's check the content of clang_scan.yml since it still contains a reference to 'intel/pcm':
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining references to 'intel/pcm' in workflow files
# and verify consistency of repository references
echo "Checking for any remaining 'intel/pcm' references in workflow files..."
rg -l "intel/pcm" .github/workflows/
echo "Listing all repository conditions in workflow files for consistency check..."
rg -A 1 "github.repository !=" .github/workflows/
Length of output: 2843
Script:
#!/bin/bash
# Check the content of clang_scan.yml for intel/pcm references
cat .github/workflows/clang_scan.yml
Length of output: 1700
🧰 Tools
🪛 yamllint (1.35.1)
[error] 16-16: trailing spaces
(trailing-spaces)
| @@ -13,7 +13,7 @@ jobs: | |||
| build: | |||
|
|
|||
| runs-on: ci-gcc9 | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
Critical: The condition will prevent CI from running on the main repository
The condition github.repository != 'khulnasoft/pcm' means this workflow will skip running on the khulnasoft/pcm repository. This appears to be incorrect as we would want the CI to run on the main repository, not skip it.
Consider one of these fixes:
- Remove the condition entirely if you want the workflow to run on all repositories
- Invert the condition to
github.repository == 'khulnasoft/pcm'if you want it to run only on the main repository - If the intent is to skip specific forks, list those repositories explicitly
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |
| if: ${{ github.repository == 'khulnasoft/pcm' }} |
| @@ -11,7 +11,7 @@ permissions: | |||
| jobs: | |||
| fuzz: | |||
| runs-on: ci-test | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
💡 Codebase verification
Repository condition logic is consistently applied but needs attention
The repository condition github.repository != 'khulnasoft/pcm' is consistently used across all CI workflow files except clang_scan.yml, which uses the opposite condition with intel/pcm. This reveals two issues:
- All CI workflows are configured to run on every repository except
khulnasoft/pcm, which is likely not the intended behavior for CI infrastructure - The
clang_scan.ymlworkflow still references the old repository nameintel/pcmand uses opposite logic
🔗 Analysis chain
Verify the repository condition logic
The condition github.repository != 'khulnasoft/pcm' means this workflow will run for all repositories except khulnasoft/pcm. Is this the intended behavior? Usually, we want workflows to run only for the main repository and its forks.
Let's verify the consistency of repository conditions across all workflow files:
Consider changing to:
- if: ${{ github.repository != 'khulnasoft/pcm' }}
+ if: ${{ github.repository == 'khulnasoft/pcm' }}🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check repository conditions in all workflow files
# Expected: All workflow files should have consistent repository checks
# Search for repository conditions in workflow files
echo "Checking repository conditions in workflow files:"
rg -l "github.repository" .github/workflows/ | while read -r file; do
echo "=== $file ==="
rg "github.repository" "$file" -A 1 -B 1
done
Length of output: 5085
| @@ -16,7 +16,7 @@ jobs: | |||
| build: | |||
|
|
|||
| runs-on: ci-windows | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
💡 Codebase verification
Critical: All CI workflows are configured to skip the main repository
This is a critical issue affecting the entire CI pipeline. The verification reveals that all workflow files (except clang_scan.yml) contain the condition if: ${{ github.repository != 'khulnasoft/pcm' }}, which means:
- None of the CI workflows will run on the main repository
- This includes critical workflows for:
- Windows builds (ci-windows.yml, ci-windows-ip.yml)
- Linux builds (ci-gcc*.yml)
- Test coverage (ci-cov-*.yml)
- Fuzzing (ci-fuzz*.yml)
- Package generation (ci-cpack.yml)
- Code analysis (ci-cppcheck.yml, ci-clang-scan.yml)
The consistent pattern across all workflows suggests this might be a systematic error in the repository migration from intel/pcm to khulnasoft/pcm. The conditions should be reversed to == instead of != to ensure CI runs on the main repository.
🔗 Analysis chain
Verify the workflow condition - potential critical issue
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} will prevent this workflow from running on the main repository. This seems counterintuitive as it means Windows builds will never run on khulnasoft/pcm.
Questions for clarification:
- Is this intentional? Are Windows builds handled differently for the main repository?
- If not intentional, should this condition be reversed to
==instead of!=?
Let's verify the conditions across other workflow files:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check conditions in other workflow files to understand the pattern
# Expected: Find similar conditions in other workflow files to understand if this is a consistent pattern
echo "Checking conditions in all workflow files:"
rg -A 1 "if: " .github/workflows/
Length of output: 2650
| @@ -9,7 +9,7 @@ jobs: | |||
| build: | |||
|
|
|||
| runs-on: ci-kw-windows | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
💡 Codebase verification
Repository condition is consistently applied but needs to be inverted
The verification shows that all CI workflows (except clang_scan.yml) use the same condition github.repository != 'khulnasoft/pcm', which means these workflows will run only on forks but not on the main repository. This is likely incorrect as CI workflows should typically run on the main repository.
- The condition should be inverted to
github.repository == 'khulnasoft/pcm'in all CI workflow files to ensure they run on the main repository - The old
clang_scan.ymlfile shows the correct pattern withgithub.repository == 'intel/pcm', confirming that CI workflows were previously configured to run on the main repository
🔗 Analysis chain
Verify the workflow execution condition
The condition if: ${{ github.repository != 'khulnasoft/pcm' }} means this workflow will NOT run on the 'khulnasoft/pcm' repository. Is this the intended behavior? The workflow will only execute on forks or other repositories.
Let's verify the repository references across other workflow files:
If this workflow should run on the main repository, the condition should be removed or inverted.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check repository conditions across all workflow files
# Expected: Consistent repository reference patterns
# Search for repository conditions in workflow files
echo "Checking repository conditions in workflows:"
rg -A 1 "github.repository" .github/workflows/
Length of output: 2665
| @@ -12,7 +12,7 @@ permissions: | |||
| jobs: | |||
| job-build1: | |||
| runs-on: ci-gcc9 | |||
| if: ${{ github.repository != 'intel/pcm' }} | |||
| if: ${{ github.repository != 'khulnasoft/pcm' }} | |||
There was a problem hiding this comment.
💡 Codebase verification
Inconsistency found in clang_scan.yml workflow condition
The repository migration from 'intel/pcm' to 'khulnasoft/pcm' is incomplete. While most workflow files have been updated correctly, there's one remaining issue:
.github/workflows/clang_scan.ymlstill uses the old conditionif: ${{ github.repository == 'intel/pcm' }}
🔗 Analysis chain
LGTM: Repository condition updated correctly
The condition update from 'intel/pcm' to 'khulnasoft/pcm' aligns with the repository migration.
Let's verify consistency across all workflow files:
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if all workflow files consistently use 'khulnasoft/pcm' in their conditions
# Search for any remaining references to 'intel/pcm' in workflow files
echo "Checking for any remaining 'intel/pcm' references:"
rg "intel/pcm" .github/workflows/
# Search for consistent usage of 'khulnasoft/pcm' in workflow files
echo "Verifying 'khulnasoft/pcm' usage:"
rg "khulnasoft/pcm" .github/workflows/
Length of output: 2096
| @@ -37,7 +37,7 @@ spec: | |||
| spec: | |||
| automountServiceAccountToken: false | |||
| containers: | |||
| - image: ghcr.io/intel/pcm:latest | |||
| - image: ghcr.io/khulnasoft/pcm:latest | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider pinning the container image to a specific version
Using the latest tag in production environments can lead to non-deterministic deployments and complicate rollbacks. Consider using a specific version tag instead.
- - image: ghcr.io/khulnasoft/pcm:latest
+ - image: ghcr.io/khulnasoft/pcm:v1.0.0 # Replace with actual versionCommittable suggestion skipped: line range outside the PR's diff.
| |Linux/FreeBSD/UNIX|bash | https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.sh | | ||
| |Windows |powershell | https://github.com/khulnasoft/pcm/blob/master/scripts/bhs-power-mode.ps1 | |
There was a problem hiding this comment.
💡 Codebase verification
Repository URLs in documentation need to be updated for consistency
Several documentation files still contain references to the old intel/pcm repository that need to be updated to khulnasoft/pcm:
doc/PCM-EXPORTER.md: Contains outdated links tointel/pcmfor build instructions and non-root executiondoc/LATENCY-OPTIMIZED-MODE.md: Contains outdated links tointel/pcmfor downloading and building instructionsdoc/STARS.md: Contains an outdated star history chart URL referencingintel/pcm
🔗 Analysis chain
Verify consistency of repository URLs across documentation.
Let's check if there are any remaining references to the old repository that need to be updated.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any remaining references to intel/pcm in documentation
echo "Checking for remaining intel/pcm references in documentation..."
rg -t md "intel/pcm" doc/
echo "Checking for inconsistent repository references..."
rg -t md "github\.com/[^/]+/pcm" doc/
Length of output: 2607
🧰 Tools
🪛 Markdownlint (0.35.0)
27-27: Column: 9
Hard tabs
(MD010, no-hard-tabs)
26-26: null
Bare URL used
(MD034, no-bare-urls)
27-27: null
Bare URL used
(MD034, no-bare-urls)
User description
Notes for Reviewers
This PR fixes #
Signed commits
PR Type
enhancement, documentation
Description
Changes walkthrough 📝
1 files
pcm-sensor-server.cpp
Update repository URL in source code commentssrc/pcm-sensor-server.cpp
20 files
ci-clang-scan.yml
Update repository condition in CI workflow.github/workflows/ci-clang-scan.yml
ci-cmake-options.yml
Modify repository condition in CI workflow.github/workflows/ci-cmake-options.yml
ci-cov-linux-report.yml
Adjust repository condition in CI workflow.github/workflows/ci-cov-linux-report.yml
ci-cov-linux.yml
Update repository condition in CI workflow.github/workflows/ci-cov-linux.yml
ci-cov-python.yml
Modify repository condition in CI workflow.github/workflows/ci-cov-python.yml
ci-cov-windows-report.yml
Adjust repository condition in CI workflow.github/workflows/ci-cov-windows-report.yml
ci-cov-windows.yml
Update repository condition in CI workflow.github/workflows/ci-cov-windows.yml
ci-cpack.yml
Modify repository condition in CI workflow.github/workflows/ci-cpack.yml
ci-cppcheck.yml
Update repository condition in CI workflow.github/workflows/ci-cppcheck.yml
ci-fuzz-micro.yml
Modify repository condition in CI workflow.github/workflows/ci-fuzz-micro.yml
ci-fuzz-short.yml
Update repository condition in CI workflow.github/workflows/ci-fuzz-short.yml
ci-fuzz.yml
Modify repository condition in CI workflow.github/workflows/ci-fuzz.yml
ci-gcc10.yml
Update repository condition in CI workflow.github/workflows/ci-gcc10.yml
ci-gcc7.yml
Modify repository condition in CI workflow.github/workflows/ci-gcc7.yml
ci-gcc9.yml
Update repository condition in CI workflow.github/workflows/ci-gcc9.yml
ci-test.yml
Modify repository condition in CI workflow.github/workflows/ci-test.yml
ci-windows-ip.yml
Update repository condition in CI workflow.github/workflows/ci-windows-ip.yml
ci-windows.yml
Modify repository condition in CI workflow.github/workflows/ci-windows.yml
_service
Update download paths in service configuration_service
pcm-kubernetes.yaml.experimental
Update Docker image path in Kubernetes configpcm-kubernetes.yaml.experimental
8 files
CONTRIBUTING.md
Update license URL in contributing guideCONTRIBUTING.md
README.md
Update URLs in README for new repositoryREADME.md
DOCKER_README.md
Update Docker instructions for new repositorydoc/DOCKER_README.md
LATENCY-OPTIMIZED-MODE.md
Update script URLs in documentationdoc/LATENCY-OPTIMIZED-MODE.md
LINUX_HOWTO.txt
Update CI workflow URL in documentationdoc/LINUX_HOWTO.txt
PCM-EXPORTER.md
Update image URL in documentationdoc/PCM-EXPORTER.md
PCM_ACCEL_README.md
Update source code URL in documentationdoc/PCM_ACCEL_README.md
README.md
Update image URL in Grafana READMEscripts/grafana/README.md
Summary by CodeRabbit
Release Notes
New Features
PodMonitorresource for monitoring metrics in the Kubernetes configuration.Documentation
CONTRIBUTING.md,README.md, and other documentation files to reflect the new repository location.pcm-acceltool documentation regarding performance metrics and prerequisites.Chores