feat: add token input and use default username constant - #95
Conversation
Summary by CodeRabbit
WalkthroughChangesAction configuration
Merge Risk: ⚪ Minimal · up to The PR adds token fallback behavior, but the generic README example still shows the old required environment variable and omits the new input and precedence rules. This is a minor documentation inconsistency; no actionable merge-blocking risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
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
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 184a8588-59b0-48d8-b6f5-402086207391
📒 Files selected for processing (3)
action.ymlsrc/Helpers.psm1src/Variables.psm1
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
6859530 to
de1324a
Compare
Signed-off-by: Chawye Hsu <su+git@chawyehsu.com>
de1324a to
3ed3ab0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 579f9dcf-a1ef-47ef-802d-0e2e7c5d9c4a
📒 Files selected for processing (2)
README.mdaction.yml
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.
| ```yaml | ||
| - uses: ScoopInstaller/GithubActions@main | ||
| env: | ||
| # `GITHUB_TOKEN`: **REQUIRED** | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| # `GITHUB_TOKEN`: Optional, `${{ github.token }}` if not specified | ||
| GITHUB_TOKEN: ${{ github.token }} |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- candidate files ---'
git ls-files | rg '(^|/)(README\.md|action\.ya?ml|package\.json|src|lib|test|tests|__tests__)(/|$)|github_token|GITHUB_TOKEN' | head -200
printf '%s\n' '--- README token references ---'
rg -n -C 4 'github_token|GITHUB_TOKEN|ScoopInstaller/GithubActions|Issues' README.md
printf '%s\n' '--- repository token references ---'
rg -n -C 3 'github_token|GITHUB_TOKEN' . -g '!README.md' -g '!node_modules' -g '!dist' -g '!build' | head -300Repository: ScoopInstaller/GithubActions
Length of output: 5802
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- action.yml ---'
cat -n action.yml
printf '%s\n' '--- README.md lines 145-180 ---'
sed -n '145,180p' README.md
printf '%s\n' '--- input usage and workflow context ---'
rg -n -C 5 'inputs\.github_token|github_token:|env:|with:' README.md action.yml .github 2>/dev/null | head -300Repository: ScoopInstaller/GithubActions
Length of output: 4378
🌐 Web query:
GitHub Actions documentation env context precedence step-level env versus action input and action.yml env expression
💡 Result:
In GitHub Actions, environment variable precedence follows a "most-specific-wins" model [1][2][3]. Variables defined at the step level override those at the job level, which in turn override those at the workflow level [1][2][3]. Regarding the specific interaction between step-level env and action inputs (with): 1. Action Inputs are not Environment Variables: Actions defined with uses (e.g., Docker or JavaScript actions) consume configuration primarily through the with keyword, not the step's env block [4]. The with inputs are mapped to environment variables by the runner using the format INPUT_<VARIABLE_NAME> (uppercase, with spaces replaced by underscores) [5]. 2. Step env is often ignored by uses actions: Defining an env block on a uses step does not configure the action unless that specific action is explicitly documented to read those environment variables [4]. For most actions, passing a value via env on the step will have no effect on the action's behavior; you must use with for declared inputs [4]. 3. Composite Actions: In composite actions, inputs are not automatically exposed as INPUT_* environment variables [5]. They must be accessed via the inputs context (e.g., ${{ inputs.name }}) within the composite action's steps [5][6]. If you want to use them as environment variables within the composite action, you must explicitly map them in the composite action's steps[*].env configuration [6]. When using expressions in action.yml (such as in env or with blocks), these are evaluated by the GitHub Actions runner before the job is sent to the runner. Consequently, they can access context data (like env, github, or inputs) but cannot access shell-based environment variables that are only created on the runner during execution [7]. Top results: [1], [5], [4], [2], [3]
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 2: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax?use_case=
- 3: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 4: https://latchkey.dev/learn/github-actions/gha-env-on-uses-step-ignored
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax
- 6: https://latchkey.dev/learn/github-actions/github-actions-composite-action-inputs-not-passed
- 7: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
🌐 Web query:
site:docs.github.com GitHub Actions composite action caller env context action.yml steps env uses step environment variables
💡 Result:
In GitHub Actions composite actions, environment variables are handled differently than in standard workflow steps [1]. Notably, composite actions do not automatically receive environment variables created from workflow inputs (i.e., they do not automatically get INPUT_<VARIABLE_NAME>) [1]. To use environment variables within a composite action, you must explicitly map them using the env key within the steps configuration in your action.yml file [1]. Here is how you handle environment variables in composite actions: 1. Mapping Inputs: Since composite actions do not automatically expose inputs as environment variables, you must map them manually if your scripts require them [1][2]. You can do this by defining them in the env block of a step [2]: steps: - name: Example Step run: echo "Hello env context (e.g., ${{ env.VAR_NAME }}) to reference custom variables defined in your workflow [3][4]. If you need to access GitHub-specific information, you can use the github context, such as ${{ github.action_path }} [5][2]. 3. Scope and Overrides: When defining env within a step in a composite action, these variables are scoped specifically to that step [1]. If you need to persist a variable change for subsequent steps within the same composite action (or the calling workflow), you must append the variable to the $GITHUB_ENV file [1]: run: echo "MY_VAR=value" >> $GITHUB_ENV Key considerations: - Contexts like env and github are processed by GitHub Actions, whereas runner environment variables (like $MY_VAR) are interpolated by the shell executing the script [6][4]. - Secrets are not automatically available to composite actions for security reasons [5]. You must pass them explicitly as inputs to the composite action [5]. - Composite actions do not share the full environment variable set of the caller workflow automatically; ensure all required variables are passed via inputs or environment mappings [7][2].
Citations:
- 1: https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax
- 2: https://docs.github.com/actions/creating-actions/creating-a-composite-action
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- 4: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
- 6: https://docs.github.com/en/actions/concepts/workflows-and-actions/contexts
- 7: https://docs.github.com/en/actions/reference/workflows-and-actions/reusing-workflow-configurations
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- all workflow and action metadata files ---'
git ls-files | rg '(^|/)(action\.ya?ml|workflow.*\.ya?ml|.*\.ya?ml)$' | while read -r f; do
printf '%s\n' "--- $f"
rg -n -C 3 'uses:.*GithubActions|github_token|GITHUB_TOKEN|env:|with:' "$f" || true
done
printf '%s\n' '--- concise repository history for relevant files ---'
git log --oneline -8 -- README.md action.ymlRepository: ScoopInstaller/GithubActions
Length of output: 2626
🏁 Script executed:
#!/bin/bash
set -eu
python3 - <<'PY'
from pathlib import Path
import re
action = Path("action.yml").read_text()
readme = Path("README.md").read_text()
input_declared = bool(re.search(r"(?m)^ github_token:\s*$", action))
mapping = re.search(
r"(?m)^\s*GITHUB_TOKEN:\s*\$\{\{\s*([^}]+?)\s*\}\}\s*$", action
)
readme_has_input = bool(re.search(r"(?m)^\s*github_token\s*:", readme))
readme_has_default_env = bool(re.search(
r"(?m)^\s*GITHUB_TOKEN:\s*\$\{\{\s*github\.token\s*\}\}\s*$", readme
))
print(f"action input declared: {input_declared}")
print(f"action token mapping: {mapping.group(1).strip() if mapping else None}")
print(f"README documents github_token: {readme_has_input}")
print(f"README sets default GITHUB_TOKEN: {readme_has_default_env}")
assert input_declared
assert mapping
precedence = [part.strip() for part in mapping.group(1).split("||")]
assert precedence == ["env.GITHUB_TOKEN", "inputs.github_token", "github.token"]
assert not readme_has_input
assert readme_has_default_env
PY
printf '%s\n' '--- token-input commit summary ---'
git show --stat --oneline --no-renames 3ed3ab0
printf '%s\n' '--- token-input commit changes in public metadata and README ---'
git show --format= --no-ext-diff --no-renames 3ed3ab0 -- action.yml README.mdRepository: ScoopInstaller/GithubActions
Length of output: 3201
Document github_token without setting GITHUB_TOKEN in the generic example.
action.yml resolves tokens in this order: env.GITHUB_TOKEN, inputs.github_token, then github.token. Remove the default GITHUB_TOKEN assignment from this block. Add a separate with: github_token: example and document this precedence.
Source: MCP tools
1 participant
With this change, downstreams don't have to explicitly set the
GITHUB_TOKENenv when referencing the action.before:
after:
Existing explicitly defined
GITHUB_TOKENenv still have the highest precedence (step level).