hiero-ledger / hiero-ledger/hiero-sdk-cpp

[Intermediate]: Investigate shared workflow/action strategy for GitHub bot scripts

Open
#1,627 12 comments 0 reactions 0 assignees View on GitHub
priority: low scope: ci skill: intermediate status: ready for dev
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.