Skip to content

ci: skip OEEquivHash when HASHSERV variable is unavailable (fork PRs) - #16624

Merged
rpcme merged 1 commit into
master-nextfrom
fix/hashserv-fork-pr-fallback
Aug 9, 2026
Merged

rpcme merged 1 commit into
master-nextfrom
fix/hashserv-fork-pr-fallback

Conversation

@rpcme

@rpcme rpcme commented Aug 9, 2026

Copy link
Copy Markdown
Member

Problem

PR #16623 fixed the case-sensitivity issue for vars[] lookup, but fork PRs (like #16292) still fail because GitHub Actions does not expose repository variables to workflows triggered by fork PRs (pull_request event). The vars context is completely empty in that security context.

Result:

echo BB_HASHSERVE = "" >> conf/local.conf
ERROR: OEEquivHash requires BB_HASHSERVE to be set

Fix

Make the BB_HASHSERVE + BB_SIGNATURE_HANDLER configuration conditional — only set them when the variable resolves to a non-empty value.

For fork PRs, this means bitbake runs without hash equivalence (no sstate cache sharing with the hash server), which is slower but functional. Internal PRs still get the full hashserv optimization.

Affected

All fork PRs that trigger build-test-recipe — currently #16292 (greengrass-lite).

For pull requests from forks, GitHub Actions does not expose
repository variables (vars context is empty). This causes
BB_HASHSERVE to be set to an empty string, which makes bitbake
fail with:
  ERROR: OEEquivHash requires BB_HASHSERVE to be set

Fix: only set BB_HASHSERVE and BB_SIGNATURE_HANDLER when the
repository variable is available. Fork PRs will build without
hash equivalence (no sstate sharing) but will still succeed.
@rpcme
rpcme requested a review from a team as a code owner August 9, 2026 15:49
@rpcme
rpcme merged commit a08b6ec into master-next Aug 9, 2026
7 of 11 checks passed
@rpcme
rpcme deleted the fix/hashserv-fork-pr-fallback branch August 9, 2026 15:50
rpcme added a commit that referenced this pull request Aug 9, 2026
The previous fix (PR #16624) used escaped quotes inside a
bash -c '...' single-quoted heredoc:
  if [ -n \"\" ]; then

Inside single quotes, \"\" produces literal quote characters,
which is a non-empty 2-char string - so the test always passes.

Fix: assign the GitHub expression to a shell variable first
(HASHSERV=<value>), then test with proper double-quoted shell
variable expansion: if [ -n "$HASHSERV" ]; then

This correctly evaluates to false when the expression is empty
(fork PRs where vars context is unavailable).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant