feat(issue-feed): trigger IssueTriage bot on new issues

[lml2468]

背景

v2 方案（已经梦林和 IssueTriage 双方确认）：在现有 octo-issue-feed.yml reusable workflow 里，当新 issue 创建时，额外向 issue-feed 频道发一条 @mention IssueTriage bot 的触发消息。

改动

文件： .github/workflows/octo-issue-feed.yml
改动量： Python 脚本 +9 行，YAML 结构不动

在 event_action == 'opened' 时，追加第三条 send() 调用：

# Trigger IssueTriage bot on newly opened issues
if action == 'opened':
    triage_msg = (
        '@[27pmzxx8nad78c9d01e_bot:Octo 助理-IssueTriage] [TRIAGE] '
        f'https://github.com/Mininglamp-OSS/{repo}/issues/{num}'
    )
    send('151a45970e1546afa9e947ac36a5c4e5', triage_msg)

不变

• 各仓库 caller workflows：零改动
• Org Secrets：零改动
• 现有 feed/proj_msg 逻辑：不受影响

链路

Issue created → octo-issue-feed reusable
  → feed_msg → issue-feed channel (existing)
  → proj_msg → per-repo channel   (existing)
  → triage_msg → issue-feed @IssueTriage  (NEW, opened only)
→ IssueTriage: gh issue view → label type+priority (idempotent)

测试建议

在任意仓库手动创建一个 test issue，确认 IssueTriage 在 issue-feed 收到 [TRIAGE] 消息并自动打上标签。

[yujiawei]

Code Review — PR #17 (.github)

Summary

This PR adds a third send() call in the octo-issue-feed.yml reusable workflow to trigger the IssueTriage bot when a new issue is opened. The triage message is sent to the same issue-feed channel with an @mention payload so IssueTriage can pick it up, fetch the issue, and apply labels.

Verdict: Approve

The change is minimal (+9 lines), well-scoped, and non-breaking. The logic is correct and the implementation is clean.

Detailed Findings

✅ Correctness

• The if action == 'opened' guard correctly limits the triage trigger to new issues only — no spurious triggers on closed, reopened, or labeled events.
• The send() function already handles retries and failure tracking, so the new call gets the same reliability guarantees as the existing ones.
• The repo and num variables used in the f-string are already validated via require_env() earlier in the script.

✅ Channel target

• The triage message is sent to 151a45970e1546afa9e947ac36a5c4e5 (the issue-feed channel) — same as the existing feed message. This is consistent with the described architecture where IssueTriage listens on the issue-feed channel.

✅ Failure handling

• If send() fails for the triage message, it appends to the failed list and the workflow still exits non-zero. This is correct — a failed triage trigger should surface as a workflow failure.

⚠️ Minor observations (non-blocking)

1. Ordering: The triage message is sent after both feed_msg and proj_msg. This means if the first two succeed but triage fails, the workflow exits non-zero even though the primary notifications were delivered. This is acceptable (fail-loud is better than silent skip), but worth noting.

2. Hardcoded channel ID: The channel 151a45970e1546afa9e947ac36a5c4e5 is used twice now (for feed_msg and triage_msg). Extracting it to a variable (e.g. FEED_CHANNEL_ID) would reduce duplication, but this is a style nit — not worth blocking.

3. Bot mention string: The @[27pmzxx8nad78c9d01e_bot:Octo 助理-IssueTriage] format is opaque but presumably matches the Octo IM mention syntax. If the bot ID ever changes, this string needs updating — consider documenting this coupling in a comment. Again, non-blocking.

Security

• No new secrets, permissions, or external inputs introduced.
• The URL in the triage message is constructed from validated environment variables — no injection risk.

Conclusion

Clean, focused change. The implementation is correct and follows existing patterns. Approved.