ci: post Validate Integration comments on fork PRs via workflow_run#313
Merged
Conversation
pull_request workflows triggered from forks always run with a read-only GITHUB_TOKEN, regardless of the workflow's permissions: block — that's a documented GitHub Actions security boundary, not a config oversight. As a result the existing 'Post PR comment' step in autohive-ai/autohive-integrations-tooling@v2 always 403s on fork PRs (e.g. #293), and the job conclusion goes red purely because of the failed comment-posting step even when all five validation checks passed. This commit switches to the standard two-workflow pattern for fork PR comments: * validate-integration.yml now sets post_comment: 'false' on the tooling action (so the inline post step is skipped), captures the rendered comment via the action's new comment_path output, and uploads it together with the PR number as a 'validation-comment' artifact. Job conclusion now reflects validation only. * validate-integration-comment.yml (new) is triggered on workflow_run completion of the validation workflow, runs in the base-repository context with full token permissions, downloads the artifact, and posts the sticky comment via marocchino/sticky-pull-request-comment@v2. Untrusted fork code never executes with elevated tokens — the validation job stays read-only, and the companion job only ever processes a small artifact (PR number + Markdown text), never executes fork code. Same trade-off (and same reason) that ruled out pull_request_target for this workflow. Requires autohive-integrations-tooling 2.1.0 (already released and v2 retagged). Closes #312
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a20ebed3db
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
Addresses review feedback: the validation job runs fork-controlled
code (pytest, imported integration modules) on the runner, so
anything it writes to the workspace — including the artifact — must
be treated as untrusted by the privileged workflow_run companion.
A malicious fork could overwrite pr-number.txt during pytest /
conftest hooks to redirect the companion's write-scoped
sticky-comment posting (or delete) at an arbitrary victim PR.
The companion now resolves the target PR from the trusted
workflow_run event payload:
1. Try github.event.workflow_run.pull_requests[0].number first
(populated for same-repo PRs).
2. Fall back to a GitHub API lookup using the trusted
workflow_run.head_sha (the pull_requests array is empty for
fork PRs because the head SHA lives in a different repo).
Both inputs come from GitHub's event payload, not from the
artifact, so on-runner fork code cannot influence the resolution.
The validate workflow no longer writes pr-number.txt — only
comment.md (or delete.marker). The artifact is still required for
the rendered comment body, but its contents now only ever land on
the PR that GitHub itself associates with the head SHA, so the
worst-case effect of fork manipulation is bounded to the fork
author's own PR.
Refs #312, codex review on #313.
NinosMan
approved these changes
May 1, 2026
sumitramanga
approved these changes
May 1, 2026
TheRealAgentK
added a commit
to lohitya/autohive-integrations
that referenced
this pull request
May 1, 2026
Empty commit to retrigger CI on PR Autohive-AI#293 so we can verify the new fork-PR comment pipeline (Autohive-AI#313) works end-to-end: 1. Validate Integration (Tooling) should now go ✅ even on a fork PR (uploads artifact instead of attempting an inline 403-bound comment post). 2. Validate Integration Comment companion should run, resolve the PR number from the workflow_run event payload, and post the sticky validation-results comment. No code changes. Safe to drop / squash on merge.
This was referenced May 1, 2026
Shubhank-Jonnada
pushed a commit
that referenced
this pull request
May 12, 2026
…h unit tests (#293) * feat: add tasks management to HubSpot integration with unit tests * fix: refine hubspot task association logic * fix(hubspot): refine task action handling and tests Restrict HubSpot task updates to the intended task action paths and align task unit tests with the latest task behavior to keep task-scoped changes isolated. Made-with: Cursor * fix(hubspot): correct integration version * fix(hubspot): remove duplicate fetch in get_thread_id_from_ticket The function was making two consecutive identical context.fetch() calls for the ticket URL — a merge artifact from resolving conflicts when master was merged into ls/hubspot-tasks. The extra call shifted mock_context.fetch.call_args_list indices by one in the existing ticket-conversation tests, causing 15 failures in test_hubspot_tickets_unit.py. Removing the duplicate restores the single-fetch behaviour from master. * style(hubspot): apply ruff format to match project line-length Reflow lines in the new task handlers and tests to match the project's 120-char ruff configuration. No behavioural changes. * ci: retrigger Validate Integration after fork-PR comment fix Empty commit to retrigger CI on PR #293 so we can verify the new fork-PR comment pipeline (#313) works end-to-end: 1. Validate Integration (Tooling) should now go ✅ even on a fork PR (uploads artifact instead of attempting an inline 403-bound comment post). 2. Validate Integration Comment companion should run, resolve the PR number from the workflow_run event payload, and post the sticky validation-results comment. No code changes. Safe to drop / squash on merge. * ci: retrigger after fork PR resolution fix Empty commit to retrigger CI on PR #293 so we can verify the fork-PR resolution fix from #315 works end-to-end: Validate Integration Comment should now successfully resolve PR 293 via /pulls?head=lohitya:ls/hubspot-tasks (the previous /commits/{sha}/pulls endpoint was returning empty for fork SHAs) and post the sticky validation-results comment. No code changes. * fix(hubspot): align task actions with schema and version bump * test(hubspot): align task unit tests with hs_task_* inputs and adds context.py This commit adds context.py for structure validation and aligns canonical HubSpot task property names. * docs(hubspot): align README task sections with config schema This commit aligns README file with updated config schema * refactor(hubspot): remove dead context.py shim and simplify test imports - Delete unused tests/context.py (was scaffolding, never imported) - Simplify tests/conftest.py to only put integration root on sys.path - Replace per-file importlib.spec_from_file_location boilerplate with plain 'from hubspot.hubspot import ...' imports across all test files - Apply ruff format using the tooling ruff.toml config --------- Co-authored-by: Kai Koenig <kai@ventego-creative.co.nz>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #312.
What
Switches the
Validate Integration (Tooling)workflow to the two-workflow pattern for fork PR comments:.github/workflows/validate-integration.yml(modified)post_comment: 'false'on the tooling action so the inline post step is skipped.comment_pathoutput (tooling 2.1.0).{ pr-number.txt, comment.md }(ordelete.markerwhen no integration directories changed) as avalidation-commentartifact, 1-day retention.pull-requests: writefrompermissions:— no longer needed in this job..github/workflows/validate-integration-comment.yml(new)workflow_runcompletion ofValidate Integration (Tooling).pull-requests: write(which actually works there because the token isn't downgraded —workflow_runis the documented escape hatch).delete.marker) or posts the rendered comment viamarocchino/sticky-pull-request-comment@v2.Why
pull_requestworkflows triggered from forks always run with a read-onlyGITHUB_TOKENregardless of the workflow'spermissions:block (docs). The existing inline comment step always 403s on fork PRs and the job goes red purely because of the failed comment-posting step, even when validation passed. Concrete example: #293 (HubSpot tasks, opened fromlohitya/autohive-integrations).workflow_run-triggered jobs run in the base-repository context with normal token permissions, regardless of whether the original event was a fork PR. Untrusted fork code never executes with elevated tokens — the validation job stays read-only, and the companion job only ever processes a small artifact (PR number + Markdown text), never executes fork code. Same trade-off (and same reason) that ruled outpull_request_targetfor this workflow.Properties
marocchino's sticky behaviour still works — matches byheader: validation-resultsand updates in place across runs.One-time blind spot during this PR's review
workflow_runtriggers fire based on the workflow file on the repository's default branch, not on the PR branch. So while this PR is open, the newvalidate-integration-comment.ymlis on the PR branch but not yet on master — meaning this PR's own CI runs won't have a companion workflow to post their comment. CI ✅/❌ will still be correct (reflects validation only). After merge, every subsequent PR — fork or same-repo — gets the full pipeline working.Verification
python3 -c "import yaml; yaml.safe_load(...)"on both workflow files — both parse cleanly.Prerequisites (already done)
autohive-ai/autohive-integrations-tooling#37/ #38 merged2.1.0published;v2tag moved to the new commit (6ae64fe)