Fix issue-comment.yml workflow incorrect triggering

[bhouston]

GitHub Issue Comment Trigger Investigation

I'm investigating why the issue-comment.yml workflow is being triggered incorrectly. Based on the workflow file, it should only run when:

1. A comment is created on an issue or PR
2. The comment contains the text '/mycoder'
3. The comment is made by the user 'bhouston'

The current workflow definition has:

on:
  issue_comment:
    types: [created]

jobs:
  process-comment:
    runs-on: ubuntu-latest
    # Only run if comment contains '/mycoder' AND commenter is in AUTHORIZED_USERS list
    if: |
      contains(github.event.comment.body, '/mycoder') && 
      github.event.comment.user.login == 'bhouston'

I need to create a GitHub issue to track this problem and propose a solution.

[bhouston]

Investigation Results

After investigating, I found that the workflow is working as designed. Here's what's happening:

1. The on: issue_comment: types: [created] trigger causes the workflow to be initiated for every new comment on an issue or PR
2. The if: condition in the job is then evaluated to determine if the job should actually run
3. If the condition is false (comment doesn't contain '/mycoder' or isn't from 'bhouston'), the job is skipped, but the workflow still shows up in the GitHub Actions logs as having been triggered

This is normal behavior for GitHub Actions. The workflow is being triggered for all comments (which is correct according to the trigger definition), but the job is only running when the condition is met.

Options to Reduce Unnecessary Workflow Triggers

If you want to reduce the number of unnecessary workflow triggers, there are a few options:

1. Use a different trigger: If there's a more specific event that better matches your use case, that could reduce triggers.

2. Add a path filter: If the comment is related to specific files, you could add a path filter.

3. Use a webhook and custom API endpoint: For more granular control, you could set up a webhook that only triggers on specific comment patterns and have it call a GitHub Actions workflow_dispatch event.

4. Accept the current behavior: Since the job isn't actually running unless the condition is met, this might be the simplest approach. The workflow is triggered but exits quickly if the condition isn't met, so the resource usage is minimal.

I recommend option 4 - accept the current behavior, as it's the standard way GitHub Actions works and has minimal impact on resources.

[bhouston]

Thank you for investigating this issue! Your explanation makes perfect sense.

To summarize what's happening:

1. GitHub Actions workflows are first triggered based on the event (in this case, all issue comments via on: issue_comment: types: [created])
2. Then, the job conditions (if: statements) are evaluated to determine if the job should actually run
3. This means the workflow will appear in the GitHub Actions logs for all issue comments, but will exit early (showing as "skipped") if the conditions aren't met

This is the expected behavior for GitHub Actions, and the workflow is working correctly. The workflow is being triggered for all comments, but the job is only running when a comment contains "/mycoder" and is from the authorized user.

I'll merge the PR that adds documentation to clarify this behavior in the workflow file. This will help future developers understand why the workflow appears in the logs even when it doesn't run.

Thanks again for the detailed investigation!

[bhouston]

Not required right now.