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

[Intermediate]: Remove PR status labels when a pull request is converted to draft

Open
#1,466 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

When a pull request transitions from "ready for review" to draft (`converted_to_draft`), any active `status: needs review` or `status: needs revision` label remains on the PR. These labels are misleading — the PR is not awaiting review and has no revision requirement while in draft state.

The bot currently handles `synchronize` and `edited` events via `on-pr-update.yaml` and `bot-on-pr-update.js`, but the `converted_to_draft` event is not handled. The `on-pr-update.yaml` workflow also has a guard (`if: github.event.pull_request.draft == false`) that prevents it from running on draft PRs at all, so the label is never cleaned up on conversion.

Relevant files:
```
.github/workflows/on-pr-update.yaml
.github/scripts/bot-on-pr-update.js
.github/scripts/helpers/constants.js
.github/scripts/helpers/api.js
.github/workflows/zxc-test-bot-scripts.yaml
```

### 💡 Proposed Approach

Add a new GitHub Actions workflow (`on-pr-converted-to-draft.yaml`) that triggers on the `pull_request_target: converted_to_draft` event, and a corresponding bot script (`bot-on-pr-converted-to-draft.js`) that removes any `status: needs review` or `status: needs revision` labels from the PR. This follows the existing one-workflow-per-event pattern used throughout `.github/workflows/`.

Add unit tests in `.github/scripts/tests/test-on-pr-converted-to-draft-bot.js` and register the test step in `zxc-test-bot-scripts.yaml`, following the pattern already used for the other bot scripts.

### 👩‍💻 Implementation Steps

- [ ] Study the existing bot event handlers (e.g. `bot-on-pr-open.js`, `bot-on-pr-close.js`) and their workflow YAML files — understand how `buildBotContext`, `removeLabel`, `hasLabel`, and `LABELS` are used before writing any code
- [ ] Add a new GitHub Actions workflow that triggers on `pull_request_target: converted_to_draft` and runs a new bot script, following the one-workflow-per-event pattern already established in `.github/workflows/`
- [ ] Implement the bot script to remove `status: needs review` and `status: needs revision` from the PR when the event fires; use `hasLabel` to guard removals and skip bot-authored PRs
- [ ] Add unit tests covering the key cases: each label removed independently, both removed together, neither present, and bot-authored PR skipped
- [ ] Register the new test file in `.github/workflows/zxc-test-bot-scripts.yaml` and confirm all existing tests still pass
- [ ] Open a pull request with all changes

### ✔️ Acceptance Criteria

- [ ] When a PR is converted to draft, any `status: needs review` label is removed
- [ ] When a PR is converted to draft, any `status: needs revision` label is removed
- [ ] If neither label is present, the bot exits cleanly without errors
- [ ] Bot-authored PRs are skipped without modifying labels
- [ ] Unit tests cover all four cases above and pass cleanly
- [ ] The new test step is registered in `zxc-test-bot-scripts.yaml` and runs in CI
- [ ] All existing bot tests continue to pass

---

### 📋 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

If you have questions while working on this issue, feel free to ask!

You can reach the community and maintainers here: [Hiero-SDK-C++ Discord](https://discord.com/channels/905194001349627914/1337424839761465364)

Whether you need help finding the right file, understanding existing code, or confirming your approach — we're happy to help.

Contributor guide

Open the contributing guide

Research direction

Start by comparing .github/scripts/bot-on-pr-open.js and bot-on-pr-close.js with their workflow YAML files, then read bot-on-pr-update.js, constants.js, api.js, and the existing test patterns. Add the converted-to-draft workflow and handler, register .github/scripts/tests/test-on-pr-converted-to-draft-bot.js in zxc-test-bot-scripts.yaml, and run the bot tests; done means both status labels are conditionally removed, bot-authored PRs are skipped, and existing tests pass.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions, javascript
Domain
ci-cd, tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
64/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.