Conversation
📝 WalkthroughWalkthroughThe pull request updates Scala, SBT, dependency, and plugin versions. It expands Scalafmt configuration, reformats Scala sources, removes Scalafix configuration, and updates CI workflow references. ChangesToolchain modernization
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Comment |
![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
🤖 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:
- Line 10: Update the reusable workflow reference in the release workflow to pin
commit b4557d9a82c03596dc2425e19b3cb9a6280a4739 instead of the v5 tag, and
replace secrets: inherit with an explicit mapping that passes only
JFROG_ACCESS_TOKEN while retaining the automatic GITHUB_TOKEN.
In @.scalafmt.conf:
- Around line 81-86: Update the rewrite.rules entry in .scalafmt.conf to use the
registered PreferCurlyFors rule name instead of the unrecognized lowercase
prefercurlyfors value, preserving the other configured rules.
🪄 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: c7a558b8-6d1e-4e66-9ba7-dfb33c5d9dcc
📒 Files selected for processing (12)
.github/workflows/ci.yml.github/workflows/release.yml.scalafix.conf.scalafmt.confbuild.sbtproject/Dependencies.scalaproject/build.propertiesproject/plugins.sbtsrc/main/scala-2/com/evolutiongaming/random/Random.scalasrc/main/scala-3/com/evolutiongaming/random/Random.scalasrc/main/scala/com/evolutiongaming/random/RandomStateOf.scalasrc/main/scala/com/evolutiongaming/random/SeedOf.scala
💤 Files with no reviewable changes (2)
- .github/workflows/ci.yml
- .scalafix.conf
| jobs: | ||
| release: | ||
| uses: evolution-gaming/scala-github-actions/.github/workflows/release.yml@v3 | ||
| uses: evolution-gaming/scala-github-actions/.github/workflows/release.yml@v5 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
repo="https://github.com/evolution-gaming/scala-github-actions.git"
sha="$(git ls-remote "$repo" 'refs/tags/v5^{}' | awk '{print $1}')"
: "${sha:=$(git ls-remote "$repo" 'refs/tags/v5' | awk '{print $1}')}"
test -n "$sha"
echo "v5 resolves to $sha"
curl -fsSL "https://raw.githubusercontent.com/evolution-gaming/scala-github-actions/$sha/.github/workflows/release.yml"Repository: evolution-gaming/random
Length of output: 2245
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- caller workflow ---'
cat -n .github/workflows/release.yml
printf '%s\n' '--- repository references to the reusable workflow and secrets ---'
rg -n -C 3 'scala-github-actions|secrets:|JFROG_ACCESS_TOKEN|permissions:' .github/workflows .github 2>/dev/null || trueRepository: evolution-gaming/random
Length of output: 1573
🌐 Web query:
GitHub Actions reusable workflow secrets inherit secret not defined workflow_call contract
💡 Result:
In GitHub Actions, you can pass secrets to a reusable workflow using either explicit mapping or the inherit keyword [1][2]. When using secrets: inherit in the calling workflow, all secrets from the caller are implicitly passed to the reusable workflow [1][3]. A key behavior of this method is that it bypasses the need to explicitly define the secrets in the workflow_call trigger of the reusable workflow [1][4]. You can access these inherited secrets directly within the reusable workflow using the ${{ secrets.SECRET_NAME }} syntax, even if they are not listed in the on.workflow_call.secrets contract [1][2]. If you choose not to use secrets: inherit, you must explicitly pass each required secret in the calling workflow and define those secrets in the on.workflow_call.secrets block of the reusable workflow [5][6]. Important considerations regarding secret inheritance include: 1. Scope and Access: Secrets are only passed to directly called workflows. In a workflow chain (A > B > C), workflow C will only receive secrets from A if they are explicitly passed or inherited through each step in the chain [1][2]. 2. Environment Secrets: The on.workflow_call trigger does not support the environment keyword [1][7]. Environment secrets are not passed automatically from the caller; instead, if a reusable workflow job references an environment, it will use the environment secrets defined in the repository where the reusable workflow resides [1][7]. 3. Security: The inherit keyword provides a convenient way to share secrets, but ensure that the reusable workflow is intended to have access to all secrets available to the caller [1][3].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 3: https://github.blog/changelog/2022-05-03-github-actions-simplify-using-secrets-with-reusable-workflows/
- 4: https://stackoverflow.com/questions/71524542/how-to-use-reusable-github-workflows-and-keep-secrets-in-a-single-place
- 5: https://stackoverflow.com/questions/74263511/unable-to-access-repository-secrets-in-reusable-workflows
- 6: https://latchkey.dev/learn/github-actions/github-actions-reusable-workflow-secret-not-inherited
- 7: https://docs.github.com/en/enterprise-server@3.17/actions/how-tos/reuse-automations/reuse-workflows
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
repo="evolution-gaming/scala-github-actions"
tag="v5"
ref_json="$(curl -fsSL "https://api.github.com/repos/${repo}/git/refs/tags/${tag}")"
printf '%s\n' '--- tag object ---'
printf '%s\n' "$ref_json" | jq '{ref, object}'
type="$(printf '%s\n' "$ref_json" | jq -r '.object.type')"
object_sha="$(printf '%s\n' "$ref_json" | jq -r '.object.sha')"
if [ "$type" = "tag" ]; then
commit_sha="$(curl -fsSL "https://api.github.com/repos/${repo}/git/tags/${object_sha}" | jq -r '.object.sha')
else
commit_sha="$object_sha"
fi
printf 'resolved commit: %s\n' "$commit_sha"
printf '%s\n' '--- commit existence ---'
curl -fsSL "https://api.github.com/repos/${repo}/commits/${commit_sha}" | jq -r '.sha'
printf '%s\n' '--- v5 workflow at resolved commit ---'
curl -fsSL "https://raw.githubusercontent.com/${repo}/${commit_sha}/.github/workflows/release.yml"Repository: evolution-gaming/random
Length of output: 212
🏁 Script executed:
#!/usr/bin/env bash
set -u
repo="evolution-gaming/scala-github-actions"
sha="b4557d9a82c03596dc2425e19b3cb9a6280a4739"
printf '%s\n' '--- commit API resolution ---'
if command -v gh >/dev/null 2>&1; then
gh api "repos/${repo}/commits/${sha}" --jq '.sha' || true
else
printf '%s\n' 'gh is unavailable'
fi
printf '%s\n' '--- git object resolution ---'
git ls-remote "https://github.com/${repo}.git" "$sha" "refs/tags/v5" "refs/tags/v5^{}" || true
printf '%s\n' '--- v5 workflow contract summary ---'
curl -fsSL "https://raw.githubusercontent.com/${repo}/${sha}/.github/workflows/release.yml" |
awk '/workflow_call:/,/^jobs:/'Repository: evolution-gaming/random
Length of output: 862
🌐 Web query:
site:docs.github.com/en/actions reusable workflow caller explicit secrets must be defined workflow_call secrets inherit GITHUB_TOKEN
💡 Result:
In GitHub Actions, secrets do not need to be explicitly defined in a reusable workflow's on.workflow_call block if you use the inherit keyword in the calling workflow [1]. When you use secrets: inherit in the caller workflow, all secrets available to the caller are implicitly passed to the reusable workflow, allowing you to reference them directly without prior definition in the reusable workflow's interface [1]. Regarding the GITHUB_TOKEN, it is important to note that it is automatically generated for every workflow job and is handled differently than user-defined secrets [2][3]. While the inherit keyword passes user-defined repository/environment secrets, the GITHUB_TOKEN is available by default in every job context regardless of secret inheritance [2][3]. You do not need to pass the GITHUB_TOKEN explicitly or via inheritance; it is always available, and you can reference it using ${{ secrets.GITHUB_TOKEN }} [3]. Summary of behavior: 1. Explicit definition: Required only if you are manually mapping specific secrets using the secrets keyword in the caller workflow [4][5]. 2. Implicit inheritance: If you use secrets: inherit, you do not need to define secrets in the reusable workflow's on.workflow_call block [1]. 3. GITHUB_TOKEN: This is not a standard repository secret; it is a built-in token automatically available to all workflow jobs [2]. It does not need to be defined in on.workflow_call or passed via inherit [2][3].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/en/actions/concepts/security/github_token
- 3: https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
- 4: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax?use_case=bi%3Futm_source%3DHyperGPT
🌐 Web query:
GitHub Actions reusable workflow secrets inherit GITHUB_TOKEN secrets context called workflow explicit mapping workflow_call
💡 Result:
In GitHub Actions, the GITHUB_TOKEN behaves differently than standard repository secrets when using reusable workflows. 1. Automatic Availability: The called (reusable) workflow is automatically granted access to the GITHUB_TOKEN without needing explicit mapping or inheritance [1]. You do not need to pass it via the secrets map or use secrets: inherit for the GITHUB_TOKEN to be available within the called workflow [1]. 2. Permissions: When a reusable workflow is triggered, it inherits the permissions associated with the GITHUB_TOKEN as defined by the caller job [1]. If the caller job does not specify permissions, the called workflow will have default permissions [1]. Importantly, any permissions specified in the called workflow can only be the same as or more restrictive (downgraded) than those provided by the caller; they cannot be elevated [1]. 3. Comparison with Other Secrets: Unlike the GITHUB_TOKEN, standard repository secrets are not automatically passed to reusable workflows [2]. To use them, you must either: - Explicitly map them using the secrets keyword in the job definition [3]: jobs: call_workflow: uses: path/to/reusable.yml secrets: MY_SECRET: ${{ secrets.MY_SECRET }} - Use the secrets: inherit keyword to pass all secrets available to the caller workflow to the called workflow [4][5]. For reusable workflows, remember that while GITHUB_TOKEN is always accessible, any other secrets required must be explicitly handled via mapping or inheritance to avoid "secret not defined" errors during the workflow parse phase [5].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations
- 2: https://qaskills.sh/blog/ci-workflow-reusable-inputs-secrets
- 3: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 4: https://github.blog/changelog/2022-05-03-github-actions-simplify-using-secrets-with-reusable-workflows/
- 5: https://latchkey.dev/learn/github-actions/gha-reusable-secret-not-defined-called-in-ci
Pin the reusable workflow and narrow secret access.
Use commit b4557d9a82c03596dc2425e19b3cb9a6280a4739 instead of @v5. The workflow reads only JFROG_ACCESS_TOKEN besides the automatic GITHUB_TOKEN, but secrets: inherit passes all caller secrets. After v5 declares JFROG_ACCESS_TOKEN in its workflow_call contract, replace inheritance with explicit mapping.
🧰 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 at line 10, Update the reusable workflow
reference in the release workflow to pin commit
b4557d9a82c03596dc2425e19b3cb9a6280a4739 instead of the v5 tag, and replace
secrets: inherit with an explicit mapping that passes only JFROG_ACCESS_TOKEN
while retaining the automatic GITHUB_TOKEN.
Sources: MCP tools, Linters/SAST tools
| rewrite.rules = [ | ||
| Imports, | ||
| RedundantParens, | ||
| SortModifiers, | ||
| prefercurlyfors, | ||
| ] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
curl -fsSL \
https://raw.githubusercontent.com/scalameta/scalafmt/v3.11.5/scalafmt-core/shared/src/main/scala/org/scalafmt/rewrite/Rewrite.scala \
| rg -n -C 2 'PreferCurlyFors|ConfCodecEx\.oneOf'Repository: evolution-gaming/random
Length of output: 448
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- repository configuration ---'
sed -n '70,92p' .scalafmt.conf
printf '%s\n' '--- Scalafmt rewrite-rule decoding ---'
curl -fsSL \
https://raw.githubusercontent.com/scalameta/scalafmt/v3.11.5/scalafmt-core/shared/src/main/scala/org/scalafmt/rewrite/Rewrite.scala \
| sed -n '96,132p'
printf '%s\n' '--- documented rule name ---'
curl -fsSL \
https://scalameta.org/scalafmt/docs/configuration.html \
| rg -n -C 3 'PreferCurlyFors|prefercurlyfors'Repository: evolution-gaming/random
Length of output: 50380
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- Scalafmt references in the repository ---'
rg -n -i --glob '!target/**' --glob '!node_modules/**' 'scalafmt|scalafmtVersion|scalafmt-core' . | head -80 || true
printf '%s\n' '--- Exact rule-name comparison ---'
python3 - <<'PY'
import re
import urllib.request
from pathlib import Path
source = urllib.request.urlopen(
"https://raw.githubusercontent.com/scalameta/scalafmt/v3.11.5/"
"scalafmt-core/shared/src/main/scala/org/scalafmt/rewrite/Rewrite.scala"
).read().decode()
config = Path(".scalafmt.conf").read_text()
registered = re.findall(r"^\s{4}([A-Z][A-Za-z0-9]+),\s*$", source, re.M)
configured = re.search(r"^\s*prefercurlyfors,\s*$", config, re.M)
print("registered_prefer_curly_fors:", "PreferCurlyFors" in registered)
print("configured_lowercase_token:", configured.group(0).strip() if configured else None)
print("exact_registered_match:", configured and configured.group(0).strip() in registered)
print("registered_rules:", registered)
PYRepository: evolution-gaming/random
Length of output: 2764
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- build plugin configuration ---'
cat -n project/plugins.sbt
printf '%s\n' '--- Scalafmt configuration version declarations ---'
rg -n -i -uu 'scalafmt|version\s*=' .scalafmt.conf .github project build.sbt 2>/dev/null || true
printf '%s\n' '--- sbt-scalafmt 2.6.2 dependency metadata ---'
curl -fsSL \
https://repo1.maven.org/maven2/org/scalameta/sbt-scalafmt_2.12_1.0/2.6.2/sbt-scalafmt_2.12_1.0-2.6.2.pom \
| rg -n -C 2 'scalafmt|version' || true
curl -fsSL \
https://repo1.maven.org/maven2/org/scalameta/sbt-scalafmt_2.12_1.0/2.6.2/sbt-scalafmt_2.12_1.0-2.6.2.pom \
| head -40 || trueRepository: evolution-gaming/random
Length of output: 4965
🏁 Script executed:
#!/bin/bash
set -euo pipefail
for version in v3.11.4 v3.11.5; do
printf '%s\n' "--- Rewrite.scala ${version} ---"
curl -fsSL \
"https://raw.githubusercontent.com/scalameta/scalafmt/${version}/scalafmt-core/shared/src/main/scala/org/scalafmt/rewrite/Rewrite.scala" \
| sed -n '/private val rewrites/,/implicit val reader/p'
done
printf '%s\n' '--- Configured rewrite-rule tokens ---'
sed -n '/^rewrite\.rules[[:space:]]*=/,/^[[:space:]]*]/p' .scalafmt.confRepository: evolution-gaming/random
Length of output: 1106
Use the registered PreferCurlyFors rule name.
Line 85 uses prefercurlyfors, which Scalafmt does not recognize. This prevents the fmt and check tasks from decoding .scalafmt.conf.
Proposed fix
- prefercurlyfors,
+ PreferCurlyFors,📝 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.
| rewrite.rules = [ | |
| Imports, | |
| RedundantParens, | |
| SortModifiers, | |
| prefercurlyfors, | |
| ] | |
| rewrite.rules = [ | |
| Imports, | |
| RedundantParens, | |
| SortModifiers, | |
| PreferCurlyFors, | |
| ] |
🤖 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 @.scalafmt.conf around lines 81 - 86, Update the rewrite.rules entry in
.scalafmt.conf to use the registered PreferCurlyFors rule name instead of the
unrecognized lowercase prefercurlyfors value, preserving the other configured
rules.
1 participant
Summary by CodeRabbit
Build & Compatibility
Dependencies
Code Quality
Release Process