Skip to content

Conversation

@Nr9
Copy link
Member

@Nr9 Nr9 commented Jan 16, 2026

Summary by CodeRabbit

  • Chores
    • Added automated database migration workflow with GCP and Firebase integration, supporting dry-run mode for safer deployments and optional Slack notifications for monitoring deployment status.

✏️ Tip: You can customize this high-level summary in your review settings.

@Nr9 Nr9 requested a review from a team as a code owner January 16, 2026 02:22
@github-actions github-actions bot added the chore Repository or code maintenance label Jan 16, 2026
@coderabbitai
Copy link

coderabbitai bot commented Jan 16, 2026

📝 Walkthrough

Walkthrough

Introduces a GitHub Actions workflow for executing Fireway database migrations on GCP. The workflow supports dry-run mode, Slack notifications on failure, and requires inputs for GCP project credentials and target directory.

Changes

Cohort / File(s) Summary
GitHub Actions Workflow
​.github/workflows/valian-fireway.yml
New workflow triggered via workflow_call that orchestrates Fireway migrations. Configures GCP authentication, selects Firebase environment, and executes migrations with optional dry-run support. Includes conditional Slack alert on failure.

Poem

🐰 A workflow hops into place,

Migrations run at steady pace,

With Slack to warn of any fall,

Fireway's here to help us all! 🔥

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title 'feat: add valian fireway workflow' accurately describes the main change—introducing a new GitHub Actions workflow for Fireway migrations.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.


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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@Nr9 Nr9 force-pushed the chore/valian-fireway branch from 5fd020e to 119be59 Compare January 16, 2026 02:25
@Nr9 Nr9 merged commit 9b71c65 into main Jan 16, 2026
3 of 4 checks passed
@Nr9 Nr9 deleted the chore/valian-fireway branch January 16, 2026 02:32
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Fix all issues with AI agents
In @.github/workflows/valian-fireway.yml:
- Around line 3-31: The reusable workflow does not declare the SLACK_BOT_TOKEN
secret required by the Slack step (it reads secrets.SLACK_BOT_TOKEN), so add a
workflow_call secrets declaration for SLACK_BOT_TOKEN; specifically, under
workflow_call add a secrets: block with SLACK_BOT_TOKEN: required: true so the
secret is passed into the workflow when invoked.
- Around line 43-53: The workflow is using mutable action refs
(actions/checkout@v6,
valian-ca/github-workflows/.github/actions/setup-pnpm@main,
valian-ca/github-workflows/.github/actions/gcp-github-auth@main,
google-github-actions/setup-gcloud@v3); replace each mutable tag with the
corresponding full commit SHA for those actions so they are pinned immutably,
e.g., update the uses entries for actions/checkout, the two valian-ca internal
actions, and google-github-actions/setup-gcloud to reference their specific
commit SHAs (and consider adding Dependabot/Renovate config to automate future
SHA updates).
- Around line 65-73: Change the Slack notification step condition from using the
negated success check to GitHub Actions' failure() so cancellations don't
trigger alerts: update the step with name "notify Slack of failure" (id "slack")
to use if: failure(); also note that secrets can't be directly checked in if
conditions—if you need to guard against a missing SLACK_BOT_TOKEN, populate a
job-level env var from the secret and check that env var in the condition
instead.
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

  • Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 3793f89 and 119be59.

📒 Files selected for processing (1)
  • .github/workflows/valian-fireway.yml
🔇 Additional comments (3)
.github/workflows/valian-fireway.yml (3)

34-41: LGTM: permissions and concurrency guard look appropriate.

Good fit for WIF auth and serializing migrations per project.


55-57: LGTM: firebase environment selection is scoped to the intended directory.


59-63: This suggestion does not apply to this repository.

This repository uses npm (based on package-lock.json), not pnpm. Additionally, @valian/fireway is not a dependency of this repository—this is a reusable GitHub Actions workflow. The working-directory parameter points to the consuming project's directory, and the npx usage is appropriate for this pattern. The setup-pnpm step earlier in the workflow is for configuring the consumer's project, not this repository itself.

Likely an incorrect or invalid review comment.

✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.

Comment on lines +3 to +31
on:
workflow_call:
inputs:
workload-identity-project-number:
description: the GCP project number used for Workload Identity Federation
required: true
type: string
gcp-project-id:
description: The firebase project environment used for the deployment
required: true
type: string
gcp-service-account:
description: the email address of the service account
required: true
type: string
working-directory:
description: The working directory of the firebase project
required: false
type: string
default: functions
dry-run:
description: run migrations in dry-run mode
type: boolean
required: false
default: false
slack-channel-id:
description: Slack channel id to send alerts to
type: string
required: false
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Expose SLACK_BOT_TOKEN in workflow_call secrets.

The Slack step (Line 73) reads secrets.SLACK_BOT_TOKEN, but reusable workflows must explicitly declare secrets; otherwise the token is unavailable and the action will fail or no-op.

✅ Proposed fix
 on:
   workflow_call:
     inputs:
       workload-identity-project-number:
         description: the GCP project number used for Workload Identity Federation
         required: true
         type: string
@@
       slack-channel-id:
         description: Slack channel id to send alerts to
         type: string
         required: false
+    secrets:
+      SLACK_BOT_TOKEN:
+        required: false
📝 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.

Suggested change
on:
workflow_call:
inputs:
workload-identity-project-number:
description: the GCP project number used for Workload Identity Federation
required: true
type: string
gcp-project-id:
description: The firebase project environment used for the deployment
required: true
type: string
gcp-service-account:
description: the email address of the service account
required: true
type: string
working-directory:
description: The working directory of the firebase project
required: false
type: string
default: functions
dry-run:
description: run migrations in dry-run mode
type: boolean
required: false
default: false
slack-channel-id:
description: Slack channel id to send alerts to
type: string
required: false
on:
workflow_call:
inputs:
workload-identity-project-number:
description: the GCP project number used for Workload Identity Federation
required: true
type: string
gcp-project-id:
description: The firebase project environment used for the deployment
required: true
type: string
gcp-service-account:
description: the email address of the service account
required: true
type: string
working-directory:
description: The working directory of the firebase project
required: false
type: string
default: functions
dry-run:
description: run migrations in dry-run mode
type: boolean
required: false
default: false
slack-channel-id:
description: Slack channel id to send alerts to
type: string
required: false
secrets:
SLACK_BOT_TOKEN:
required: false
🤖 Prompt for AI Agents
In @.github/workflows/valian-fireway.yml around lines 3 - 31, The reusable
workflow does not declare the SLACK_BOT_TOKEN secret required by the Slack step
(it reads secrets.SLACK_BOT_TOKEN), so add a workflow_call secrets declaration
for SLACK_BOT_TOKEN; specifically, under workflow_call add a secrets: block with
SLACK_BOT_TOKEN: required: true so the secret is passed into the workflow when
invoked.

Comment on lines +43 to +53
- uses: actions/checkout@v6
- name: setup pnpm
uses: valian-ca/github-workflows/.github/actions/setup-pnpm@main
- uses: valian-ca/github-workflows/.github/actions/gcp-github-auth@main
with:
workload-identity-project-number: ${{ inputs.workload-identity-project-number }}
gcp-service-account: ${{ inputs.gcp-service-account }}

- uses: google-github-actions/setup-gcloud@v3
with:
project_id: ${{ inputs.gcp-project-id }}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

actions/checkout v6 latest stable version GitHub Actions

💡 Result:

Latest stable release for actions/checkout v6 is v6.0.1 (released Dec 2, 2025). [1]

Sources:
[1] actions/checkout releases (GitHub).


🌐 Web query:

google-github-actions setup-gcloud latest stable version documentation

💡 Result:

The action's current stable major release is v3 (latest patch v3.0.1). Pin like:

  • uses: google-github-actions/setup-gcloud@v3
    or pin exact release:
  • uses: google-github-actions/setup-gcloud@v3.0.1

Docs (inputs, default version behavior, version constraints, Workload Identity requirements): README. [1][2][3]

Sources:

  • README / usage & inputs. [1]
  • Releases (v3.0.1 release). [2]
  • GitHub Marketplace listing (latest published). [3]

🌐 Web query:

GitHub Actions best practices pinning commit SHA vs tags security

💡 Result:

Short answer

  • Prefer pinning third‑party actions to a full-length commit SHA (immutable) for security; tags/branches are mutable and can be moved to malicious code. [1][3]

When tags may be acceptable

  • Tag (or semver) pins are OK only for actions/releases that are provably immutable (GitHub immutable releases / “immutable actions”) or when you fully trust and control the action’s repo/author. Even then prefer a process that validates immutability. [2][5]

Practical best practices

  1. Pin to full commit SHAs for third‑party actions by default. This is the only current guarantee of immutability. [1][3]
  2. Enforce SHA pinning via enterprise/org/repo allowed‑actions policy when possible. [2][3]
  3. Automate updates (Dependabot, Renovate, pinning bots) so you can review and merge SHA bumps rather than using mutable tags. [3][8]
  4. Prefer Verified creators and audit action source code (or use actions from your org). Avoid “unpinnable” actions that pull remote code at runtime. [1][3]
  5. Block known‑bad actions and use policy blocklists, secrets least privilege, and other workflow hardening (reuse rules, OSSF/scorecards). [2][3]

References
[1] GitHub Docs — Secure use reference / pin actions to full-length commit SHA.
[2] GitHub Changelog — allowed actions policy and SHA pinning enforcement (immutable releases roadmap).
[3] GitHub Well‑Architected / Actions security — pin SHAs, avoid unpinnable actions, enforce policies.
[5] StepSecurity reporting on immutable actions and policy options.
[8] Guidance on automating SHA pin updates (Dependabot/renovate/pinning tools).


Pin GitHub Actions to commit SHAs to harden supply-chain security.

Using mutable references like @main and major version tags (e.g., @v3) introduces supply-chain risk, as tags can be reassigned to different commits. GitHub's official security guidance recommends pinning all actions to full commit SHAs for immutability. While actions/checkout@v6 (v6.0.1) and google-github-actions/setup-gcloud@v3 (v3.0.1) are valid and documented, they should be pinned to specific commit SHAs instead of version tags.

For internal actions in valian-ca/github-workflows (currently pinned to @main), also switch to commit SHAs to enforce consistency and prevent accidental code changes.

Consider automating SHA pin updates using Dependabot or Renovate to keep actions current while maintaining security.

🤖 Prompt for AI Agents
In @.github/workflows/valian-fireway.yml around lines 43 - 53, The workflow is
using mutable action refs (actions/checkout@v6,
valian-ca/github-workflows/.github/actions/setup-pnpm@main,
valian-ca/github-workflows/.github/actions/gcp-github-auth@main,
google-github-actions/setup-gcloud@v3); replace each mutable tag with the
corresponding full commit SHA for those actions so they are pinned immutably,
e.g., update the uses entries for actions/checkout, the two valian-ca internal
actions, and google-github-actions/setup-gcloud to reference their specific
commit SHAs (and consider adding Dependabot/Renovate config to automate future
SHA updates).

Comment on lines +65 to +73
- name: notify Slack of failure
id: slack
if: ${{ !success() && inputs.slack-channel-id != '' }}
uses: valian-ca/github-workflows/.github/actions/slack-alert@main
with:
message: fireway migrate ${{ inputs.gcp-project-id }} error
mrkdwn: |
:warning: fireway migrate *${{ inputs.gcp-project-id }}* (`${{ job.status }}`)
token: ${{ secrets.SLACK_BOT_TOKEN }}
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

GitHub Actions success() failure() cancelled() step if condition semantics

💡 Result:

Short summary of semantics and gotchas

  • Default: an omitted if on a job or step is treated as if: success() (i.e., run only when prior required steps/jobs succeeded). [1][2]

  • success(): true when all previous steps (in the same job) or all needed jobs (for job-level if with needs:) succeeded. Use to run only on overall success. [2][3]

  • failure(): true when any previous step (or any needed job in a dependency chain) has failed. Note: using failure() in an if overrides the default success() status check. You can combine it with extra predicates (e.g., failure() && steps.foo.conclusion == 'failure'). [2][3]

  • cancelled(): true when the workflow or job was cancelled. Use to run steps/jobs only when cancellation occurred. [2][3]

  • always(): returns true even if cancelled; it forces execution unconditionally (including during cancellation). Because always() still runs when a workflow is cancelled, GitHub recommends using if: ${{ !cancelled() }} when you want "always except when cancelled". [2][4]

  • Evaluation during cancellation: when a workflow is cancelled GitHub re-evaluates job-level and then unfinished step-level if conditions. Jobs/steps whose if evaluates true may continue; others get cancelled. Runners send SIGINT/SIGTERM to canceled steps and eventually kill them. [4]

  • needs: interaction: job-level status-check functions (success/failure/cancelled) consider the status of needed jobs (ancestors). A job without an explicit status-check function behaves like if: success() && (your other conditions). failure() returns true if any ancestor job failed. Skipped ancestors can cause a dependent job to be skipped under success(). [3][5]

Practical rules

  • Use explicit status functions when you need behaviour different from the default.
  • To run cleanup on failure or cancellation, prefer separate steps with if: ${{ failure() || cancelled() }} or use an always() step but guard with !cancelled() if you must avoid running during cancellation. [2][4]
  • Remember YAML quoting rules: use ${{ }} (or quote) when expressions start with !. [6]

Sources
[1] GitHub Docs — Expressions / Evaluate expressions (status functions).
[2] GitHub Docs — Evaluate expressions in workflows and actions (success/failure/cancelled/always examples).
[3] GitHub Docs — Workflow syntax for GitHub Actions (jobs.steps.if and default behavior).
[4] GitHub Docs — Workflow cancellation reference (how if is re-evaluated during cancel and runner termination behavior).
[5] Community tests and examples showing needs/status interactions.

If you want, I can produce a few minimal workflow examples that demonstrate each case.


🌐 Web query:

GitHub Actions secrets in if condition expression whether allowed

💡 Result:

Short answer: No — GitHub Actions does not allow directly referencing secrets in an if: expression. Use a non-secret value (env var, step output) derived from the secret and test that instead. [1][2]

Why and alternatives:

  • Official docs: "Secrets cannot be directly referenced in if: conditionals." Recommend setting secrets as job-level environment variables or producing a non-secret result and using that in if. [1]
  • Common workaround: read/inspect the secret in a step (or set an env at job/step level) and emit a boolean output or env var, then use that output/env in later if: checks. (Examples and community discussion). [2][3]

References:

  • GitHub Docs — Using secrets in GitHub Actions. [1]
  • GitHub Docs — Expressions / if conditionals. [2]
  • Community discussion / workaround examples. [3]

Use failure() instead of !success() to avoid Slack alerts on workflow cancellations.

When a run is cancelled, !success() evaluates to true, causing unnecessary Slack notifications. Use failure() to alert only on actual failures. Note: secrets cannot be checked in if conditions in GitHub Actions; if the token is missing, the step will fail. If you want to guard against that, set a job-level environment variable from the secret and check that instead.

✅ Suggested condition
-        if: ${{ !success() && inputs.slack-channel-id != '' }}
+        if: ${{ failure() && inputs.slack-channel-id != '' }}
📝 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.

Suggested change
- name: notify Slack of failure
id: slack
if: ${{ !success() && inputs.slack-channel-id != '' }}
uses: valian-ca/github-workflows/.github/actions/slack-alert@main
with:
message: fireway migrate ${{ inputs.gcp-project-id }} error
mrkdwn: |
:warning: fireway migrate *${{ inputs.gcp-project-id }}* (`${{ job.status }}`)
token: ${{ secrets.SLACK_BOT_TOKEN }}
- name: notify Slack of failure
id: slack
if: ${{ failure() && inputs.slack-channel-id != '' }}
uses: valian-ca/github-workflows/.github/actions/slack-alert@main
with:
message: fireway migrate ${{ inputs.gcp-project-id }} error
mrkdwn: |
:warning: fireway migrate *${{ inputs.gcp-project-id }}* (`${{ job.status }}`)
token: ${{ secrets.SLACK_BOT_TOKEN }}
🤖 Prompt for AI Agents
In @.github/workflows/valian-fireway.yml around lines 65 - 73, Change the Slack
notification step condition from using the negated success check to GitHub
Actions' failure() so cancellations don't trigger alerts: update the step with
name "notify Slack of failure" (id "slack") to use if: failure(); also note that
secrets can't be directly checked in if conditions—if you need to guard against
a missing SLACK_BOT_TOKEN, populate a job-level env var from the secret and
check that env var in the condition instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

chore Repository or code maintenance

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants