If you're going to update this, could you also fix:

Actions are reusable pieces of code created with Javascript or Docker containers.

1. JavaScript should be constantly written as such
2. It's also possible to write "composite" actions.
   For instance, my check-spelling action is a composite action that currently uses neither Docker nor JavaScript, but will tell you how to spell JavaScript 😉

Well said @Akash1134

Ska

That support site reminds me of how IT's ticketing system at my work used to be. It's not a compliment!

On the bright side, it improved?

yes

@rafaelfronza: you should create your own top level discussion. The 's you have aren't necessary, but they aren't problematic either.

?

I don't understand.

Events happen period
They're dispatched to things configured to listen to them and not to things not configured to listen to them.

If you want, you can log all the properties of the events you receive.

Hi @ElmiraOn!

Great question! Yes, you can definitely check and limit what events trigger your action inside the action itself. Here are several practical approaches:

Method 1: Using Context Variables

Check the Triggering Event

GitHub provides the github.event_name context variable that tells you exactly what event triggered the workflow:

steps:
  - name: Check event type
    run: |
      echo "Event name: ${{ github.event_name }}"
      echo "Event action: ${{ github.event.action }}"

Conditional Step Execution

You can use conditions to only run steps for specific events:

steps:
  - name: Only run on push to main
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    run: echo "This only runs on push to main branch"
    
  - name: Only run on pull request opened
    if: github.event_name == 'pull_request' && github.event.action == 'opened'
    run: echo "This only runs when PR is opened"

Method 2: Event-Specific Conditional Jobs

jobs:
  push-only-job:
    if: github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job only runs on push events"
      
  pr-only-job:
    if: github.event_name == 'pull_request'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job only runs on PR events"

Method 3: Multiple Event Types with Different Behaviors

on:
  push:
    branches: [main]
  pull_request:
    types: [opened, synchronize]
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        
      - name: Handle different events
        run: |
          case "${{ github.event_name }}" in
            "push")
              echo "Handling push event"
              echo "Pushed by: ${{ github.event.pusher.name }}"
              ;;
            "pull_request")
              echo "Handling PR event"
              echo "PR action: ${{ github.event.action }}"
              echo "PR number: ${{ github.event.number }}"
              ;;
            "workflow_dispatch")
              echo "Manually triggered"
              ;;
            *)
              echo "Unknown event: ${{ github.event_name }}"
              ;;
          esac

Method 4: Using Outputs for Event-Based Logic

jobs:
  detect-event:
    runs-on: ubuntu-latest
    outputs:
      is-push: ${{ github.event_name == 'push' }}
      is-pr: ${{ github.event_name == 'pull_request' }}
      branch-name: ${{ github.ref_name }}
    steps:
      - run: echo "Event detection complete"
        
  conditional-job:
    needs: detect-event
    if: needs.detect-event.outputs.is-push == 'true'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This only runs for push events"

Method 5: Advanced Event Property Checking

steps:
  - name: Detailed event inspection
    run: |
      echo "Event: ${{ github.event_name }}"
      echo "Repository: ${{ github.repository }}"
      echo "Ref: ${{ github.ref }}"
      echo "SHA: ${{ github.sha }}"
      echo "Actor: ${{ github.actor }}"
      
      # For push events
      if [ "${{ github.event_name }}" = "push" ]; then
        echo "Push event details:"
        echo "  Before: ${{ github.event.before }}"
        echo "  After: ${{ github.event.after }}"
        echo "  Forced: ${{ github.event.forced }}"
      fi
      
      # For PR events
      if [ "${{ github.event_name }}" = "pull_request" ]; then
        echo "PR event details:"
        echo "  Action: ${{ github.event.action }}"
        echo "  Number: ${{ github.event.number }}"
        echo "  Title: ${{ github.event.pull_request.title }}"
      fi

Key Context Variables Available:

• github.event_name - The event that triggered the workflow
• github.event.action - The specific action that occurred (for events like PR)
• github.ref - The branch or tag ref
• github.sha - The commit SHA
• github.actor - The username of the person who initiated the event
• github.event.* - All event payload data

Pro Tips:

1. Debug Events: Use echo '${{ toJSON(github.event) }}' to see the full event payload
2. Combine Conditions: Use && and || for complex conditions
3. Environment Variables: Set event-based environment variables for reuse
4. Matrix Strategy: Use different matrix configurations based on events

Example: Environment-Based Event Handling

env:
  EVENT_TYPE: ${{ github.event_name }}
  IS_MAIN_BRANCH: ${{ github.ref == 'refs/heads/main' }}
  
steps:
  - name: Event-based logic
    run: |
      if [ "$EVENT_TYPE" = "push" ] && [ "$IS_MAIN_BRANCH" = "true" ]; then
        echo "Deploy to production"
      elif [ "$EVENT_TYPE" = "pull_request" ]; then
        echo "Run tests and deploy to staging"
      else
        echo "Run basic validation only"
      fi

This approach gives you complete control over how your action behaves based on the triggering event, all from within the workflow file itself! Let me know if you need help with any specific event handling scenarios.

Hi! Here’s how you can detect and limit events inside your action:

1. How GitHub Actions exposes the event

Environment variables:

GITHUB_EVENT_NAME # e.g., push, pull_request
GITHUB_EVENT_PATH # path to full JSON payload
GITHUB_REF # branch or tag

github.context (for JavaScript/TypeScript actions):

const github = require('@actions/github');

console.log(github.context.eventName); // "push" or "pull_request"
console.log(github.context.payload); // full webhook payload

2. Checking/limiting event inside the action

JavaScript:

const core = require('@actions/core');
const github = require('@actions/github');

const allowedEvent = 'pull_request';
if (github.context.eventName !== allowedEvent) {
core.info(This action only runs on ${allowedEvent}, skipping...);
process.exit(0);
}

// continue main logic

Bash:

if [ "$GITHUB_EVENT_NAME" != "pull_request" ]; then
echo "This action only runs on pull_request events. Skipping..."
exit 0
fi

3. Use cases

Reusable workflows: same workflow called from multiple events but only some steps run on certain events.

Custom actions: action runs only for specific events even if workflow triggers from multiple events.

✅ Key takeaway: You cannot prevent a workflow from triggering once the event happens (set in workflow file), but you can detect and limit actions inside the action itself using GITHUB_EVENT_NAME or github.context.eventName.

Исполнители: это машины (размещённые на GitHub или на вашем собственном сервере), на которых выполняются ваши действия. Вы можете выбрать исполнителей, размещённых на GitHub, которыми управляет GitHub, или исполнителей на вашем собственном сервере, которыми вы управляете в своей инфраструктуре. Действия: это отдельные задачи, которые можно объединять в задания в рамках рабочего процесса. Действия можно создавать с помощью JavaScript или контейнеров Docker. Рабочие процессы: рабочие процессы, определяемые в файлах YAML, задают задачи автоматизации, которые выполняются в ответ на определённые события (например, отправку кода).

https://github.com/orgs/community/discussions/48283#discussioncomment-11943026

Hi @Reaidetnalio The best route to get this to the proper GitHub team is to use our abuse reporting tools. Here's all the info:

• Reporting abuse or spam
• Reporting a user
• Reporting an issue or pull request
• Reporting a comment

You can report behavior and content that violates community guidelines and terms. We are going to close this post, but for this and any future incidents, please refer to the links above.

Thank you!