fix: read GITHUB_EVENT_PATH using @actions/github

[tcely]

PR Type

Bug fix, Enhancement

---

Description

• Read GitHub event data using @actions/github instead of environment variables

• Rename optionalFollowUpLabelColor to optionalFollowUpColor for consistency

• Improve event type detection with explicit action validation

• Add environment variable mapping for action inputs in workflow

• Refactor handleClosedIssue to use sender ID comparison

---

Diagram Walkthrough

flowchart LR
  A["Environment Variables"] -->|"Replace with"| B["@actions/github context"]
  C["optionalFollowUpLabelColor"] -->|"Rename to"| D["optionalFollowUpColor"]
  E["Event Action Detection"] -->|"Improve validation"| F["Explicit type checks"]
  G["action.yml inputs"] -->|"Map to"| H["Environment variables"]
  I["handleClosedIssue"] -->|"Refactor with"| J["Sender ID comparison"]

Loading

File Walkthrough

	Relevant files
Enhancement	main.ts Use @actions/github for event context                                        src/main.ts Replace process.env['GITHUB_EVENT_NAME'] and process.env['GITHUB_EVENT_ACTION'] with github.context.eventName and github.context.payload.action Add explicit event type validation for issue_comment and issues events Improve logging to include both event name and type Add unrecognized event type warnings +17/-9    config.ts Standardize optional follow-up color naming                            src/config.ts Rename optionalFollowUpLabelColor property to optionalFollowUpColor Update input reading to check both new and old input names for backward compatibility Fix documentation comment for the color property +6/-3
Bug fix	no-response.ts Update color reference and improve issue closure validation src/no-response.ts Update reference from optionalFollowUpLabelColor to optionalFollowUpColor Refactor handleClosedIssue to validate event name and use sender ID comparison instead of login comparison Reorder initialization to fetch payload before using it +6/-5
Configuration changes	action.yml Add new input and maintain backward compatibility                action.yml Add new optionalFollowUpColor input with default value Mark old optionalFollowUpLabelColor input as compatibility-only Add environment variable mappings for all inputs in the Run Action step +14/-2
Documentation	README.md Update documentation for renamed input                                      README.md Update input documentation to reflect optionalFollowUpColor instead of optionalFollowUpLabelColor +1/-1

---

[qodo-code-review]

Review Summary by Qodo

Use @actions/github for event data and rename color inputs

🐞 Bug fix ✨ Enhancement

Walkthroughs

Description

• Read GitHub event data using @actions/github instead of environment variables
• Rename optionalFollowUpLabelColor to optionalFollowUpColor for consistency
• Add backward compatibility for deprecated optionalFollowUpLabelColor input
• Improve event type validation and error handling in main workflow
• Fix handleClosedIssue to use sender ID comparison instead of login
• Restore environment variable mapping from action inputs in workflow

Diagram

flowchart LR
  A["GitHub Event"] -->|"@actions/github"| B["Event Context"]
  B --> C["Event Name & Type"]
  C --> D["Event Handlers"]
  D --> E["Improved Validation"]
  F["Config Inputs"] -->|"Renamed"| G["optionalFollowUpColor"]
  G --> H["Backward Compatible"]

Loading

File Changes

1. src/main.ts ✨ Enhancement +17/-9

Use @actions/github for event data reading

• Replace process.env with github.context for reading event name and action
• Extract and validate event type from github.context.payload.action
• Add event type validation for issue_comment and issues events
• Add informational logging for unrecognized event types
• Use strict equality comparisons for event name checks

src/main.ts

---

2. src/config.ts ✨ Enhancement +6/-3

Rename color input with backward compatibility

• Rename optionalFollowUpLabelColor property to optionalFollowUpColor
• Update JSDoc comment to describe color encoding as hex string
• Add fallback logic to read deprecated optionalFollowUpLabelColor input for backward
 compatibility
• Maintain support for both old and new input names

src/config.ts

---

3. src/no-response.ts 🐞 Bug fix +6/-5

Fix closed issue handler and update color reference

• Update reference from optionalFollowUpLabelColor to optionalFollowUpColor
• Refactor handleClosedIssue to validate event name and action type
• Change sender validation from login string comparison to ID comparison
• Move payload type casting earlier in function
• Add early return for invalid event context

src/no-response.ts

---

View more (2)

4. action.yml ⚙️ Configuration changes +14/-2

Add new input and environment variable mappings

• Add new optionalFollowUpColor input with default value ffffff
• Mark optionalFollowUpLabelColor as deprecated with compatibility note
• Add environment variable mappings for all inputs in Run Action step
• Map action inputs to INPUT_* environment variables for core.getInput() compatibility

action.yml

---

5. README.md 📝 Documentation +1/-1

Update documentation for renamed input

• Update input documentation to reflect renamed optionalFollowUpColor parameter
• Change table entry from optionalFollowUpLabelColor to optionalFollowUpColor

README.md

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Legacy color ignored ☑ 🐞 Bug ✓ Correctness

Description

Config.optionalFollowUpColor always resolves from optionalFollowUpColor first, and action.yml
gives that input a non-empty default, so the fallback to legacy optionalFollowUpLabelColor is
never reached at runtime. This silently breaks existing workflows that only set
optionalFollowUpLabelColor (their chosen color is ignored).

Code

src/config.ts[R84-87]

+    this.optionalFollowUpColor =
+      core.getInput('optionalFollowUpColor') ||
+      core.getInput('optionalFollowUpLabelColor') ||
+      undefined

Evidence

action.yml sets a default for optionalFollowUpColor and also exports it into
INPUT_OPTIONALFOLLOWUPCOLOR, so core.getInput('optionalFollowUpColor') will be truthy even when
users only provide the legacy input. Because src/config.ts checks the new input first with ||,
the legacy input can never be used in that common migration scenario.

src/config.ts[82-88]
action.yml[21-28]
action.yml[78-91]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Backward compatibility for `optionalFollowUpLabelColor` is broken. Because `optionalFollowUpColor` has an `action.yml` default, `core.getInput('optionalFollowUpColor')` is always non-empty at runtime, so the fallback to `optionalFollowUpLabelColor` in `Config` is never used.
### Issue Context
Goal appears to be: support new `optionalFollowUpColor` while still honoring the legacy `optionalFollowUpLabelColor` when the new input is not explicitly provided.
### Fix Focus Areas
- action.yml[21-28]
- action.yml[78-91]
- src/config.ts[82-88]
### Suggested fix approach
- Remove the `default: ffffff` from `optionalFollowUpColor` in `action.yml` (or otherwise ensure it can be empty when not explicitly set).
- In `Config`, compute:
- `const newVal = core.getInput('optionalFollowUpColor')`
- `const legacyVal = core.getInput('optionalFollowUpLabelColor')`
- `this.optionalFollowUpColor = newVal || legacyVal || 'ffffff'`
This preserves precedence (new overrides legacy when explicitly set) while keeping the default behavior.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more