linera-io/linera-protocol · error
GITHUB_PR_NUMBER is not a valid number: {pr_string}
Error message
GITHUB_PR_NUMBER is not a valid number: {pr_string} What it means
Thrown by GithubContext::from_env when linera-summary runs in CI mode (is_local=false). The tool reads the GITHUB_PR_NUMBER environment variable and parses it with str::parse::<u64>(); the parse itself only fails when the variable exists but its value is not a bare decimal number. The message interpolates the offending value, so the raw string appears in the error.
Source
Thrown at linera-summary/src/github.rs:134
pr_number.ok_or_else(|| anyhow!("pr_number is None"))?,
)
} else {
let pr_string = env_pr_number.map_err(|_| {
anyhow!("GITHUB_PR_NUMBER is not set! This must be run from within CI")
})?;
(
env_pr_commit_hash.map_err(|_| {
anyhow!("GITHUB_PR_COMMIT_HASH is not set! This must be run from within CI")
})?,
env_pr_branch.map_err(|_| {
anyhow!("GITHUB_PR_BRANCH is not set! This must be run from within CI")
})?,
env_base_branch.map_err(|_| {
anyhow!("GITHUB_BASE_BRANCH is not set! This must be run from within CI")
})?,
pr_string
.parse()
.map_err(|_| anyhow!("GITHUB_PR_NUMBER is not a valid number: {pr_string}"))?,
)
};
Ok(Self {
repository: GithubRepository::from_env(is_local)?,
pr_commit_hash,
pr_branch,
base_branch,
pr_number,
})
}
}
/// A GitHub client bound to a PR context, used to query workflow runs/jobs and post comments.
pub struct Github {
octocrab: Octocrab,
context: GithubContext,
is_local: bool,View on GitHub (pinned to 6c226ddcb3)
Solutions
- Check the exact value printed in the message; strip quotes, whitespace and CR/LF: GITHUB_PR_NUMBER=$(echo "$GITHUB_PR_NUMBER" | tr -d '[:space:]')
- In GitHub Actions, set it from the numeric event field: env: GITHUB_PR_NUMBER: ${{ github.event.number }}
- If running locally, invoke the tool in local mode (is_local=true / --local) so it derives context from git instead of env vars, passing the PR number explicitly
- Never assign a git ref like refs/pull/N/merge; use only the bare integer N
Example fix
# before (workflow yaml)
env:
GITHUB_PR_NUMBER: ${{ github.ref }} # "refs/pull/123/merge" -> parse fails
# after
env:
GITHUB_PR_NUMBER: ${{ github.event.number }} Defensive patterns
Strategy: validation
Validate before calling
// Rust: validate before constructing the Github client
fn pr_number_from_env() -> anyhow::Result<u64> {
let raw = std::env::var("GITHUB_PR_NUMBER")
.map_err(|_| anyhow::anyhow!("GITHUB_PR_NUMBER is not set"))?;
let trimmed = raw.trim();
trimmed.parse::<u64>().map_err(|_| {
anyhow::anyhow!("GITHUB_PR_NUMBER={raw:?} is not a PR number")
})
} Try / catch
match Github::new(false, None) {
Ok(gh) => gh,
Err(e) if e.to_string().contains("GITHUB_PR_NUMBER") => {
eprintln!("CI env incomplete: {e}"); return Ok(());
}
Err(e) => return Err(e),
} Prevention
- In workflows, always derive GITHUB_PR_NUMBER from ${{ github.event.number }}
- Trim whitespace and CR in wrapper scripts before launching the binary
- Add a startup assert that logs all required GITHUB_* variables when CI mode is on
When it happens
Trigger: Running the linera-summary binary outside GitHub Actions CI but with GITHUB_PR_NUMBER set to something non-numeric (e.g. "true", "refs/pull/123/merge", an empty string, or a value with whitespace/newline); in CI, exporting the PR from the wrong context expression such as github.ref instead of github.event.number.
Common situations: Manually replaying a CI run locally and copying GitHub payload JSON where number fields arrive as strings with quotes or CR/LF; workflow templates that pass "${{ github.head_ref }}" by mistake; a step that does `echo GITHUB_PR_NUMBER=123 #comment` on Windows (trailing \r).
Related errors
- GITHUB_TOKEN is not set! This must be run from within CI
- Invalid address value: {s}
- HEAD is not on a branch - it may be detached
- Invalid blob ID: {s}
- Invalid parsing of GenericApplicationId
AI-assisted analysis of linera-io/linera-protocol@6c226ddcb3 (2026-08-22).
Data as JSON: /api/errors/d946b7e58b1cebf7.
Report an issue: GitHub.