Add internal cloud image release workflow - #1566
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe reusable cloud build workflow now supports optional Sentry enforcement. A new manually triggered workflow invokes it for internal cloud releases with Sentry disabled and ChangesCloud release workflows
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Operator
participant InternalRelease as releaseCloudInternal.yml
participant CloudBuild as _build-cloud.yml
participant Docker
Operator->>InternalRelease: Dispatch internal release
InternalRelease->>CloudBuild: Invoke build with Sentry disabled
CloudBuild->>Docker: Build image with main and SHA tags
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: 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-cloud-internal.yml:
- Line 1: Rename the workflow file from release-cloud-internal.yml to
releaseCloudInternal.yml, preserving its existing contents and workflow
behavior.
- Around line 22-30: Remove the unconditional secrets: inherit setting from the
internal build invocation of ./.github/workflows/_build-cloud.yml; rely on the
internal environment’s environment-scoped secrets, since require_sentry is false
and no additional repository- or organization-level secret is required.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 5eb0b518-2b97-48fa-b065-8e541501e49c
📒 Files selected for processing (3)
.github/workflows/_build-cloud.yml.github/workflows/release-cloud-internal.ymlCHANGELOG.md
| @@ -0,0 +1,30 @@ | |||
| name: Release Sourcebot (Cloud - Internal Demo) | |||
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Rename the workflow file to camelCase.
Rename .github/workflows/release-cloud-internal.yml to .github/workflows/releaseCloudInternal.yml before merge. The current filename violates the repository file naming rule.
As per coding guidelines, files must use camelCase names starting with a lowercase letter.
🤖 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-cloud-internal.yml at line 1, Rename the workflow
file from release-cloud-internal.yml to releaseCloudInternal.yml, preserving its
existing contents and workflow behavior.
Source: Coding guidelines
| uses: ./.github/workflows/_build-cloud.yml | ||
| with: | ||
| environment: internal | ||
| git_ref: ${{ inputs.git_ref || 'main' }} | ||
| require_sentry: false | ||
| docker_tags: | | ||
| type=raw,value=main | ||
| type=sha,format=long | ||
| secrets: inherit |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
# Verify that the reusable workflow has no non-Sentry secret dependency.
rg -n -C 3 'secrets\.' .github/workflows/_build-cloud.ymlRepository: sourcebot-dev/sourcebot
Length of output: 1451
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- reusable workflow ---'
cat -n .github/workflows/_build-cloud.yml | sed -n '1,180p'
printf '%s\n' '--- internal caller ---'
cat -n .github/workflows/release-cloud-internal.yml | sed -n '1,100p'
printf '%s\n' '--- callers and secret declarations ---'
rg -n -C 5 'uses: .*_build-cloud\.yml|require_sentry:|secrets:|workflow_call:|SENTRY_AUTH_TOKEN' .github/workflowsRepository: sourcebot-dev/sourcebot
Length of output: 24669
🌐 Web query:
GitHub Actions reusable workflows secrets inherit environment secrets called workflow job environment workflow_call
💡 Result:
In GitHub Actions, environment secrets in reusable workflows are accessed by defining an environment at the job level within the called (reusable) workflow, while also ensuring the caller workflow provides the necessary secret context via secrets: inherit [1][2]. While official documentation notes that environment secrets cannot be passed directly from a caller workflow using the environment keyword in on.workflow_call [1][3], users have identified that simply defining environment in the reusable workflow is often insufficient for secret resolution [4][5]. The use of secrets: inherit in the caller workflow's job configuration is effectively required to ensure that environment-scoped secrets are correctly resolved and available within the reusable workflow [4][5][2]. Key implementation details include: 1. Reusable Workflow Configuration: The reusable workflow must define the environment at the job level (e.g., environment: ${{ inputs.env_name }}) [6][2]. You may need to pass the environment name as an input to the reusable workflow to keep it dynamic [6][2]. 2. Caller Workflow Configuration: The caller workflow must use secrets: inherit to grant the reusable workflow access to the caller's secret context, which includes environment-specific secrets once the environment is properly scoped [1][4][2]. If secrets: inherit is not used, environment-scoped secrets often resolve to an empty string instead of throwing an error [4][5]. Using secrets: inherit allows the reusable workflow to access the environment secrets associated with the environment defined in its job [2].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://cloudchronicles.blog/blog/Passing-Environment-Secrets-and-Variables-to-Reusable-Workflows-in-GitHub-Actions/
- 3: https://docs.github.com/en/enterprise-server@3.12/actions/using-workflows/reusing-workflows
- 4: [BUG] Environment-scoped secrets unreachable from reusable workflow without secrets: inherit, despite called job declaring environment actions/runner#4453
- 5: [Docs Bug] Reusable workflow env-scope secrets section missing the secrets: inherit requirement (see actions/runner#4453) github/docs#44458
- 6: Environment Secrets are not available on Reusable Workflow / Workflow Templates actions/runner#1490
🌐 Web query:
site:docs.github.com actions reusable workflow jobs environment secrets inherit workflow_call environment secrets
💡 Result:
When calling a reusable workflow in GitHub Actions, you can use the secrets: inherit keyword in your calling workflow to implicitly pass all secrets from the caller to the called workflow [1][2]. However, there are critical limitations regarding environment secrets and how they interact with reusable workflows [1][3]. Key points regarding environment secrets and reusable workflows: 1. Environment secrets cannot be passed from a caller workflow to a reusable workflow [1][3]. This is because the on.workflow_call trigger does not support the environment keyword [1][3]. 2. If your reusable workflow needs to access environment secrets, it must define the environment keyword at the job level within the reusable workflow itself [1][3]. 3. When you define an environment at the job level in a reusable workflow, the job will use the secrets associated with that specified environment, not any secrets passed from the caller workflow [1][2]. 4. The secrets: inherit keyword allows the called workflow to access all secrets available to the caller (such as repository or organization-level secrets) without needing to explicitly map them in the on.workflow_call configuration [1][3]. In summary, because environment cannot be passed through workflow_call, you cannot dynamically inject environment-specific secrets from a caller into a reusable workflow via inherit or mapping. The reusable workflow must explicitly declare the environment it requires to access secrets bound to that environment [1][3].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/en/enterprise-server@3.12/actions/using-workflows/reusing-workflows
- 3: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows
🌐 Web query:
site:docs.github.com "Environment secrets cannot be passed from the caller workflow"
💡 Result:
In GitHub Actions, environment secrets cannot be passed from a caller workflow to a reusable workflow because the on.workflow_call trigger does not support the environment keyword [1][2]. When a reusable workflow is configured to use an environment at the job level, it will automatically use the environment secrets defined for that environment within its own repository, rather than any secrets passed from the caller workflow [1][3]. To use secrets in a reusable workflow, you must explicitly pass them using the secrets keyword in the caller workflow [2][4], or use secrets: inherit to pass all secrets from the caller to the reusable workflow [1][2]. However, these methods apply to repository or organization-level secrets, not environment-specific secrets, which are strictly scoped to the job's execution context and the environment they are associated with [1][5].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
- 2: https://docs.github.com/enterprise-cloud@latest/actions/using-workflows/reusing-workflows
- 3: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows
- 4: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 5: https://docs.github.com/en/actions/reference/security/secrets
Remove unconditional secret inheritance for the internal build.
The internal job environment supplies its environment-scoped secrets independently of secrets: inherit. With require_sentry: false, the workflow does not require SENTRY_AUTH_TOKEN. Remove secrets: inherit unless another repository- or organization-level secret is required.
🧰 Tools
🪛 zizmor (1.29.0)
[warning] 22-22: 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-cloud-internal.yml around lines 22 - 30, Remove
the unconditional secrets: inherit setting from the internal build invocation of
./.github/workflows/_build-cloud.yml; rely on the internal environment’s
environment-scoped secrets, since require_sentry is false and no additional
repository- or organization-level secret is required.
Source: Linters/SAST tools
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 002b174. Configure here.
1 participant
Summary
Verification
Note
Cursor Bugbot is generating a summary for commit 1b9f596. Configure here.
Summary by CodeRabbit
New Features
Documentation