Wondering why my release GitHub workflow generated 3 GitHub Actions

[Rod-at-DOH]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

I am continuing my journey of learning how to use GitHub Flow. I have three environments: development, staging, and production. I did have all three environments in 3 different jobs in one workflow file. However, I've learned that it might be better to refactor that YAML into two YAML files, one with a different on: for the release. So, that is what I've done. I'm using a simple repo, which doesn't do anything important, such as it doesn't deploy to anywhere. I'm using it to learn how to do this. Once I had that configured, I then created a Release and saw that it used the new .yml to generate a GitHub Action. However, it generated 3 GitHub Actions, all using the same .yml and each of them asking if I want to use production. Basically, they were identical. I could have chosen one of them at random, let it run to completion, then canceled the other two. But I'd like to know why it produced 3 GitHub Action jobs, please. Here's the new workflow file:

name: Single Workflow Release (for production environment)

on:
  release:  
  workflow_dispatch: # manual

jobs:
    production-deploy:
        if: github.event_name == 'release'
        runs-on: ubuntu-latest
        environment: production
        
        steps:
        - uses: actions/checkout@v6
    
        - name: Print value from ENVIRONMENT
          run: echo ${{ vars.DISPLAY_TEXT }}

Could what I'm seeing be caused by there being 3 environments?

[AnkanMisra]

@Rod-at-DOH I don't think this is being caused by the fact that you have 3 environments

What I think is happening is that your workflow is subscribed to the release event too broadly:

on:
  release:
  workflow_dispatch:

When release is configured that way, GitHub Actions listens to all release activity types by default, not just the final "publish" moment. According to the GitHub Actions docs, the release event can fire for published, unpublished, created, edited, deleted, prereleased, and released. The workflow syntax docs also say that if multiple triggering activity types happen as part of the same action, GitHub can create multiple workflow runs.

So the most likely explanation is that when you created/published the release, GitHub emitted multiple release actions for that same release, and your workflow responded to each one. That would explain why you saw 3 nearly identical runs, all pointing to the same workflow file and all waiting for approval on the same production environment.

I would separate that from environments, because environment: production does not tell GitHub to fan out across all environments in the repo. It only tells GitHub that this specific job targets the production environment. GitHub's environment docs are explicit that each job references a single environment. So having development, staging, and production defined would not by itself create 3 runs.

If your goal is "run this once when I publish a release," I would narrow the trigger like this:

name: Single Workflow Release (for production environment)

on:
  release:
    types: [published]
  workflow_dispatch:

jobs:
  production-deploy:
    if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }}
    runs-on: ubuntu-latest
    environment: production

    steps:
      - uses: actions/checkout@v6

      - name: Print value from ENVIRONMENT
        run: echo ${{ vars.DISPLAY_TEXT }}

A few details that may help:

• types: [published] is usually the cleanest option if you want one run when the release is actually published.
• If you care only about stable releases and want to exclude pre-releases, you can look at released, but GitHub's docs specifically recommend published when you want the workflow to run when releases are published.
• In your original workflow, workflow_dispatch is present, but the job itself has if: github.event_name == 'release', so a manual run would start the workflow and then skip the job. That's a separate issue from the 3 runs.

If you want to confirm this in your repo, a simple way is to print the event action in the workflow once:

      - name: Debug event
        run: echo "event=${{ github.event_name }} action=${{ github.event.action }}"

My guess is that those 3 runs would show different github.event.action values for the same release.

So in short: I would not blame the 3 environments. I would blame the unfiltered release trigger.

References:

• Events that trigger workflows
• Workflow syntax for GitHub Actions
• Webhook events and payloads for release
• Deployment environments

[Rod-at-DOH]

Thank you very much for your feedback! I'll experiment with what you've shared to see how it goes.

[Rod-at-DOH]

Thank you for that debug event code. Very helpful.

[AnkanMisra]

Glad to help you buddy 🙌
if you have any more issue or talks do lemme know

[henderson-01]

Hi Rod-at-DOH,

Welcome to the journey of learning GitHub Flow! It's completely normal to run into these quirks when you're first getting started.

To answer your question directly: No, the 3 environments are not causing this. Defining multiple environments simply tells GitHub they exist; it doesn't automatically multiply your workflow runs.

---

The Root Cause

When you use the release trigger without specifying any activity types, like this:

on:
  release:

GitHub Actions defaults to listening for all release activities. According to GitHub's documentation, this includes:

• published
• unpublished
• created
• edited
• deleted
• prereleased

When you create and publish a release through the GitHub web UI, GitHub doesn't just send one signal. It fires a rapid sequence of events (usually created and published, plus edited, depending on how you fill out and submit the form). Because your workflow is listening to any release event by default, it spins up a separate, identical workflow run for every single one of those signals.

---

The Fix

To ensure your workflow only runs exactly once when you actually publish a release, you just need to restrict the activity type to [published].

Update your on: block to look like this:

name: Single Workflow Release (for production environment)
on:
  release:  
    types: [published]
  workflow_dispatch: # manual
jobs:
  # ... rest of your workflow remains the same

With types: [published] added, your workflow will safely ignore the intermediate "created" or "edited" events and run a single time when the release is officially published. Keep up the great work with your learning repo!

[Rod-at-DOH]

Thank you very much for your feedback! I'm going to take your suggestions and try them out.

[Rod-at-DOH]

Your answer is also the answer. I wish I could mark it as an additional answer.