Conversation
|
Warning Review limit reached
Next review available in: 20 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe pull request modernizes sbt and CI workflows, adds Scalafmt and version-policy configuration, updates selected dependency versions, and applies formatting-only changes across Scala production and test sources. ChangesBuild and formatting modernization
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
coverage: 44.327% (+9.8%) from 34.492% — m/updates into master |
1 similar comment
|
coverage: 44.327% (+9.8%) from 34.492% — m/updates into master |
|
coverage: 44.327% (+9.8%) from 34.492% — m/updates into master |
![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
🤖 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/release.yml:
- Around line 10-11: Update the release workflow reference to the exact commit
b4557d9a82c03596dc2425e19b3cb9a6280a4739 instead of `@v5`, replace secrets:
inherit with an explicit JFROG_ACCESS_TOKEN mapping, and declare
JFROG_ACCESS_TOKEN under the called workflow’s on.workflow_call.secrets
configuration.
🪄 Autofix
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 Plus
Run ID: 9006f451-39b9-49d7-a030-974f8b1ed3aa
📒 Files selected for processing (40)
.github/workflows/ci.yml.github/workflows/release.yml.scalafmt.confbuild.sbtcluster/src/main/scala/com/evolutiongaming/cluster/AddressHelper.scalacluster/src/main/scala/com/evolutiongaming/cluster/LocalSupervisorActor.scalacluster/src/main/scala/com/evolutiongaming/cluster/LogUnreachable.scalacluster/src/main/scala/com/evolutiongaming/cluster/NodesUnreachableException.scalainstrumentation/src/main/scala/akka/dispatch/InstrumentedDispatcherMixin.scalainstrumentation/src/main/scala/akka/dispatch/OverrideAkkaRunnable.scalainstrumentation/src/main/scala/com/evolutiongaming/util/dispatchers/AbstractInstrumentedDispatcher.scalainstrumentation/src/main/scala/com/evolutiongaming/util/dispatchers/AbstractInstrumentedPinned.scalainstrumentation/src/main/scala/com/evolutiongaming/util/dispatchers/Instrumented.scalainstrumentation/src/main/scala/com/evolutiongaming/util/dispatchers/InstrumentedConfig.scalapersistence/src/main/scala/akka/persistence/JournalFailure.scalapersistence/src/main/scala/akka/persistence/RecoveryBreaker.scalapersistence/src/main/scala/akka/persistence/Replicate.scalapersistence/src/main/scala/com/evolutiongaming/persistence/PersistenceId.scalapersistence/src/main/scala/com/evolutiongaming/sharding/ShardEntry.scalapersistence/src/main/scala/com/evolutiongaming/util/DuplicatingJournal.scalapersistence/src/test/scala/akka/persistence/DuplicatingActorSpec.scalapersistence/src/test/scala/akka/persistence/RecoveryBreakerSpec.scalapersistence/src/test/scala/com/evolutiongaming/persistence/PersistenceIdSpec.scalaproject/Dependencies.scalaproject/build.propertiesproject/plugins.sbtserialization/src/main/scala/com/evolutiongaming/serialization/BrokenSerializer.scalaserialization/src/main/scala/com/evolutiongaming/serialization/SerializerOf.scalatest/src/main/scala/com/evolutiongaming/test/ActorSpec.scalatest/src/main/scala/com/evolutiongaming/test/PatienceConfiguration.scalatest/src/main/scala/com/evolutiongaming/test/TestConfig.scalatest/src/main/scala/com/evolutiongaming/test/package.scalautil/src/main/scala/com/evolutiongaming/util/BackpressureBuffer.scalautil/src/main/scala/com/evolutiongaming/util/BlockingTracker.scalautil/src/main/scala/com/evolutiongaming/util/ExecutionThreadTracker.scalautil/src/main/scala/com/evolutiongaming/util/FutureSequentialForKey.scalautil/src/main/scala/com/evolutiongaming/util/Scheduler.scalautil/src/test/scala/com/evolutiongaming/util/BackpressureBufferSpec.scalautil/src/test/scala/com/evolutiongaming/util/FutureSequentialForKeySpec.scalaversion.sbt
💤 Files with no reviewable changes (1)
- version.sbt
| uses: evolution-gaming/scala-github-actions/.github/workflows/release.yml@v5 | ||
| secrets: inherit |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
repo="evolution-gaming/scala-github-actions"
sha="$(gh api "repos/$repo/commits/v5" --jq .sha)"
printf 'Current v5 commit: %s\n' "$sha"
gh api "repos/$repo/contents/.github/workflows/release.yml?ref=$sha" \
--jq .content | base64 --decodeRepository: evolution-gaming/akka-tools
Length of output: 2253
🏁 Script executed:
#!/bin/bash
set -euo pipefail
repo="evolution-gaming/scala-github-actions"
printf '%s\n' 'Tag reference:'
gh api "repos/$repo/git/ref/tags/v5" --jq '{type: .object.type, sha: .object.sha}'
printf '%s\n' 'Resolved commit:'
tag_obj="$(gh api "repos/$repo/git/ref/tags/v5" --jq '.object | [.type, .sha] | `@tsv`')"
tag_type="${tag_obj%%$'\t'*}"
tag_sha="${tag_obj#*$'\t'}"
if [ "$tag_type" = tag ]; then
commit_sha="$(gh api "repos/$repo/git/tags/$tag_sha" --jq '.object | select(.type == "commit") | .sha')"
else
commit_sha="$tag_sha"
fi
gh api "repos/$repo/commits/$commit_sha" --jq .sha
printf 'v5 commit: %s\n' "$commit_sha"
printf '%s\n' 'Caller workflow:'
cat -n .github/workflows/release.yml | sed -n '1,35p'
printf '%s\n' 'Workflow references and secret declarations:'
rg -n --hidden -g '.github/workflows/*.yml' -g '.github/workflows/*.yaml' \
'scala-github-actions/.github/workflows/release\.yml|secrets:|JFROG_ACCESS_TOKEN|GITHUB_TOKEN' .Repository: evolution-gaming/akka-tools
Length of output: 846
🌐 Web query:
GitHub Actions reusable workflow secrets inherit explicit secrets workflow_call declaration caller passing secret not defined
💡 Result:
In GitHub Actions, a reusable workflow does not automatically inherit secrets from the calling workflow [1][2][3]. To make secrets available, you must explicitly configure how they are passed. There are two primary methods to achieve this, depending on whether you want to pass specific secrets or grant access to all available secrets [1][4]. 1. Explicit Passing (Recommended for Security): You can pass specific secrets by mapping them in the calling workflow's job definition [4][5][6]. - In the caller workflow, use the secrets keyword: jobs: call_workflow: uses: owner/repo/.github/workflows/reusable.yml@main secrets: SECRET_NAME: ${{ secrets.SECRET_NAME }} - In the reusable workflow, you must define these expected secrets under the on.workflow_call.secrets block [7][1][2]: on: workflow_call: secrets: SECRET_NAME: required: true 2. Inheritance (secrets: inherit): For workflows within the same organization or enterprise, you can use the inherit keyword to automatically pass all secrets available to the calling workflow to the reusable workflow [8][9]. - In the caller workflow: jobs: call_workflow: uses: owner/repo/.github/workflows/reusable.yml@main secrets: inherit - Important Behavior: When using secrets: inherit, you are not required to explicitly define the secrets in the reusable workflow's on.workflow_call block to access them [8][10][11]. However, this method is less secure because it exposes all secrets available to the caller to the reusable workflow, increasing the potential blast radius if the downstream workflow is compromised [5][3][6]. Key Considerations: - Secret Scope: Secrets are only passed to the directly called workflow [9][3]. In a chain of workflows (A -> B -> C), secrets must be passed from A to B, and then from B to C [9][3]. - Environment Secrets: Environment-level secrets cannot be passed using on.workflow_call [8][11]. If a reusable workflow job specifies an environment, it will use the environment's secrets rather than any secrets passed from the caller [8][11]. - Best Practice: Explicitly naming and passing only the necessary secrets is considered the best practice to maintain the principle of least privilege [5][3][6]. Use secrets: inherit only when the reusable workflow is fully trusted and requires broad secret access [5][3].
Citations:
- 1: https://latchkey.dev/learn/github-actions/reusable-workflow-secrets-inherit-not-passed-in-ci
- 2: https://latchkey.dev/learn/github-actions/github-actions-reusable-workflow-secret-not-inherited
- 3: https://qaskills.sh/blog/ci-workflow-reusable-inputs-secrets
- 4: https://sadamkhan.spiralsync.com/blog/quick-tips/github-actions-reusable-workflows
- 5: https://adaptive-enforcement-lab.com/secure/github-actions-security/workflows/reusable/secret-patterns/
- 6: https://actsense.dev/vulnerabilities/secrets_inherit/
- 7: https://stackoverflow.com/questions/74263511/unable-to-access-repository-secrets-in-reusable-workflows
- 8: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 9: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows
- 10: https://stackoverflow.com/questions/71524542/how-to-use-reusable-github-workflows-and-keep-secrets-in-a-single-place
- 11: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
Pin the release workflow and scope its secrets.
Pin @v5 to b4557d9a82c03596dc2425e19b3cb9a6280a4739. Replace secrets: inherit with an explicit JFROG_ACCESS_TOKEN mapping, and declare that secret in the called workflow’s on.workflow_call.secrets section.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 10-10: secrets unconditionally inherited by called workflow (secrets-inherit): this reusable workflow
(secrets-inherit)
🤖 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/release.yml around lines 10 - 11, Update the release
workflow reference to the exact commit b4557d9a82c03596dc2425e19b3cb9a6280a4739
instead of `@v5`, replace secrets: inherit with an explicit JFROG_ACCESS_TOKEN
mapping, and declare JFROG_ACCESS_TOKEN under the called workflow’s
on.workflow_call.secrets configuration.
Source: Linters/SAST tools
|
2 participants
Summary by CodeRabbit
Build and Release
Maintenance