[GH-ISSUE #6335] [Docs/Feature] Provide a minimal GitHub Actions example for repeatable REA analysis #3817

New issue

Closed

opened 2026-10-31 00:44:21 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-31 00:44:21 +00:00

Owner

Originally created by @jayykernel on GitHub (Oct 22, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6335

Problem

Users who want to run REA in CI need a reliable starting point for installing the supported runtime, invoking an analysis operation, handling its exit status, and retaining machine-readable results. An example reduces the chance of each integration making different assumptions.

Desired outcome

Provide a maintained, minimal GitHub Actions workflow example for analyzing an artifact produced by a build.

Proposed behavior

Demonstrate analysis of a known build artifact using documented REA interfaces.
Keep generated reports available as workflow artifacts.
Show how to handle analysis failures and unsupported capabilities.
State any external engine or platform requirements explicitly.
Avoid executing untrusted artifacts unless the selected operation requires it and the workflow documents the risk.

Acceptance criteria

The example can be followed in a clean repository with only documented prerequisites.
Commands and output paths match the current CLI contract.
Failure behavior is explicit and testable.
The example does not require unnecessary credentials or secrets.

Scope

Start with a documentation/example workflow rather than introducing a new GitHub Action or promising compatibility with every REA provider.

Originally created by @jayykernel on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6335 ### Problem Users who want to run REA in CI need a reliable starting point for installing the supported runtime, invoking an analysis operation, handling its exit status, and retaining machine-readable results. An example reduces the chance of each integration making different assumptions. ### Desired outcome Provide a maintained, minimal GitHub Actions workflow example for analyzing an artifact produced by a build. ### Proposed behavior - Demonstrate analysis of a known build artifact using documented REA interfaces. - Keep generated reports available as workflow artifacts. - Show how to handle analysis failures and unsupported capabilities. - State any external engine or platform requirements explicitly. - Avoid executing untrusted artifacts unless the selected operation requires it and the workflow documents the risk. ### Acceptance criteria - The example can be followed in a clean repository with only documented prerequisites. - Commands and output paths match the current CLI contract. - Failure behavior is explicit and testable. - The example does not require unnecessary credentials or secrets. ### Scope Start with a documentation/example workflow rather than introducing a new GitHub Action or promising compatibility with every REA provider.

bsakaguchi closed this issue

2026-10-31 00:44:22 +00:00

bsakaguchi commented

2026-10-31 00:44:22 +00:00

Author

Owner

@gongfpp commented on GitHub (Oct 23, 2026):

I would like to work on a minimal documented GitHub Actions example using the existing static JavaScript application analysis CLI: a pinned supported Node/REA installation, a known build artifact, machine-readable output retained even on analysis failure, and an explicit distinction between process exit success and partial/unsupported analysis. The example will not add a GitHub Action, provider, execution capability, broad credentials, or optional reverse-engineering engines. I plan to validate the documented public CLI commands and failure/report-retention behavior and state any hosted-runner verification gap rather than imply it was tested. I checked the issue timeline and the current public open-PR index plus recent closed PRs and found no directly overlapping implementation; the visible documentation/workflow PRs appear to address other subjects. Please let me know if someone is already working on this or if there is a preferred example location. This is a coordination note, not an assignment or a claim of scope approval.

@gongfpp commented on GitHub (Oct 23, 2026): I would like to work on a minimal documented GitHub Actions example using the existing static JavaScript application analysis CLI: a pinned supported Node/REA installation, a known build artifact, machine-readable output retained even on analysis failure, and an explicit distinction between process exit success and partial/unsupported analysis. The example will not add a GitHub Action, provider, execution capability, broad credentials, or optional reverse-engineering engines. I plan to validate the documented public CLI commands and failure/report-retention behavior and state any hosted-runner verification gap rather than imply it was tested. I checked the issue timeline and the current public open-PR index plus recent closed PRs and found no directly overlapping implementation; the visible documentation/workflow PRs appear to address other subjects. Please let me know if someone is already working on this or if there is a preferred example location. This is a coordination note, not an assignment or a claim of scope approval.

bsakaguchi referenced this issue

2026-10-31 00:44:30 +00:00

[GH-ISSUE #6405] [Feature] Ghidra: export analyst names and comments from a session and re-apply them when the target is reopened #3835

bsakaguchi referenced this issue

2026-10-31 01:10:26 +00:00

[PR #3817] feat(ghidra): select an existing-project program inside a project folder #5920

bsakaguchi referenced this issue

2026-10-31 01:10:28 +00:00

[PR #3818] feat(ghidra): apply a caller-selected PDB that matches the target #5923

bsakaguchi referenced this issue

2026-11-01 21:11:07 +00:00

[GH-ISSUE #5654] [Tracker] Open PRs that can't merge yet: conflicts and red CI (October 2026) #3425