chore: rolling promotion dev -> main - #2606
Conversation
The manifests job reads RELEASE_MANIFESTS_TOKEN from the release-manifests environment, but reusable workflows get an empty secrets context unless the caller passes one. Both hops (version.yml -> release.yml -> release-publish.yml) omitted secrets: inherit, so the v5.260720.10 stable run's preflight correctly reported the token unset despite the environment secret existing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the version of the genie plugin and its associated packages from 5.260720.10 to 5.260721.1 across several configuration and package files, including package.json, plugin.json, and plugin.yaml. I have no feedback to provide as there are no review comments.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
📝 WalkthroughWalkthroughVersion metadata is updated from ChangesRelease metadata and workflow configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
![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/version.yml:
- Around line 433-435: Replace broad secrets inheritance with an explicit
RELEASE_MANIFESTS_TOKEN mapping: declare RELEASE_MANIFESTS_TOKEN under
workflow_call and pass it explicitly at the call site in
.github/workflows/version.yml lines 433-435 and .github/workflows/release.yml
lines 186-190, preserving manifest access without forwarding unrelated secrets.
🪄 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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 654309e2-4ea7-432a-8c43-a37b5aa369e3
📒 Files selected for processing (8)
.claude-plugin/marketplace.json.github/workflows/release.yml.github/workflows/version.ymlpackage.jsonplugins/genie/.claude-plugin/plugin.jsonplugins/genie/.codex-plugin/plugin.jsonplugins/genie/package.jsonplugins/hermes-genie/plugin.yaml
| # Propagate secrets through the call chain so release-publish.yml's | ||
| # manifests job can read RELEASE_MANIFESTS_TOKEN (see release.yml publish). | ||
| secrets: inherit |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the relevant workflow files around the cited lines.
sed -n '400,460p' .github/workflows/version.yml
printf '\n--- release.yml ---\n'
sed -n '150,230p' .github/workflows/release.yml
# Find reusable workflow inputs/secrets declarations and where the manifest token is used.
printf '\n--- search secrets / workflow_call ---\n'
rg -n "workflow_call|secrets: inherit|RELEASE_MANIFESTS_TOKEN|release-manifests|release-publish" .github/workflowsRepository: automagik-dev/genie
Length of output: 6937
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- release.yml workflow_call ---'
sed -n '1,90p' .github/workflows/release.yml
printf '\n%s\n' '--- release-publish.yml workflow_call and manifest job ---'
sed -n '1,320p' .github/workflows/release-publish.ymlRepository: automagik-dev/genie
Length of output: 18907
🌐 Web query:
GitHub Actions reusable workflow environment secret precedence caller secrets secrets inherit job environment reusable workflow
💡 Result:
In GitHub Actions, secrets are not automatically passed to reusable workflows; they must be explicitly provided by the caller [1][2]. When a reusable workflow is called, you can pass specific secrets or use the secrets: inherit keyword to pass all secrets available to the calling workflow to the called workflow [1][3]. Precedence and Environment Secrets: 1. Secret Precedence: Generally, if secrets with the same name exist at different levels, the secret at the most specific level takes precedence [4]. The order (from lowest to highest precedence) is organization-level, repository-level, and environment-level [4]. 2. Reusable Workflow Environment Secrets: A common pitfall exists when attempting to use environment-scoped secrets within a reusable workflow. While a reusable workflow job must define the environment attribute to access environment-level secrets, this alone is often insufficient [5][6]. Empirical evidence indicates that the caller must also provide the secrets via explicit mapping or by using secrets: inherit for those secrets to resolve within the called workflow [5][6]. Without secrets: inherit (or explicit passing), environment-level secrets may resolve to an empty string instead of the expected value [5][6]. 3. Inheritance Scope: The secrets: inherit keyword passes all secrets the calling workflow has access to, including organization, repository, and environment secrets [5][7]. If a reusable workflow defines its own environment context, that local environment configuration can interact with the inherited secrets [3]. Note that if a secret is defined in both the calling workflow's environment and the reusable workflow's environment, the latter may take precedence depending on the specific configuration and resolution path [3]. Key takeaway: To ensure environment-scoped secrets are available in a reusable workflow, it is recommended to both define the environment in the called job and use secrets: inherit (or explicit passing) in the caller [5][6].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
- 3: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 4: https://docs.github.com/en/actions/reference/security/secrets
- 5: [BUG] Environment-scoped secrets unreachable from reusable workflow without secrets: inherit, despite called job declaring environment actions/runner#4453
- 6: [Docs Bug] Reusable workflow env-scope secrets section missing the secrets: inherit requirement (see actions/runner#4453) github/docs#44458
- 7: https://github.com/orgs/community/discussions/23107
🌐 Web query:
GitHub Actions reusable workflow on.workflow_call.secrets explicit mapping environment secret reusable workflow inherit required
💡 Result:
In GitHub Actions, you can pass secrets to a reusable workflow using either explicit mapping or the inherit keyword [1][2]. Explicit Mapping To use explicit mapping, you must first define the required secrets in the reusable workflow under the on.workflow_call.secrets key [3][2]. You can specify whether each secret is required [2]. Reusable workflow configuration: on: workflow_call: secrets: MY_SECRET: required: true Calling workflow configuration: jobs: call-workflow: uses: owner/repo/.github/workflows/reusable.yml@main secrets: MY_SECRET: ${{ secrets.MY_SECRET }} If a caller workflow attempts to pass a secret that is not defined in the reusable workflow's on.workflow_call.secrets block, or if a required secret is missing, it will result in an error [2]. Inherit Keyword Alternatively, the inherit keyword allows a calling workflow to implicitly pass all of its available secrets to the reusable workflow [1][4]. This is often used for convenience but carries security implications as it follows a permissive approach by passing every available secret to the called workflow [5][6]. Calling workflow configuration: jobs: call-workflow: uses: owner/repo/.github/workflows/reusable.yml@main secrets: inherit Key Considerations 1. Security and Principle of Least Privilege: Using secrets: inherit is generally discouraged in environments where strict security controls are required, as it may expose more secrets than necessary [5][6]. Explicit mapping is the recommended approach to limit the attack surface by ensuring only required secrets are shared [6]. 2. Nested Workflows: Secrets are only passed to directly called workflows [1]. If you have a workflow chain (A > B > C), workflow B must explicitly pass secrets to workflow C, or pass them using inherit, even if B inherited them from A [1][2]. 3. Automatic Secrets: GITHUB_TOKEN is automatically provided to reusable workflows by GitHub Actions and does not need to be explicitly passed or inherited [7][5].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 3: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
- 4: https://github.blog/changelog/2022-05-03-github-actions-simplify-using-secrets-with-reusable-workflows/
- 5: feat: avoid secrets:inherit as default, infer minimal set automatically github/gh-aw#29455
- 6: fix: replace secrets: inherit with explicit secret mappings in CI/CD workflows nhs-england-tools/repository-template#213
- 7: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/reusing-workflow-configurations.md
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Find secret references in the release workflow chain.
rg -n "secrets\.[A-Z0-9_]+|secrets:\s*inherit|workflow_call:\s*$|secrets:\s*$" \
.github/workflows/version.yml \
.github/workflows/release.yml \
.github/workflows/release-publish.yml
printf '\n--- declared workflow_call secrets blocks ---\n'
sed -n '1,120p' .github/workflows/version.yml | sed -n '/workflow_call:/,/permissions:/p'
printf '\n--- release.yml ---\n'
sed -n '1,120p' .github/workflows/release.yml | sed -n '/workflow_call:/,/permissions:/p'
printf '\n--- release-publish.yml ---\n'
sed -n '1,120p' .github/workflows/release-publish.yml | sed -n '/workflow_call:/,/permissions:/p'Repository: automagik-dev/genie
Length of output: 2046
Replace secrets: inherit with an explicit RELEASE_MANIFESTS_TOKEN mapping.
.github/workflows/version.yml and .github/workflows/release.yml only need to forward the manifest token; inheriting all caller secrets widens the blast radius for no benefit. Declare RELEASE_MANIFESTS_TOKEN on workflow_call and pass it explicitly at both call sites.
📍 Affects 2 files
.github/workflows/version.yml#L433-L435(this comment).github/workflows/release.yml#L186-L190
🤖 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/version.yml around lines 433 - 435, Replace broad secrets
inheritance with an explicit RELEASE_MANIFESTS_TOKEN mapping: declare
RELEASE_MANIFESTS_TOKEN under workflow_call and pass it explicitly at the call
site in .github/workflows/version.yml lines 433-435 and
.github/workflows/release.yml lines 186-190, preserving manifest access without
forwarding unrelated secrets.
Source: MCP tools
1 participant
Rolling Promotion PR
Auto-maintained rolling promotion PR from
devtomain.Process:
ready-to-mergeadded when all checks passSummary by CodeRabbit
5.260721.1.