hiero-ledger / hiero-ledger/hiero-sdk-cpp
[Intermediate]: Investigate shared workflow/action strategy for GitHub bot scripts
- Dominant language
- C++
- Stars
- 42
- Forks
- 108
- Avg merge
- 11h 45m
- Merged PRs (30d)
- 2
Description
### 🧩 Intermediate Friendly
This issue is a good fit for contributors who are already familiar with the Hiero C++ SDK and feel comfortable navigating the codebase.
Intermediate Issues often involve:
- Exploring existing implementations
- Understanding how different components work together
- Making thoughtful changes that follow established patterns
The goal is to support deeper problem-solving while keeping the task clear, focused, and enjoyable to work on.
> [!IMPORTANT]
> ### 🧭 About Intermediate Issues
>
> Intermediate Issues are a great next step for contributors who enjoy digging into the codebase and reasoning about how things work.
>
> These issues often:
> - Involve multiple related files or components
> - Encourage investigation and understanding of existing behavior
> - Leave room for thoughtful implementation choices
> - Stay focused on a clearly defined goal
>
> Other kinds of contributions — from beginner-friendly tasks to large system-level changes — are just as valuable and use different labels.
### 👾 Description of the Task
The C++ SDK workflows currently invoke local bot scripts directly from each workflow using `actions/github-script`. While this works well for a single repository, it makes future migration to shared automation harder because every repository would need to duplicate the same workflow and script execution structure.
Several workflows currently repeat the same execution pattern:
- Checkout default branch
- Run `harden-runner`
- Run `actions/github-script`
- Require a local `.github/scripts/*.js` handler
## Relevant Files
### Workflows
- `.github/workflows/on-pr.yaml`
- `.github/workflows/on-pr-update.yaml`
- `.github/workflows/on-comment.yaml`
- `.github/workflows/on-pr-close.yaml`
- `.github/workflows/on-schedule-inactivity.yaml`
- `.github/workflows/on-pr-review-labels.yaml`
### Bot Handlers
- `.github/scripts/bot-on-pr-open.js`
- `.github/scripts/bot-on-pr-update.js`
- `.github/scripts/bot-on-comment.js`
- `.github/scripts/bot-inactivity.js`
### 💡 Proposed Approach
Re-scope this issue from an implementation refactor into a design investigation.
The goal is not to change the C++ SDK workflows yet. Instead, this task should evaluate whether a shared workflow/action wrapper is actually the right direction for the C++ bot workflows, given the constraints around `pull_request_target`, local composite actions, StepSecurity visibility, per-workflow differences, and the still-evolving `hiero-hackers` automation prototypes.
The output of this issue should be a recommendation, not code changes.
### 👩💻 Investigation Deliverables
- [ ] Identify the actual target among the current `hiero-hackers` automation prototypes, or document that no single target has been selected yet.
- [ ] Define the proposed wrapper/reusable workflow/action interface that SDK repositories would call, including expected inputs such as config path, automation name, token handling, and repository-specific policy.
- [ ] Investigate the StepSecurity impact and document whether `step-security/harden-runner` can remain visible in caller workflows, or whether wrapping it would likely reintroduce duplicate remediation PRs.
- [ ] Provide a concrete before/after example for one simple C++ workflow, such as `.github/workflows/on-pr.yaml`.
- [ ] Provide a concrete before/after example for one awkward C++ workflow, such as `.github/workflows/on-pr-review-labels.yaml` or `.github/workflows/on-pr-close.yaml`.
- [ ] Recommend whether this wrapper/refactor should proceed now, be deferred until the external automation repo/API is mature, or be replaced by a different approach such as keeping workflow wiring local while moving reusable logic into a central action/app.
### ✔️ Acceptance Criteria
- [ ] The issue documents the selected or likely target automation prototype, or clearly states that the target is still undecided.
- [ ] The proposed caller interface is described clearly enough for maintainers to evaluate.
- [ ] StepSecurity behavior is explicitly addressed.
- [ ] At least one simple workflow before/after is included.
- [ ] At least one awkward workflow before/after is included.
- [ ] The final recommendation clearly states whether implementation should proceed, be deferred, or change direction.
- [ ] No production workflow or bot behavior changes are made as part of this issue.
---
### 📋 Step-by-Step Contribution Guide
To help keep contributions consistent and easy to review, we recommend following these steps:
- [ ] Comment `/assign` to request the issue
- [ ] Wait for assignment
- [ ] Fork the repository and create a branch
- [ ] Set up the project using the instructions in `README.md`
- [ ] Make the requested changes
- [ ] Sign each commit using `-s -S`
- [ ] Push your branch and open a pull request
Read [Workflow Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/workflow.md) for step-by-step workflow guidance.
Read [README.md](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/README.md) for setup instructions.
❗ Pull requests **cannot be merged** without `S` and `s` signed commits.
See the [Signing Guide](https://github.com/hiero-ledger/hiero-sdk-cpp/blob/main/docs/training/signing.md).
### 🤔 Additional Information
This issue was originally opened as a preparatory workflow refactor. Based on maintainer feedback, it is now scoped as an investigation so the project can decide whether a shared wrapper/action approach is worthwhile before changing production C++ SDK workflows.
Contributor guide
Research direction
Read the six listed workflows and four .github/scripts/*.js handlers, then compare the simple on-pr.yaml flow with on-pr-review-labels.yaml or on-pr-close.yaml. Review the hiero-hackers automation prototypes and the pull_request_target, local-action, and StepSecurity constraints described in the issue. Done means a documented interface, before/after examples, StepSecurity assessment, and a clear proceed, defer, or change-direction recommendation without production workflow changes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, javascript
- Domain
- ci-cd, devops, tooling
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100