Open
Conversation
On-behalf-of: @SAP angel.kafazov@sap.com Signed-off-by: Angel Kafazov <akafazov@cst-bg.net>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds three reusable GitHub Actions workflows for Node release orchestration and GitHub Releases, a cross-repository release dispatcher using a GitHub App installation token, and flips a pipeline input default to make publishing opt-in. Changes
Sequence Diagram(s)sequenceDiagram
participant Caller as Caller (workflow_call)
participant Reusable as Release Node Workflow
participant BuildWF as job-node-test.yml
participant PublishWF as job-node-publish.yml
participant GHRelease as job-github-release.yml
Caller->>Reusable: invoke(version, environment, ...)
Reusable->>BuildWF: run build (hasBuild, artifactPath, node_version)
BuildWF-->>Reusable: artifacts / status
Reusable->>PublishWF: run publish (version, artifacts, publishFromDist, environment)
PublishWF-->>Reusable: publish result
Reusable->>GHRelease: create/update GitHub Release (version)
GHRelease-->>Reusable: release created/updated
sequenceDiagram
participant User as User (workflow_dispatch)
participant Trigger as release-openmfp.yml
participant GitHubApp as actions/create-github-app-token
participant GHCLI as gh (GitHub CLI)
participant RepoA as openmfp/portal-ui-lib
participant RepoB as openmfp/portal-server-lib
User->>Trigger: trigger with version
Trigger->>GitHubApp: create installation token (app-id, private key)
GitHubApp-->>Trigger: returns token (GITHUB_TOKEN)
Trigger->>GHCLI: gh workflow run release.yml `@RepoA` (VERSION)
Trigger->>GHCLI: poll & watch run for RepoA
Trigger->>GHCLI: gh workflow run release.yml `@RepoB` (VERSION)
Trigger->>GHCLI: poll & watch run for RepoB
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
akafazov
changed the title
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
On-behalf-of: @SAP angel.kafazov@sap.com Signed-off-by: Angel Kafazov <akafazov@cst-bg.net>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/release-openmfp.yml (1)
11-13:⚠️ Potential issue | 🟡 MinorAdd explicit permissions block.
The workflow should define an explicit
permissionsblock to limit the defaultGITHUB_TOKENscope, even though you're using a GitHub App token for the actual operations. This follows the principle of least privilege.🔒 Proposed fix
jobs: trigger-releases: runs-on: ubuntu-latest + permissions: + contents: read steps:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-openmfp.yml around lines 11 - 13, Add an explicit top-level permissions block to the release-openmfp.yml workflow to limit the default GITHUB_TOKEN scope for the trigger-releases job; update the workflow (release-openmfp.yml) to include a minimal permissions section (for example: permissions: contents: read and other scopes set to none or only those required) so the trigger-releases job runs with least privilege while your GitHub App token is still used for actual operations.
🧹 Nitpick comments (2)
.github/workflows/pipeline-node-module.yml (1)
64-71: Consider forwardingpublishinput tojob-node-test.yml.The
buildjob does not forward thepublishinput tojob-node-test.yml. Sincejob-node-test.ymldefaultspublishtotrue(per.github/workflows/job-node-test.yml:27-31), artifacts will be uploaded even when this pipeline runs withpublish: false. This causes unnecessary artifact uploads during non-publishing builds.♻️ Proposed fix to forward publish input
build: uses: ./.github/workflows/job-node-test.yml secrets: inherit with: workingDirectory: ${{ inputs.workingDirectory }} release_branch: ${{ inputs.release_branch }} artifactPath: ${{ inputs.artifactPath }} hasBuild: ${{ inputs.hasBuild }} + publish: ${{ inputs.publish }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/pipeline-node-module.yml around lines 64 - 71, The build job currently calls the reusable workflow job-node-test.yml but does not forward the publish input, so the reusable workflow's default publish=true persists; update the build job's with-block to forward the publish input (add publish: ${{ inputs.publish }}) so the publish flag from this pipeline is respected when invoking job-node-test.yml..github/workflows/release-openmfp.yml (1)
22-32: Consider using a matrix strategy to reduce duplication.The repository list is duplicated in the token scope (lines 22-24) and the release trigger steps (lines 26, 30). A matrix strategy would make it easier to add or remove repositories.
♻️ Alternative approach using matrix
jobs: trigger-releases: runs-on: ubuntu-latest strategy: matrix: repo: [portal-ui-lib, portal-server-lib] fail-fast: true steps: - name: Generate a token id: generate-token uses: actions/create-github-app-token@f8d387b68d61c58ab83c6c016672934102569859 # v3 with: app-id: "838464" private-key: ${{ secrets.OPENMFP_PUBLISHER_PRIVATE_KEY }} owner: ${{ github.repository_owner }} repositories: ${{ matrix.repo }} - name: Release ${{ matrix.repo }} run: gh workflow run release.yml --repo openmfp/${{ matrix.repo }} --field version="${{ inputs.version }}" env: GITHUB_TOKEN: ${{ steps.generate-token.outputs.token }}Note: This runs releases in parallel. If you need sequential execution, use a different approach or set
max-parallel: 1in the strategy.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-openmfp.yml around lines 22 - 32, Replace the duplicated repository listing and duplicated release steps by converting the trigger-releases job to use a strategy.matrix (e.g., matrix.repo) so the Generate a token step (id: generate-token) uses repositories: ${{ matrix.repo }} and the release step (currently named "Release portal-ui-lib" / "Release portal-server-lib") runs once per matrix entry with run: gh workflow run release.yml --repo openmfp/${{ matrix.repo }} --field version="${{ inputs.version }}" and env GITHUB_TOKEN from steps.generate-token.outputs.token; set fail-fast and/or max-parallel: 1 on the strategy if you need sequential execution.
🤖 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/job-release-node.yml:
- Around line 52-61: Add a release_branch input to the workflow's build job and
forward it to the reusable workflow so artifacts can be published from non-main
branches: update the jobs.build inputs to include release_branch: ${{
inputs.release_branch }} (matching the existing pattern for
workingDirectory/artifactPath/hasBuild/node_version/publish) so the reusable
workflow job-node-test.yml receives inputs.release_branch; follow the same
wiring used in pipeline-node-module.yml to ensure the artifact upload condition
checks the correct branch.
---
Duplicate comments:
In @.github/workflows/release-openmfp.yml:
- Around line 11-13: Add an explicit top-level permissions block to the
release-openmfp.yml workflow to limit the default GITHUB_TOKEN scope for the
trigger-releases job; update the workflow (release-openmfp.yml) to include a
minimal permissions section (for example: permissions: contents: read and other
scopes set to none or only those required) so the trigger-releases job runs with
least privilege while your GitHub App token is still used for actual operations.
---
Nitpick comments:
In @.github/workflows/pipeline-node-module.yml:
- Around line 64-71: The build job currently calls the reusable workflow
job-node-test.yml but does not forward the publish input, so the reusable
workflow's default publish=true persists; update the build job's with-block to
forward the publish input (add publish: ${{ inputs.publish }}) so the publish
flag from this pipeline is respected when invoking job-node-test.yml.
In @.github/workflows/release-openmfp.yml:
- Around line 22-32: Replace the duplicated repository listing and duplicated
release steps by converting the trigger-releases job to use a strategy.matrix
(e.g., matrix.repo) so the Generate a token step (id: generate-token) uses
repositories: ${{ matrix.repo }} and the release step (currently named "Release
portal-ui-lib" / "Release portal-server-lib") runs once per matrix entry with
run: gh workflow run release.yml --repo openmfp/${{ matrix.repo }} --field
version="${{ inputs.version }}" and env GITHUB_TOKEN from
steps.generate-token.outputs.token; set fail-fast and/or max-parallel: 1 on the
strategy if you need sequential execution.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 4b228c40-9c5b-48e7-806f-e63badf8ee2b
📒 Files selected for processing (4)
.github/workflows/job-github-release.yml.github/workflows/job-release-node.yml.github/workflows/pipeline-node-module.yml.github/workflows/release-openmfp.yml
Pass inputs.version through an environment variable instead of interpolating it directly into the shell script, avoiding injection via crafted workflow_dispatch input values. Signed-off-by: Bastian Echterhölter <bastian.echterhoelter@sap.com> On-behalf-of: @SAP <bastian.echterhoelter@sap.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/release-openmfp.yml (1)
11-13:⚠️ Potential issue | 🟠 MajorAdd explicit
permissionsto restrict default token scope.This workflow omits a
permissionsblock, soGITHUB_TOKENgets broader default scopes than necessary. Even though release dispatch uses the app token, lock down workflow/job permissions explicitly.Suggested hardening
name: Release OpenMFP on: workflow_dispatch: @@ +permissions: {} + jobs: trigger-releases: runs-on: ubuntu-latest🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-openmfp.yml around lines 11 - 13, Add an explicit permissions block to the workflow or to the trigger-releases job to restrict the GITHUB_TOKEN scope (e.g., set minimal permissions like contents: read, actions: read, id-token: write only as required) instead of relying on broad defaults; update the jobs.trigger-releases definition to include a permissions mapping so the GITHUB_TOKEN used by this workflow is limited to the least privilege necessary.
🤖 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-openmfp.yml:
- Around line 25-34: The workflow currently dispatches "Release portal-ui-lib"
and immediately dispatches "Release portal-server-lib" (using gh workflow run),
which is asynchronous and doesn't gate on success; modify the "Release
portal-ui-lib" step to capture the run URL/ID returned by gh workflow run (or
parse output), then wait for that run to finish and verify success (e.g. with gh
run watch / gh run view --json status/conclusion or by polling the run URL)
before executing the "Release portal-server-lib" step; keep the existing env
inputs.version and generated token usage but only run the second gh workflow run
after confirming the first run's conclusion is successful.
---
Duplicate comments:
In @.github/workflows/release-openmfp.yml:
- Around line 11-13: Add an explicit permissions block to the workflow or to the
trigger-releases job to restrict the GITHUB_TOKEN scope (e.g., set minimal
permissions like contents: read, actions: read, id-token: write only as
required) instead of relying on broad defaults; update the jobs.trigger-releases
definition to include a permissions mapping so the GITHUB_TOKEN used by this
workflow is limited to the least privilege necessary.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 31db21c3-b73d-4c25-a3a5-3ffa56a0e719
📒 Files selected for processing (1)
.github/workflows/release-openmfp.yml
gh workflow run is fire-and-forget. Record a timestamp before triggering, poll for the new run ID, then use gh run watch --exit-status to block until completion. If portal-ui-lib fails, portal-server-lib is never triggered. Signed-off-by: Bastian Echterhölter <bastian.echterhoelter@sap.com> On-behalf-of: @SAP <bastian.echterhoelter@sap.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/release-openmfp.yml (1)
11-13:⚠️ Potential issue | 🟠 MajorAdd explicit
permissionsfor least privilege.There is still no workflow/job
permissionsblock, soGITHUB_TOKENgets default scopes. Please set explicit minimal permissions.🔐 Suggested patch
name: Release OpenMFP on: workflow_dispatch: @@ jobs: trigger-releases: + permissions: + contents: read runs-on: ubuntu-latest steps:🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release-openmfp.yml around lines 11 - 13, The workflow job "trigger-releases" lacks an explicit permissions block so GITHUB_TOKEN gets default overly-broad scopes; add a permissions entry under the job (jobs.trigger-releases) that declares only the minimal scopes needed for this release workflow (for example, restrict to contents: read, packages: write, id-token: write or whatever specific actions you actually use) and remove any other default privileges—adjust the exact permission keys to match the actions used in the job.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In @.github/workflows/release-openmfp.yml:
- Around line 11-13: The workflow job "trigger-releases" lacks an explicit
permissions block so GITHUB_TOKEN gets default overly-broad scopes; add a
permissions entry under the job (jobs.trigger-releases) that declares only the
minimal scopes needed for this release workflow (for example, restrict to
contents: read, packages: write, id-token: write or whatever specific actions
you actually use) and remove any other default privileges—adjust the exact
permission keys to match the actions used in the job.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 2f14819b-748c-4c56-98a9-f0613cee1dd1
📒 Files selected for processing (1)
.github/workflows/release-openmfp.yml
Add explicit empty permissions block to release-openmfp.yml to restrict default GITHUB_TOKEN scope per least privilege principle. Add release_branch input to job-release-node.yml and forward it to job-node-test.yml so artifact uploads work for non-main branches. Signed-off-by: Bastian Echterhölter <bastian.echterhoelter@sap.com> On-behalf-of: @SAP <bastian.echterhoelter@sap.com>
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
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Changes
job-github-releaseandjob-release-node) to create github release for individual core repositoryrelease-openmfp) to trigger new releaseHow it works
Continuous Build Flow
mainnever publish to npmjs (publishdefaults tofalse)Release Flow
release-openmfp.ymlis the single manual entry point for a coordinated releaseportal-ui-libfails,portal-server-libis not triggeredImplements openmfp/portal#741
Summary by CodeRabbit