Repository navigation
chore(ci): consolidate deploy workflows - #22
Conversation
📝 WalkthroughWalkthroughThree workflow files were removed: .github/workflows/deno-deploy.yml, .github/workflows/worker-delete.yml, and .github/workflows/worker-deploy.yml. The remaining .github/workflows/update-configuration.yml was renamed to "Deploy" and reworked: new workflow_dispatch inputs (build_action_enabled, deploy_deno_enabled, skip_bot_events, exclude_supported_events); source-ref resolution and logging steps; conditional publishing of action artifacts; environment selection logic; and an integrated Deno deployment flow gated by inputs and reference type. 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
There was a problem hiding this comment.
Actionable comments posted: 3
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9231573c-0207-40f3-8f05-a5f71027f144
📒 Files selected for processing (4)
.github/workflows/deno-deploy.yml.github/workflows/update-configuration.yml.github/workflows/worker-delete.yml.github/workflows/worker-deploy.yml
💤 Files with no reviewable changes (3)
- .github/workflows/worker-delete.yml
- .github/workflows/worker-deploy.yml
- .github/workflows/deno-deploy.yml
| deploy: | ||
| name: "Deploy (Action / Deno)" | ||
| runs-on: ubuntu-latest | ||
| permissions: write-all |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/update-configuration.ymlRepository: ubiquity-os/command-demo
Length of output: 7736
Pin actions to full SHAs and scope permissions.
Line 41's permissions: write-all grants unnecessary access to GITHUB_TOKEN. The unpinned cross-repo actions at lines 94, 128, and 134 reference @main while receiving sensitive secrets (APP_ID, APP_PRIVATE_KEY, KERNEL_PUBLIC_KEY, GITHUB_TOKEN, APP_INSTALLATION_ID). If an action is compromised, it can access these secrets and write to the repository. Pin actions to full commit SHAs and restrict permissions to only what each step requires.
| echo "source_ref=$source_ref" >> "$GITHUB_OUTPUT" | ||
| echo "is_tag_ref=$is_tag_ref" >> "$GITHUB_OUTPUT" | ||
| echo "is_artifact_ref=$is_artifact_ref" >> "$GITHUB_OUTPUT" | ||
| echo "ACTION_REF=${GITHUB_REPOSITORY}@${action_ref_branch}" >> "$GITHUB_ENV" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, get the actual lines from the workflow file
fd '.github/workflows/update-configuration.yml' -x cat {} | head -160 | tail -90Repository: ubiquity-os/command-demo
Length of output: 50
🏁 Script executed:
find . -name "update-configuration.yml" -type fRepository: ubiquity-os/command-demo
Length of output: 112
🏁 Script executed:
cat -n ./.github/workflows/update-configuration.yml | sed -n '70,85p'Repository: ubiquity-os/command-demo
Length of output: 828
🏁 Script executed:
cat -n ./.github/workflows/update-configuration.yml | sed -n '135,150p'Repository: ubiquity-os/command-demo
Length of output: 1127
🌐 Web query:
GitHub Actions $GITHUB_ENV vs $GITHUB_OUTPUT env context expression resolution
💡 Result:
What gets resolved when (expressions vs runtime)
${{ ... }}expressions are evaluated by the GitHub Actions workflow engine (before/during step dispatch), using contexts likegithub,env,steps,needs, etc.$VAR/%VAR%/$env:VARare expanded later by the runner shell at runtime insiderun:.
$GITHUB_ENV (environment variables) vs env context
- Writing
NAME=valueto$GITHUB_ENVsets an OS environment variable for subsequent steps in the same job; the step that writes it cannot see the new value. [1] - The
envcontext (${{ env.NAME }}) contains variables defined in workflow/job/stepenv:blocks, and does not contain variables inherited by the runner process. So a variable created via$GITHUB_ENVis reliably usable as$NAMEin laterrun:steps, but is not guaranteed to appear in${{ env.NAME }}. [2]
$GITHUB_OUTPUT (step outputs) vs env context
- Writing
name=valueto$GITHUB_OUTPUTsets a step output (step needs anid) that you can reference later as${{ steps.<id>.outputs.<name> }}. [1] - Step outputs are specifically designed to feed expressions in later steps (including
if:,with:,env:values, etc.), because they live in thestepscontext. [1][2]
Practical rule of thumb
- Use
$GITHUB_ENVwhen the next steps only need the value inside shell scripts (run:):echo "$MYVAR". - Use
$GITHUB_OUTPUTwhen the next steps need the value in workflow expressions:if: ${{ steps.calc.outputs.foo == 'bar' }}orwith: token: ${{ steps.auth.outputs.token }}. [1][2]
Minimal example showing the difference
- name: Compute
id: calc
run: |
echo "RUNTIME_ONLY=hello" >> "$GITHUB_ENV"
echo "expr_value=hello" >> "$GITHUB_OUTPUT"
- name: Use in shell (works)
run: echo "$RUNTIME_ONLY"
- name: Use in expressions (use outputs)
if: ${{ steps.calc.outputs.expr_value == 'hello' }}
run: echo "expression matched"Sources: GitHub Docs on workflow commands (GITHUB_ENV, GITHUB_OUTPUT) [1], contexts and env/steps behavior [2], and notes about what the env context does/doesn’t include [3].
References
- [1] GitHub Docs — Workflow commands for GitHub Actions (sections “Setting an environment variable”, “Setting an output parameter”) (docs.github.com)
- [2] GitHub Docs — Contexts (
envcontext does not include runner-inherited variables;steps.<id>.outputs) (docs.github.com) - [3] GitHub Docs — Variables reference (default env vars not accessible via
envcontext; context alternatives) (docs.github.com)
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-commands
- 2: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs?apiVersion=2022-11-28
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/variables
ACTION_REF must use step output, not $GITHUB_ENV.
Writing to $GITHUB_ENV makes values available only as shell variables in later steps. The env context (${{ env.* }}) contains only workflow/job/step env: block variables—not runner-inherited ones. Line 142's ACTION_REF: ${{ env.ACTION_REF }} will not resolve to the value written at line 78. Step outputs (via $GITHUB_OUTPUT and ${{ steps.refs.outputs.action_ref }}) are the correct way to pass values to workflow expressions.
Suggested fix
- echo "ACTION_REF=${GITHUB_REPOSITORY}@${action_ref_branch}" >> "$GITHUB_ENV"
+ action_ref="${GITHUB_REPOSITORY}@${action_ref_branch}"
+ echo "action_ref=$action_ref" >> "$GITHUB_OUTPUT"
+ echo "ACTION_REF=$action_ref" >> "$GITHUB_ENV"
...
- ACTION_REF: ${{ env.ACTION_REF }}
+ ACTION_REF: ${{ steps.refs.outputs.action_ref }}| deno-version: v2.x | ||
|
|
||
| - name: Install dependencies | ||
| if: ${{ env.DEPLOY_DENO_ENABLED == 'true' && steps.refs.outputs.is_tag_ref != 'true' && steps.refs.outputs.is_artifact_ref != 'true' && github.event_name != 'delete' }} | ||
| run: deno install --node-modules-dir=auto --no-lock | ||
|
|
||
| - name: Generate manifest for deploy | ||
| if: ${{ env.DEPLOY_DENO_ENABLED == 'true' && steps.refs.outputs.is_tag_ref != 'true' && steps.refs.outputs.is_artifact_ref != 'true' && github.event_name != 'delete' }} | ||
| run: deno x -A -y --no-lock npm:@ubiquity-os/plugin-manifest-tool@latest |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Check for deno configuration files
fd -t f "(deno\.json|deno\.lock|\.github/workflows)" | head -20Repository: ubiquity-os/command-demo
Length of output: 50
🏁 Script executed:
# Get the full context of the workflow file
cat -n .github/workflows/update-configuration.yml | head -130 | tail -40Repository: ubiquity-os/command-demo
Length of output: 2438
🏁 Script executed:
# Check if there's a deno.lock file in the repository
find . -name "deno.lock" -o -name "deno.json" 2>/dev/null | head -20Repository: ubiquity-os/command-demo
Length of output: 50
🌐 Web query:
Deno --no-lock flag behavior documentation
💡 Result:
--no-lock tells Deno not to auto-discover and use a lockfile (for example, the default deno.lock that would otherwise be picked up when Deno finds your project config). (docs.deno.com)
Context: since Deno v1.28, Deno will automatically discover/use (and create/update) deno.lock when a deno.json(c) is discovered; --no-lock is the documented opt-out for that auto-discovery behavior. (deno.com)
If you want to disable lockfiles via config instead of a CLI flag, you can set "lock": false in deno.json. (docs.deno.com)
Citations:
- 1: https://docs.deno.com/runtime/reference/cli/run/
- 2: https://deno.com/blog/v1.28?utm_source=openai
- 3: https://docs.deno.com/runtime/fundamentals/configuration/?utm_source=openai
🌐 Web query:
Deno reproducibility lockfile auto-discovery
💡 Result:
Deno’s lockfile “auto-discovery” works like this:
- Deno first auto-detects your config file (
deno.json/deno.jsonc) by searching the current working directory and then walking up parent directories. You can override with--config. [1] - Once a config file is resolved, Deno uses lockfiles by default—and will create/use
deno.lockalongside that config (unless configured otherwise). You can also set"lock": { "path": "./deno.lock", "frozen": true }or disable with"lock": false. [1] - This behavior was introduced so you no longer need to pass
--lock=...manually; since Deno v1.28, the lockfile is automatically discovered and used when a config file is discovered. You can disable with--no-lock. [2]
Sources:
[1] Deno docs: deno.json / lockfile configuration and defaults (docs.deno.com)
[2] Deno v1.28 announcement (auto-discovered lockfiles; --no-lock) (deno.com)
Citations:
- 1: https://docs.deno.com/runtime/fundamentals/configuration/
- 2: https://deno.com/posts/v1.28?utm_source=openai
Pin Deno version and plugin-manifest-tool to specific versions.
deno-version: v2.x (semver range) and @ubiquity-os/plugin-manifest-tool@latest allow versions to drift over time. Pin both to exact versions (e.g., v2.0.0 and plugin-manifest-tool@1.2.3) for reproducible builds. The --no-lock flags are redundant here since the repository has no deno.json file to trigger lockfile auto-discovery, but the semver ranges and @latest tags are the actual reproducibility concerns.
There was a problem hiding this comment.
♻️ Duplicate comments (2)
.github/workflows/update-configuration.yml (2)
41-41:⚠️ Potential issue | 🟠 MajorRestrict token scope and pin action refs to immutable SHAs.
Line 41 grants full repo token access, and Lines 94/128/134 use mutable
@mainwhile passing sensitive secrets. Please scope permissions minimally and pin these actions to full commit SHAs.Suggested hardening diff
- permissions: write-all + permissions: + contents: write - uses: ubiquity-os/action-deploy-plugin@main + uses: ubiquity-os/action-deploy-plugin@<full_commit_sha> - uses: ubiquity-os/deno-plugin-adapter@main + uses: ubiquity-os/deno-plugin-adapter@<full_commit_sha> - - uses: ubiquity-os/deno-deploy@main + - uses: ubiquity-os/deno-deploy@<full_commit_sha>Also applies to: 94-94, 128-128, 134-134
75-79:⚠️ Potential issue | 🟠 MajorUse step output for
ACTION_REFin expressions.Line 142 reads
${{ env.ACTION_REF }}, but Line 78 setsACTION_REFvia$GITHUB_ENV. For workflow expressions, publishACTION_REFthrough$GITHUB_OUTPUTand consumesteps.refs.outputs.action_ref.Suggested fix
- echo "ACTION_REF=${GITHUB_REPOSITORY}@${action_ref_branch}" >> "$GITHUB_ENV" + action_ref="${GITHUB_REPOSITORY}@${action_ref_branch}" + echo "action_ref=$action_ref" >> "$GITHUB_OUTPUT" + echo "ACTION_REF=$action_ref" >> "$GITHUB_ENV" - ACTION_REF: ${{ env.ACTION_REF }} + ACTION_REF: ${{ steps.refs.outputs.action_ref }}Also applies to: 142-142
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 30d2cc03-1aaa-440d-8500-6d79bea5f6ea
📒 Files selected for processing (1)
.github/workflows/update-configuration.yml
Summary
Defaults in this repo