Conversation
feat: use top-level tenantId
scott45
requested review from
Justus-at-Tazama and
Sandy-at-Tazama
as code owners
build: bump @tazama-lf deps to rc and update CODEOWNERS
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (15)
📝 WalkthroughWalkthroughRepository-wide infra and CI changes: updated CODEOWNERS to team-based entries, removed a benchmark workflow, added/modified many GitHub Actions (pinned action SHAs, new branch-target and scorecard workflows, reusable rule packaging workflows), bumped package to 4.0.0-rc.0, removed CHANGELOG/VERSION, switched Dockerfile to BuildKit secrets, and one small service tenant-id fix. ChangesCode Ownership Management
Benchmark Workflow Removal
Branch & Scorecard Gateworkflows
Reusable Rule Packaging (independent DAG)
Workflow Pinning, Hardening & Misc CI Changes
Release / Changelog / Milestone Flow Changes
Container Build Changes
Package, Versioning & Changelog
Application Logic
Sequence Diagram(s)sequenceDiagram
actor Caller as Caller
participant GH as GitHub Actions
participant Repo as Caller Repo
participant RuleExec as Rule-Executer Repo
participant Docker as DockerHub
participant Slack as Slack webhook
Caller->>GH: workflow_call(rule_number, rule_org, secrets)
GH->>Repo: checkout caller repo/context
GH->>GitHub: clone RuleExec (main/dev) using GH_TOKEN_LIB
GH->>Repo: copy rule-executer -> rewrite package.json & Dockerfile
GH->>GH: npm install / docker build
GH->>Docker: tag (version & latest/rc) -> push
GH->>Docker: remove local tags
GH->>Slack: POST notification (rule, version, link)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related issues
Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ci: remove bench.yml (dead code, no redesign planned)
…G GH_TOKEN from all build stages and replaces plain npm ci with RUN --mount=type=secret so the token is available only within that RUN step and is never recorded in image layer history (docker history). Part of the coordinated migration tracked in tazama-lf/workflows#52.
fix: use BuildKit secret for GH_TOKEN (tazama-lf/workflows#52)
Signed-off-by: Justus-at-Tazama <Justus-at-Tazama@users.noreply.github.com>
ci: sync workflows from central-workflows
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (6)
.github/workflows/milestone.yml (1)
40-45: Consider upgradingpeter-evans/repository-dispatchto a newer version.The action is pinned to v1, but v4 is the current major version. While SHA pinning provides security benefits, v1 lacks features and bug fixes present in newer versions.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/milestone.yml around lines 40 - 45, The workflow pins peter-evans/repository-dispatch to an old v1 SHA in the uses statement, which misses newer features and fixes; update the uses entry (the line containing "uses: peter-evans/repository-dispatch@ce5485de42c9b2622d2ed064be479e8ed65e76f4") to a current v4 reference (either a v4 tag like "@v4" or a v4 commit SHA) and ensure the rest of the input parameters (token, repository, event-type, client-payload) remain unchanged; if you prefer strict pinning, replace the SHA with a vetted v4 commit SHA instead of the v1 SHA..github/workflows/gpg-verify.yml (1)
30-33: Redundant environment variable assignment.The
env:block already makesPR_HEAD_REF,PR_BASE_REF,GH_TOKEN, andGH_REPOavailable to the step. Then they're re-exported to$GITHUB_ENVwith slightly different names (GITHUB_TOKEN,GITHUB_REPOSITORY). The subsequent step at line 36 uses$PR_BASE_REFand$PR_HEAD_REFdirectly (set via$GITHUB_ENV), but$GITHUB_TOKENand$GITHUB_REPOSITORYare already available as default environment variables.Consider simplifying by using the already-available
$GITHUB_TOKENand$GITHUB_REPOSITORYdirectly, or use consistent naming.💡 Suggested simplification
- name: Set up environment variables env: PR_HEAD_REF: ${{ github.event.pull_request.head.ref }} PR_BASE_REF: ${{ github.event.pull_request.base.ref }} - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - GH_REPO: ${{ github.repository }} run: | printf 'PR_HEAD_REF=%s\n' "$PR_HEAD_REF" >> "$GITHUB_ENV" printf 'PR_BASE_REF=%s\n' "$PR_BASE_REF" >> "$GITHUB_ENV" - printf 'GITHUB_TOKEN=%s\n' "$GH_TOKEN" >> "$GITHUB_ENV" - printf 'GITHUB_REPOSITORY=%s\n' "$GH_REPO" >> "$GITHUB_ENV"Then in the subsequent step, use
${{ secrets.GITHUB_TOKEN }}and${{ github.repository }}directly in theenv:block.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/gpg-verify.yml around lines 30 - 33, Remove the redundant re-exporting of variables into GITHUB_ENV: stop writing PR_HEAD_REF/PR_BASE_REF/GITHUB_TOKEN/GITHUB_REPOSITORY via printf to "$GITHUB_ENV"; instead rely on the step's env: inputs and GitHub-provided variables (use PR_HEAD_REF and PR_BASE_REF if you need those from env, and use the existing GITHUB_TOKEN / github.repository or secrets.GITHUB_TOKEN directly where required). Ensure naming is consistent (either keep PR_* names for PR refs or use GITHUB_REPOSITORY/GITHUB_TOKEN directly) and delete the printf lines that set GITHUB_TOKEN and GITHUB_REPOSITORY to avoid duplication..github/workflows/scorecard.yml (1)
52-55: Consider aligningcodeql-actionversions across workflows.This workflow uses
github/codeql-action/upload-sarif@38697555549f1db7851b81482ff19f1fa5c4fedc(v4.34.1), whilenjsscan.ymluses a different SHA marked as v3. Consider aligning versions for consistency, unless intentional.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/scorecard.yml around lines 52 - 55, The workflows use different pinned versions of the CodeQL upload action; update the upload action reference in this file (the uses entry "github/codeql-action/upload-sarif@38697555549f1db7851b81482ff19f1fa5c4fedc") to match the SHA/tag used in njsscan.yml (or vice‑versa) so both workflows use the same github/codeql-action/upload-sarif version; make sure the chosen SHA/tag corresponds to the intended release (e.g., v4.34.1) and update the uses string consistently in both workflow files..github/workflows/dockerhub-image-build.yml (1)
16-20: Workflow may trigger twice for releases.With both
push: branches: [main]andrelease: types: [published], if a release is created frommain, both triggers could fire. Consider if this is intentional or if the push trigger should be removed for release workflows.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/dockerhub-image-build.yml around lines 16 - 20, The workflow currently has two triggers—on: push: branches: [ "main" ] and on: release: types: [published ]—which can both fire when a release is created from main; decide which behavior you want and update the triggers accordingly: either remove the push trigger (delete the on: push block) so only release events run, or restrict push to non-release events (e.g., change push to tags or add an if: condition like github.event_name == 'push' on the job), or keep both but add a job-level conditional to skip when github.event_name == 'release'; update the on: push / on: release configuration and any job-level if conditions to enforce the chosen behavior..github/workflows/package-rule-rc.yml (1)
94-147: Significant code duplication withpackage-rule.yml.The modification logic (lines 94-147) is nearly identical to the stable workflow. Consider extracting this into a shared composite action or script to reduce maintenance burden and ensure consistency.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/package-rule-rc.yml around lines 94 - 147, The changes duplicate logic from package-rule.yml — extract the shared substitution/validation steps (the case on RULE_ORG, sed replacements for package.json and Dockerfile, the grep validations for "npm:${EXPECTED_SCOPE}/rule-${RULE_NUM}@${VERSION}", ENV RULE_NAME and ENV APM_SERVICE_NAME) into a single reusable unit (either a composite GitHub Action or an executable script invoked by both workflows) and replace the inline block in this file with a call to that unit; ensure the reusable unit accepts inputs RULE_DIR, RULE_NUM, RULE_ORG and VERSION and preserves the same sed/grep checks (including EXPECTED_SCOPE logic) so both workflows behave identically..github/workflows/release.yml (1)
86-90: Consider capturing and displaying curl errors for better debugging.The
--failflag will cause a non-zero exit on HTTP errors, but the error response body is discarded. When debugging milestone fetch failures, it would help to capture the response.♻️ Optional: Capture error response
- MILESTONE_RESPONSE=$(curl --fail -s -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" "https://api.github.com/repos/${{ github.repository }}/milestones/${MILESTONE_NUMBER}") + MILESTONE_RESPONSE=$(curl --fail -sS -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" "https://api.github.com/repos/${{ github.repository }}/milestones/${MILESTONE_NUMBER}") || { + echo "::error::Failed to fetch milestone ${MILESTONE_NUMBER}" + exit 1 + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 86 - 90, The current curl call uses --fail so HTTP error bodies are discarded; change the fetch for the milestone so you capture both the response body and HTTP status (e.g., call curl without --fail and use -w to capture the status into a separate variable), store the body in MILESTONE_RESPONSE and the status in a new variable (e.g., MILESTONE_STATUS), then check MILESTONE_STATUS for non-2xx responses and log/echo the full MILESTONE_RESPONSE (including the error payload) before exiting; keep the same Authorization header and repo URL and update the conditional that follows to use the new status check.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/release.yml:
- Line 143: The git log invocation that builds commit_messages uses color format
specifiers (%C(yellow) and %Creset) which emit ANSI codes into the changelog
file; update the git log --pretty=format string used to populate commit_messages
(the local commit_messages=$(git log ... $GIT_LOG_RANGE --grep="$section_label"
... ) line) to remove color markers and instead use a plain placeholder for the
commit hash (e.g., %H or %h) so the output written to the changelog file
contains only readable text without ANSI escape sequences.
In `@package.json`:
- Line 3: The PR title and the package.json "version" field are inconsistent (PR
title says v3.0.0 while package.json shows "4.0.0-rc.0"); update one so they
match: either change the PR title to "Release v4.0.0-rc.0" to reflect the
current package.json version or bump/downgrade the package.json "version" value
to "3.0.0" (or "3.0.0-rc.0" if you intend a release candidate) so it matches the
intended PR; ensure the chosen version string is used consistently in the commit
and changelog entries as well.
---
Nitpick comments:
In @.github/workflows/dockerhub-image-build.yml:
- Around line 16-20: The workflow currently has two triggers—on: push: branches:
[ "main" ] and on: release: types: [published ]—which can both fire when a
release is created from main; decide which behavior you want and update the
triggers accordingly: either remove the push trigger (delete the on: push block)
so only release events run, or restrict push to non-release events (e.g., change
push to tags or add an if: condition like github.event_name == 'push' on the
job), or keep both but add a job-level conditional to skip when
github.event_name == 'release'; update the on: push / on: release configuration
and any job-level if conditions to enforce the chosen behavior.
In @.github/workflows/gpg-verify.yml:
- Around line 30-33: Remove the redundant re-exporting of variables into
GITHUB_ENV: stop writing PR_HEAD_REF/PR_BASE_REF/GITHUB_TOKEN/GITHUB_REPOSITORY
via printf to "$GITHUB_ENV"; instead rely on the step's env: inputs and
GitHub-provided variables (use PR_HEAD_REF and PR_BASE_REF if you need those
from env, and use the existing GITHUB_TOKEN / github.repository or
secrets.GITHUB_TOKEN directly where required). Ensure naming is consistent
(either keep PR_* names for PR refs or use GITHUB_REPOSITORY/GITHUB_TOKEN
directly) and delete the printf lines that set GITHUB_TOKEN and
GITHUB_REPOSITORY to avoid duplication.
In @.github/workflows/milestone.yml:
- Around line 40-45: The workflow pins peter-evans/repository-dispatch to an old
v1 SHA in the uses statement, which misses newer features and fixes; update the
uses entry (the line containing "uses:
peter-evans/repository-dispatch@ce5485de42c9b2622d2ed064be479e8ed65e76f4") to a
current v4 reference (either a v4 tag like "@v4" or a v4 commit SHA) and ensure
the rest of the input parameters (token, repository, event-type, client-payload)
remain unchanged; if you prefer strict pinning, replace the SHA with a vetted v4
commit SHA instead of the v1 SHA.
In @.github/workflows/package-rule-rc.yml:
- Around line 94-147: The changes duplicate logic from package-rule.yml —
extract the shared substitution/validation steps (the case on RULE_ORG, sed
replacements for package.json and Dockerfile, the grep validations for
"npm:${EXPECTED_SCOPE}/rule-${RULE_NUM}@${VERSION}", ENV RULE_NAME and ENV
APM_SERVICE_NAME) into a single reusable unit (either a composite GitHub Action
or an executable script invoked by both workflows) and replace the inline block
in this file with a call to that unit; ensure the reusable unit accepts inputs
RULE_DIR, RULE_NUM, RULE_ORG and VERSION and preserves the same sed/grep checks
(including EXPECTED_SCOPE logic) so both workflows behave identically.
In @.github/workflows/release.yml:
- Around line 86-90: The current curl call uses --fail so HTTP error bodies are
discarded; change the fetch for the milestone so you capture both the response
body and HTTP status (e.g., call curl without --fail and use -w to capture the
status into a separate variable), store the body in MILESTONE_RESPONSE and the
status in a new variable (e.g., MILESTONE_STATUS), then check MILESTONE_STATUS
for non-2xx responses and log/echo the full MILESTONE_RESPONSE (including the
error payload) before exiting; keep the same Authorization header and repo URL
and update the conditional that follows to use the new status check.
In @.github/workflows/scorecard.yml:
- Around line 52-55: The workflows use different pinned versions of the CodeQL
upload action; update the upload action reference in this file (the uses entry
"github/codeql-action/upload-sarif@38697555549f1db7851b81482ff19f1fa5c4fedc") to
match the SHA/tag used in njsscan.yml (or vice‑versa) so both workflows use the
same github/codeql-action/upload-sarif version; make sure the chosen SHA/tag
corresponds to the intended release (e.g., v4.34.1) and update the uses string
consistently in both workflow files.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: c9280e76-f687-4443-ac23-078a66d3d703
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (24)
.github/CODEOWNERS.github/workflows/bench.yml.github/workflows/branch-target-check.yml.github/workflows/codacy.yml.github/workflows/codeql.yml.github/workflows/conventional-commits.yml.github/workflows/dco-check.yml.github/workflows/dependency-review.yml.github/workflows/dockerfile-linter.yml.github/workflows/dockerhub-image-build-rc.yml.github/workflows/dockerhub-image-build.yml.github/workflows/gpg-verify.yml.github/workflows/milestone.yml.github/workflows/njsscan.yml.github/workflows/package-rule-rc.yml.github/workflows/package-rule.yml.github/workflows/release.yml.github/workflows/sbom.yml.github/workflows/scorecard.ymlCHANGELOG.mdDockerfileVERSIONpackage.jsonsrc/services/services.ts
💤 Files with no reviewable changes (3)
- VERSION
- .github/workflows/bench.yml
- CHANGELOG.md
| local section_icon="$3" | ||
| # Get the commit messages with the specified label between the last release and the current release | ||
| local commit_messages=$(git log --pretty=format:"- %s (Linked Issues: %C(yellow)%H%Creset)" "$LAST_RELEASE_TAG..HEAD" --grep="$section_label" --no-merges --decorate --decorate-refs=refs/issues) | ||
| local commit_messages=$(git log --pretty=format:"- %s (Linked Issues: %C(yellow)%H%Creset)" $GIT_LOG_RANGE --grep="$section_label" --no-merges --decorate --decorate-refs=refs/issues) |
There was a problem hiding this comment.
Color escape codes will appear as literal text in the changelog file.
The %C(yellow) and %Creset format specifiers produce ANSI escape codes, which will render as garbled text in the changelog file (e.g., [33m...). Consider removing color codes since this output goes to a file, not a terminal.
🐛 Proposed fix
- local commit_messages=$(git log --pretty=format:"- %s (Linked Issues: %C(yellow)%H%Creset)" $GIT_LOG_RANGE --grep="$section_label" --no-merges --decorate --decorate-refs=refs/issues)
+ local commit_messages=$(git log --pretty=format:"- %s (Commit: %H)" $GIT_LOG_RANGE --grep="$section_label" --no-merges)📝 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.
Suggested change
| local commit_messages=$(git log --pretty=format:"- %s (Linked Issues: %C(yellow)%H%Creset)" $GIT_LOG_RANGE --grep="$section_label" --no-merges --decorate --decorate-refs=refs/issues) | |
| local commit_messages=$(git log --pretty=format:"- %s (Commit: %H)" $GIT_LOG_RANGE --grep="$section_label" --no-merges) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/release.yml at line 143, The git log invocation that
builds commit_messages uses color format specifiers (%C(yellow) and %Creset)
which emit ANSI codes into the changelog file; update the git log
--pretty=format string used to populate commit_messages (the local
commit_messages=$(git log ... $GIT_LOG_RANGE --grep="$section_label" ... ) line)
to remove color markers and instead use a plain placeholder for the commit hash
(e.g., %H or %h) so the output written to the changelog file contains only
readable text without ANSI escape sequences.
| { | ||
| "name": "typology-processor", | ||
| "version": "3.0.0", | ||
| "version": "4.0.0-rc.0", |
There was a problem hiding this comment.
PR title inconsistency with package version.
The PR title states "Release V3.0.0" but the package version is 4.0.0-rc.0. Consider aligning these to avoid confusion.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@package.json` at line 3, The PR title and the package.json "version" field
are inconsistent (PR title says v3.0.0 while package.json shows "4.0.0-rc.0");
update one so they match: either change the PR title to "Release v4.0.0-rc.0" to
reflect the current package.json version or bump/downgrade the package.json
"version" value to "3.0.0" (or "3.0.0-rc.0" if you intend a release candidate)
so it matches the intended PR; ensure the chosen version string is used
consistently in the commit and changelog entries as well.
Signed-off-by: Justus-at-Tazama <Justus-at-Tazama@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
.github/workflows/njsscan.yml (1)
46-46: Inconsistent codeql-action versions across workflows.This workflow pins
github/codeql-action/upload-sariftov4.35.1, whiledockerfile-linter.ymlpins it tov3. Consider aligning on a single major version across workflows for consistency and easier maintenance.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/njsscan.yml at line 46, The workflow pins github/codeql-action/upload-sarif to v4.35.1 which mismatches the dockerfile-linter.yml pin to v3; update the uses line (github/codeql-action/upload-sarif@60168ffe96596fce55ee3851b6bb7b2e1ea8dbb0) to the same major version used in dockerfile-linter.yml (or vice versa) so both workflows reference the same major tag (e.g., change to github/codeql-action/upload-sarif@v3 or update the other workflow to v4) to ensure consistent action versions across workflows..github/workflows/package-rule.yml (2)
97-120: Consider validatingrule_numberinput format.The
rule_orgis validated via the case statement, butrule_numberis used directly in sed commands and file paths without validation. While the description says it should be zero-padded (e.g., "001", "901"), a malformed input could cause unexpected behavior in sed substitutions or directory naming.🛡️ Proposed validation for rule_number
Add validation at the start of the step:
RULE_DIR="rule-executer-${{ inputs.rule_number }}" RULE_NUM="${{ inputs.rule_number }}" RULE_ORG="${{ inputs.rule_org }}" VERSION="${{ steps.rule_version.outputs.VERSION }}" + # Validate rule_number is a zero-padded numeric string + if ! [[ "$RULE_NUM" =~ ^[0-9]+$ ]]; then + echo "::error::rule_number must be numeric (got: '${RULE_NUM}')" + exit 1 + fi + echo "Applying substitutions for rule-${RULE_NUM} (org: ${RULE_ORG}, version: ${VERSION})"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/package-rule.yml around lines 97 - 120, The workflow uses RULE_NUM (RULE_DIR, RULE_ORG, and the sed substitutions) without validating the input RULE_NUMBER, which can break sed patterns and paths; add an early validation step that checks RULE_NUM matches the expected zero-padded numeric format (e.g., a regex like three digits) and exits with an error if it doesn't, before constructing RULE_DIR or running the sed commands, and update the error message to include the invalid RULE_NUMBER and expected format so the step fails fast and clearly.
185-217: Minor: JSON payload could break with unexpected characters in inputs.The Slack notification constructs JSON using string interpolation. If
rule_numberorVERSIONcontained quotes or special characters, the JSON would be malformed. While the version is validated and rule_number should be numeric, consider usingjqfor safer JSON construction.💡 Optional: Use jq for safer JSON construction
- name: Send Slack notification env: SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }} + RULE_NUM: ${{ inputs.rule_number }} + VERSION: ${{ steps.rule_version.outputs.VERSION }} run: | - curl -s -X POST -H 'Content-type: application/json' --data '{ - "blocks": [ - ... - ] - }' "$SLACK_WEBHOOK_URL" || true + PAYLOAD=$(jq -n \ + --arg rule "$RULE_NUM" \ + --arg version "$VERSION" \ + '{ + blocks: [ + {type: "header", text: {type: "plain_text", text: "New Rule stable Docker image published :white_check_mark:", emoji: true}}, + {type: "section", fields: [ + {type: "mrkdwn", text: "*Rule:*\nrule-\($rule)"}, + {type: "mrkdwn", text: "*Version:*\n\($version)"}, + {type: "mrkdwn", text: "*DockerHub:*\n<https://hub.docker.com/orgs/tazamaorg/repositories>"} + ]} + ] + }') + curl -s -X POST -H 'Content-type: application/json' --data "$PAYLOAD" "$SLACK_WEBHOOK_URL" || true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/package-rule.yml around lines 185 - 217, The Slack step "Send Slack notification" constructs JSON via string interpolation which can break if inputs.rule_number or steps.rule_version.outputs.VERSION contain quotes/special chars; change the step to build the payload safely (e.g., use jq or printf with proper escaping) and pass the resulting JSON to curl via SLACK_PAYLOAD or stdin; update references to rule-${{ inputs.rule_number }} and ${{ steps.rule_version.outputs.VERSION }} so they are fed into jq (or an escaped here-doc) rather than concatenated into raw JSON in the run script..github/workflows/package-rule-rc.yml (1)
94-147: Same recommendation: Consider validatingrule_numberinput format.This RC workflow has the same input validation gap as the stable workflow. The
rule_numberinput is used directly in sed commands and file paths without validation.🛡️ Proposed validation for rule_number
Add validation at the start of the step:
RULE_DIR="rule-executer-${{ inputs.rule_number }}" RULE_NUM="${{ inputs.rule_number }}" RULE_ORG="${{ inputs.rule_org }}" VERSION="${{ steps.rule_version.outputs.VERSION }}" + # Validate rule_number is a zero-padded numeric string + if ! [[ "$RULE_NUM" =~ ^[0-9]+$ ]]; then + echo "::error::rule_number must be numeric (got: '${RULE_NUM}')" + exit 1 + fi + echo "Applying substitutions for rule-${RULE_NUM} (org: ${RULE_ORG}, version: ${VERSION})"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/package-rule-rc.yml around lines 94 - 147, Validate the rule_number input before using RULE_NUM/RULE_DIR: ensure RULE_NUM is non-empty and matches an expected numeric pattern (e.g., only digits) and fail early with a clear error if it doesn't; add this check immediately after RULE_NUM="${{ inputs.rule_number }}" and before any sed/grep/file access so the subsequent uses in sed -i "...rule-${RULE_NUM}..." and file path construction RULE_DIR="rule-executer-${{ inputs.rule_number }}" are safe, and return a non-zero exit if the regex test (e.g., ^[0-9]+$) fails.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/gpg-verify.yml:
- Around line 30-33: Remove the lines that write GITHUB_TOKEN and
GITHUB_REPOSITORY into GITHUB_ENV; do not persist secrets to the environment
file. Instead, stop exporting GITHUB_TOKEN (GH_TOKEN) to GITHUB_ENV and pass the
token into the verification step via a step-level env: block (use the secret
directly, e.g., GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}), and rely on the
runner-provided GITHUB_REPOSITORY (do not write GH_REPO to GITHUB_ENV); update
any steps that referenced the env file to read the token from the step-level env
and the repo from the default GITHUB_REPOSITORY variable.
In @.github/workflows/njsscan.yml:
- Around line 41-47: The upload step's conditional uses steps.njsscan.outcome
which is set before continue-on-error and causes SARIF to be skipped when
njsscan finds issues; update the upload step condition to check
steps.njsscan.conclusion instead (or use a more permissive expression like
always() && steps.njsscan.outcome != 'skipped') so the GitHub SARIF upload runs
when the job is allowed to continue-on-error but not when the scan was skipped;
modify the `if:` on the Upload njsscan report step accordingly and keep the step
name/uses (Upload njsscan report / github/codeql-action/upload-sarif) unchanged.
---
Nitpick comments:
In @.github/workflows/njsscan.yml:
- Line 46: The workflow pins github/codeql-action/upload-sarif to v4.35.1 which
mismatches the dockerfile-linter.yml pin to v3; update the uses line
(github/codeql-action/upload-sarif@60168ffe96596fce55ee3851b6bb7b2e1ea8dbb0) to
the same major version used in dockerfile-linter.yml (or vice versa) so both
workflows reference the same major tag (e.g., change to
github/codeql-action/upload-sarif@v3 or update the other workflow to v4) to
ensure consistent action versions across workflows.
In @.github/workflows/package-rule-rc.yml:
- Around line 94-147: Validate the rule_number input before using
RULE_NUM/RULE_DIR: ensure RULE_NUM is non-empty and matches an expected numeric
pattern (e.g., only digits) and fail early with a clear error if it doesn't; add
this check immediately after RULE_NUM="${{ inputs.rule_number }}" and before any
sed/grep/file access so the subsequent uses in sed -i "...rule-${RULE_NUM}..."
and file path construction RULE_DIR="rule-executer-${{ inputs.rule_number }}"
are safe, and return a non-zero exit if the regex test (e.g., ^[0-9]+$) fails.
In @.github/workflows/package-rule.yml:
- Around line 97-120: The workflow uses RULE_NUM (RULE_DIR, RULE_ORG, and the
sed substitutions) without validating the input RULE_NUMBER, which can break sed
patterns and paths; add an early validation step that checks RULE_NUM matches
the expected zero-padded numeric format (e.g., a regex like three digits) and
exits with an error if it doesn't, before constructing RULE_DIR or running the
sed commands, and update the error message to include the invalid RULE_NUMBER
and expected format so the step fails fast and clearly.
- Around line 185-217: The Slack step "Send Slack notification" constructs JSON
via string interpolation which can break if inputs.rule_number or
steps.rule_version.outputs.VERSION contain quotes/special chars; change the step
to build the payload safely (e.g., use jq or printf with proper escaping) and
pass the resulting JSON to curl via SLACK_PAYLOAD or stdin; update references to
rule-${{ inputs.rule_number }} and ${{ steps.rule_version.outputs.VERSION }} so
they are fed into jq (or an escaped here-doc) rather than concatenated into raw
JSON in the run script.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5a7f602b-3b46-46be-8c2c-7df8fad7e8e2
📒 Files selected for processing (8)
.github/workflows/codacy.yml.github/workflows/dco-check.yml.github/workflows/dockerfile-linter.yml.github/workflows/gpg-verify.yml.github/workflows/njsscan.yml.github/workflows/package-rule-rc.yml.github/workflows/package-rule.yml.github/workflows/sbom.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/codacy.yml
- .github/workflows/sbom.yml
Comment on lines
+30
to
+33
| printf 'PR_HEAD_SHA=%s\n' "$PR_HEAD_SHA" >> "$GITHUB_ENV" | ||
| printf 'PR_BASE_SHA=%s\n' "$PR_BASE_SHA" >> "$GITHUB_ENV" | ||
| printf 'GITHUB_TOKEN=%s\n' "$GH_TOKEN" >> "$GITHUB_ENV" | ||
| printf 'GITHUB_REPOSITORY=%s\n' "$GH_REPO" >> "$GITHUB_ENV" |
There was a problem hiding this comment.
Avoid writing secrets to GITHUB_ENV.
Writing GITHUB_TOKEN to $GITHUB_ENV (line 32) persists the secret in a file, which is less secure than passing it via step-level env: blocks. GitHub's security guidance recommends against storing secrets in GITHUB_ENV.
Additionally, GITHUB_REPOSITORY (line 33) is already available as a default environment variable in GitHub Actions runners, making this write redundant.
🛡️ Suggested fix: Pass token directly to the verification step
Remove the token from GITHUB_ENV and pass it via step-level env::
run: |
printf 'PR_HEAD_SHA=%s\n' "$PR_HEAD_SHA" >> "$GITHUB_ENV"
printf 'PR_BASE_SHA=%s\n' "$PR_BASE_SHA" >> "$GITHUB_ENV"
- printf 'GITHUB_TOKEN=%s\n' "$GH_TOKEN" >> "$GITHUB_ENV"
- printf 'GITHUB_REPOSITORY=%s\n' "$GH_REPO" >> "$GITHUB_ENV"
- name: Check GPG verification status # Step to check each commit for GPG signature verification
+ env:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |GITHUB_REPOSITORY can be used directly without export as it's a default variable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/gpg-verify.yml around lines 30 - 33, Remove the lines that
write GITHUB_TOKEN and GITHUB_REPOSITORY into GITHUB_ENV; do not persist secrets
to the environment file. Instead, stop exporting GITHUB_TOKEN (GH_TOKEN) to
GITHUB_ENV and pass the token into the verification step via a step-level env:
block (use the secret directly, e.g., GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN
}}), and rely on the runner-provided GITHUB_REPOSITORY (do not write GH_REPO to
GITHUB_ENV); update any steps that referenced the env file to read the token
from the step-level env and the repo from the default GITHUB_REPOSITORY
variable.
Comment on lines
+41
to
+47
| continue-on-error: true | ||
| uses: ajinabraham/njsscan-action@d58d8b2f26322cd35a9efb8003baac517f226d81 | ||
| with: | ||
| args: '. --sarif --output results.sarif || true' | ||
| args: '. --sarif --output results.sarif' | ||
| - name: Upload njsscan report | ||
| uses: github/codeql-action/upload-sarif@v3 | ||
| uses: github/codeql-action/upload-sarif@60168ffe96596fce55ee3851b6bb7b2e1ea8dbb0 # v4.35.1 | ||
| if: steps.njsscan.outcome == 'success' |
There was a problem hiding this comment.
SARIF upload will be skipped when njsscan finds vulnerabilities.
The combination of continue-on-error: true (line 41) with if: steps.njsscan.outcome == 'success' (line 47) creates a logic flaw:
- When njsscan finds vulnerabilities, it may exit non-zero
outcomereflects the result beforecontinue-on-erroris applied (sooutcome='failure')conclusionreflects the result aftercontinue-on-erroris applied (soconclusion='success')- The condition checks
outcome, which will be'failure', causing the SARIF upload to be skipped
This means security findings won't be uploaded to GitHub's Code Scanning dashboard.
🐛 Proposed fix: use `conclusion` instead of `outcome`
- name: Upload njsscan report
uses: github/codeql-action/upload-sarif@60168ffe96596fce55ee3851b6bb7b2e1ea8dbb0 # v4.35.1
- if: steps.njsscan.outcome == 'success'
+ if: steps.njsscan.conclusion == 'success'
with:
sarif_file: results.sarif
category: njsscanAlternatively, if you want to upload regardless of scan result (but not when skipped):
if: always() && steps.njsscan.outcome != 'skipped'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/njsscan.yml around lines 41 - 47, The upload step's
conditional uses steps.njsscan.outcome which is set before continue-on-error and
causes SARIF to be skipped when njsscan finds issues; update the upload step
condition to check steps.njsscan.conclusion instead (or use a more permissive
expression like always() && steps.njsscan.outcome != 'skipped') so the GitHub
SARIF upload runs when the job is allowed to continue-on-error but not when the
scan was skipped; modify the `if:` on the Upload njsscan report step accordingly
and keep the step name/uses (Upload njsscan report /
github/codeql-action/upload-sarif) unchanged.
Signed-off-by: Sandy-at-Tazama <Sandy-at-Tazama@users.noreply.github.com>
ci: sync workflows from central-workflows
github-actions
Bot
added
enhancement
and removed
type: feature request
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/branch-target-check.yml:
- Around line 30-31: The current workflow conditional (if: github.actor !=
'dependabot[bot]' && github.actor != 'dependabot-preview[bot]') can be bypassed
by fork contributors naming their branch `dev` because github.head_ref is the
fork branch name; update the workflow file header comment to explicitly state
that this branch-name check is a developer experience guardrail and not a
security boundary, and add guidance that repository-level branch protection
rules (e.g., "Require a pull request before merging" and push restrictions) must
be configured on main to enforce actual security; mention the relevant
expressions (`github.head_ref`, `github.actor`) in the comment so readers
understand the limitation.
- Line 37: The branch check using SOURCE currently uses the overly-permissive
glob release/v[0-9]*; update the conditional to use an anchored ERE so only
dot-separated version segments match. Replace the condition that references
SOURCE (the line with [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]* ]])
with a regex match like [[ "$SOURCE" == "dev" || "$SOURCE" =~
^release/v[0-9]+(\.[0-9]+)*$ ]] so branches such as release/v1 or release/v1.2.3
match but release/v1/anything or release/v2-hotfix do not.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 539a2fd5-8076-4be6-8a3e-b060f8677760
📒 Files selected for processing (3)
.github/workflows/branch-target-check.yml.github/workflows/package-rule-rc.yml.github/workflows/package-rule.yml
🚧 Files skipped from review as they are similar to previous changes (2)
- .github/workflows/package-rule-rc.yml
- .github/workflows/package-rule.yml
Comment on lines
+30
to
+31
| if: github.actor != 'dependabot[bot]' && github.actor != 'dependabot-preview[bot]' | ||
| runs-on: ubuntu-latest |
There was a problem hiding this comment.
Fork contributors can bypass this check by naming their branch dev.
Since github.head_ref is the branch name in the fork, a contributor can create a branch named dev in their fork, open a PR targeting main, and this check will pass. This is a structural limitation of branch-name-based enforcement — it does not replace branch protection rules on the base repository.
This is acceptable as long as branch protection rules (e.g. "Require a pull request before merging", "Restrict who can push") are configured on main in addition to this workflow check. Consider adding a note to the header comment clarifying that this check is a DX guardrail, not a security boundary.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/branch-target-check.yml around lines 30 - 31, The current
workflow conditional (if: github.actor != 'dependabot[bot]' && github.actor !=
'dependabot-preview[bot]') can be bypassed by fork contributors naming their
branch `dev` because github.head_ref is the fork branch name; update the
workflow file header comment to explicitly state that this branch-name check is
a developer experience guardrail and not a security boundary, and add guidance
that repository-level branch protection rules (e.g., "Require a pull request
before merging" and push restrictions) must be configured on main to enforce
actual security; mention the relevant expressions (`github.head_ref`,
`github.actor`) in the comment so readers understand the limitation.
| env: | ||
| SOURCE: ${{ github.head_ref }} | ||
| run: | | ||
| if [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]* ]]; then |
There was a problem hiding this comment.
Bash glob release/v[0-9]* is more permissive than intended.
In bash [[ ]] pattern matching, * matches any string including /, so branches like release/v1/anything or release/v2-hotfix would pass the check. The documentation comments (lines 7, 13) describe the intent as release/v<N>.* (e.g. release/v1.2), meaning a dot-separated version after the major number. Consider tightening the glob to match the documented contract:
🔧 Proposed tighter pattern
- if [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]* ]]; then
+ if [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]*([0-9.])[0-9] ]]; thenOr, if you want to permit release/v1, release/v1.2, release/v1.2.3, etc., a simpler and readable approach:
- if [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]* ]]; then
+ if [[ "$SOURCE" == "dev" ]] || [[ "$SOURCE" =~ ^release/v[0-9]+(\.[0-9]+)*$ ]]; thenThe =~ operator in [[ ]] uses ERE (extended regular expressions), which is more expressive and anchored with ^/$ to prevent partial matches.
📝 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.
Suggested change
| if [[ "$SOURCE" == "dev" || "$SOURCE" == release/v[0-9]* ]]; then | |
| if [[ "$SOURCE" == "dev" ]] || [[ "$SOURCE" =~ ^release/v[0-9]+(\.[0-9]+)*$ ]]; then |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/branch-target-check.yml at line 37, The branch check using
SOURCE currently uses the overly-permissive glob release/v[0-9]*; update the
conditional to use an anchored ERE so only dot-separated version segments match.
Replace the condition that references SOURCE (the line with [[ "$SOURCE" ==
"dev" || "$SOURCE" == release/v[0-9]* ]]) with a regex match like [[ "$SOURCE"
== "dev" || "$SOURCE" =~ ^release/v[0-9]+(\.[0-9]+)*$ ]] so branches such as
release/v1 or release/v1.2.3 match but release/v1/anything or release/v2-hotfix
do not.
Signed-off-by: Justus-at-Tazama <Justus-at-Tazama@users.noreply.github.com>
ci: sync workflows from central-workflows
Signed-off-by: Sandy-at-Tazama <Sandy-at-Tazama@users.noreply.github.com>
ci: sync workflows from central-workflows [skip ci]
Signed-off-by: Justus-at-Tazama <Justus-at-Tazama@users.noreply.github.com>
ci: sync workflows from central-workflows [skip ci]
* fix: frms version * fix: bump frms-coe-lib to 8.0.0-rc.1 * fix: bump frms-coe-startup-lib to 3.0.2-rc.3 * fix: defensive else-branch, root-export import, ESLint bump, dependabot target-branch - src/logic.service.ts: if/if chain replaced with if/else if/else; let transactionId uninitialised to enforce TypeScript definite assignment; explicit loggerService.error and return on unrecognised transaction type; import moved to frms-coe-lib root export - __tests__/unit/logic.service.test.ts: unsupported-type test added (35 -> 36 tests) - package.json: eslint bumped from ^9.36.0 to ^9.39.4 (fixes unified-signatures crash) - .github/dependabot.yml: target-branch set to dev Closes #401 --------- Co-authored-by: Justus-at-Tazama <jortlepp@contractor.linuxfoundation.org>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| ARG GH_TOKEN | ||
|
|
||
| RUN npm ci --ignore-scripts | ||
| RUN --mount=type=secret,id=GH_TOKEN,env=GH_TOKEN npm ci --ignore-scripts |
|
|
||
| jobs: | ||
| encoding-check: | ||
| permissions: |
Contributor
|
Stale |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 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.
SPDX-License-Identifier: Apache-2.0
What did we change?
Initiate Tazama Release V3.0.0.
How was it tested?
Summary by CodeRabbit
New Features
Bug Fixes
Chores