chore: include workflow inputs in job get endpoint#1162
Conversation
📝 WalkthroughWalkthroughThe PR adds an ChangesExpose Resolved Workflow Inputs
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ast-grep (0.43.0)github/get-job-inputs/index.jsThanks 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.
Pull request overview
This PR extends the job “dispatch context” surface area to include resolved workflow-run input values, and wires those inputs into the Get Job Inputs GitHub Action so they can be exposed as flattened GitHub Actions outputs.
Changes:
- Add
dispatchContext.inputsto the OpenAPI schema (jsonnet source, generatedopenapi.json, and generated TypeScript types). - Include
dispatchContext.inputsin the GitHub Action’s flattened output object (and in the bundledindex.js).
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| integrations/github-get-job-inputs/src/index.ts | Adds workflow-run inputs into the flattened GitHub Actions output payload. |
| github/get-job-inputs/index.js | Updates the bundled GitHub Action output to match the source change. |
| apps/api/src/types/openapi.ts | Updates generated OpenAPI TS types to include DispatchContext.inputs. |
| apps/api/openapi/schemas/jobs.jsonnet | Adds inputs field to the DispatchContext schema source. |
| apps/api/openapi/openapi.json | Updates generated OpenAPI JSON to include DispatchContext.inputs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| workspace: { id: job.workspaceId }, | ||
| environment: dispatchContext?.environment, | ||
| deployment: dispatchContext?.deployment, | ||
| input: dispatchContext?.inputs, |
| workspace: { id: job.workspaceId }, | ||
| environment: dispatchContext?.environment, | ||
| deployment: dispatchContext?.deployment, | ||
| input: dispatchContext?.inputs, |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
integrations/github-get-job-inputs/src/index.ts (1)
86-86: 💤 Low valueConsider aligning field name with source property.
The field is named
input(singular) while the source isdispatchContext?.inputs(plural). Other fields likevariable,resource, andversionfollow a singular naming pattern, but maintaining consistency with the source property name (inputs) might improve clarity.♻️ Proposed naming alignment
If
inputsis the canonical name in the API schema:- input: dispatchContext?.inputs, + inputs: dispatchContext?.inputs,This would result in flattened outputs like
inputs_*instead ofinput_*, which is a breaking change for workflow compatibility, so only apply if this is intentional.Based on learnings: "Sanitize flattened output keys consistently; changing key format is a breaking workflow compatibility change" applies to this file.
🤖 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 `@integrations/github-get-job-inputs/src/index.ts` at line 86, The field mapping uses a singular key `input` while sourcing from `dispatchContext?.inputs`, causing a naming mismatch; update the object property from `input` to `inputs` in the code that constructs the output (the mapping where `input: dispatchContext?.inputs` is set in integrations/github-get-job-inputs/src/index.ts) so the output key aligns with the source property, and verify downstream consumers and flattened key generation (e.g., the code that produces `input_*` vs `inputs_*`) to ensure you intentionally accept the breaking change or update those consumers accordingly.
🤖 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 `@integrations/github-get-job-inputs/src/index.ts`:
- Line 86: dispatchContext?.inputs is being passed directly into
setOutputsRecursively (via the property input) which flattens and writes every
nested value to core.setOutput/core.info and can leak secrets; change the code
so that index.ts does not pass raw dispatchContext?.inputs into
setOutputsRecursively—either (a) only pass a vetted whitelist of allowed keys,
(b) redact sensitive-looking values (e.g., keys containing
"token"/"password"/"secret"/"key") before passing, or (c) avoid recursive output
logging entirely and instead expose only specific safe fields; also confirm
whether the singular property name input is intentional and, if kept, ensure its
contents are sanitized before any calls to setOutputsRecursively or core.info to
prevent secret exposure.
---
Nitpick comments:
In `@integrations/github-get-job-inputs/src/index.ts`:
- Line 86: The field mapping uses a singular key `input` while sourcing from
`dispatchContext?.inputs`, causing a naming mismatch; update the object property
from `input` to `inputs` in the code that constructs the output (the mapping
where `input: dispatchContext?.inputs` is set in
integrations/github-get-job-inputs/src/index.ts) so the output key aligns with
the source property, and verify downstream consumers and flattened key
generation (e.g., the code that produces `input_*` vs `inputs_*`) to ensure you
intentionally accept the breaking change or update those consumers accordingly.
🪄 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: CHILL
Plan: Pro
Run ID: df0c9bae-1ce7-446f-a745-3b9fd0f86016
📒 Files selected for processing (5)
apps/api/openapi/openapi.jsonapps/api/openapi/schemas/jobs.jsonnetapps/api/src/types/openapi.tsgithub/get-job-inputs/index.jsintegrations/github-get-job-inputs/src/index.ts
| workspace: { id: job.workspaceId }, | ||
| environment: dispatchContext?.environment, | ||
| deployment: dispatchContext?.deployment, | ||
| input: dispatchContext?.inputs, |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check the DispatchContext schema to understand if inputs can contain sensitive data
# Look for the DispatchContext type definition and inputs field
ast-grep --pattern $'interface DispatchContext {
$$$
inputs$_
$$$
}'
# Also search for any documentation or comments about inputs
rg -nP -C5 'inputs.*:.*\{' --type=ts --glob '**/schemas/**' --glob '**/types/**'
# Check if there are any sanitization or filtering patterns for inputs
rg -nP '(secret|password|token|key|credential)' --type=ts --iglob '*dispatch*' --iglob '*input*' -C3Repository: ctrlplanedev/ctrlplane
Length of output: 22669
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Locate and print the relevant section of the action entrypoint
echo "### integrations/github-get-job-inputs/src/index.ts (around line 60-120)"
nl -ba integrations/github-get-job-inputs/src/index.ts | sed -n '60,130p'
# Find where setOutputsRecursively is defined/used
echo "### Search for setOutputsRecursively definition"
rg -n "setOutputsRecursively" integrations/github-get-job-inputs/src -S
# Print the file(s) containing setOutputsRecursively
echo "### Print setOutputsRecursively implementation (if in-repo)"
FILES=$(rg -l "setOutputsRecursively" integrations/github-get-job-inputs/src -S || true)
if [ -n "${FILES:-}" ]; then
for f in $FILES; do
echo "---- $f ----"
nl -ba "$f" | sed -n '1,220p'
done
fi
# Determine where dispatchContext comes from and its type import/definition
echo "### Search for dispatchContext usage and its type/source"
rg -n "dispatchContext" integrations/github-get-job-inputs/src -S
# Also locate the typed DispatchContext import (if any) and show its type shape
echo "### Search for DispatchContext type references in this integration"
rg -n "DispatchContext" integrations/github-get-job-inputs/src -SRepository: ctrlplanedev/ctrlplane
Length of output: 200
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "### integrations/github-get-job-inputs/src/index.ts (around line 60-130)"
sed -n '60,130p' integrations/github-get-job-inputs/src/index.ts | cat -n
echo "### Search for setOutputsRecursively definition/usage"
rg -n "setOutputsRecursively" integrations/github-get-job-inputs/src -S || true
echo "### Print candidate files that define setOutputsRecursively (if in-repo)"
FILES=$(rg -l "setOutputsRecursively" integrations/github-get-job-inputs/src -S || true)
if [ -n "${FILES:-}" ]; then
for f in $FILES; do
echo "---- $f ----"
# show enough lines around the definition
sed -n '1,220p' "$f" | cat -n
done
fi
echo "### Search for dispatchContext usage"
rg -n "dispatchContext" integrations/github-get-job-inputs/src -S || true
echo "### Search for DispatchContext type references"
rg -n "DispatchContext" integrations/github-get-job-inputs/src -S || trueRepository: ctrlplanedev/ctrlplane
Length of output: 6394
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "### Search for sanitization/redaction in the integration"
rg -n "(sanitize|redact|mask|secret|token|password|key|credential)" integrations/github-get-job-inputs/src -S || true
echo "### Inspect OpenAPI DispatchContext type shape around inputs"
# show the exact lines from openapi generated types
sed -n '1560,1620p' apps/api/src/types/openapi.ts | cat -n
echo "### Search for setOutputAndLog usage / any overrides"
rg -n "setOutputAndLog|core\.info\(" integrations/github-get-job-inputs/src -SRepository: ctrlplanedev/ctrlplane
Length of output: 4906
Prevent potential secret leakage by not recursively logging/setting outputs from dispatchContext?.inputs
integrations/github-get-job-inputs/src/index.tssetsinput: dispatchContext?.inputsand passes it tosetOutputsRecursively, which flattens every nested leaf and writes it to bothcore.setOutput(...)andcore.info(...).DispatchContext.inputsis typed as{ [key: string]: unknown }, and there’s no value redaction/sanitization (only key name normalization), so any workflow input that contains a token/password/API key would be exposed in action logs and as outputs.- Minor:
input(singular) is populated frominputs(plural); check if the naming is intentional for workflow compatibility.
🤖 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 `@integrations/github-get-job-inputs/src/index.ts` at line 86,
dispatchContext?.inputs is being passed directly into setOutputsRecursively (via
the property input) which flattens and writes every nested value to
core.setOutput/core.info and can leak secrets; change the code so that index.ts
does not pass raw dispatchContext?.inputs into setOutputsRecursively—either (a)
only pass a vetted whitelist of allowed keys, (b) redact sensitive-looking
values (e.g., keys containing "token"/"password"/"secret"/"key") before passing,
or (c) avoid recursive output logging entirely and instead expose only specific
safe fields; also confirm whether the singular property name input is
intentional and, if kept, ensure its contents are sanitized before any calls to
setOutputsRecursively or core.info to prevent secret exposure.
Summary by CodeRabbit