Reusable workflows with skipped internal jobs cause dependents to be auto-skipped

[nv-tusharma]

Problem

When a job depends on a reusable workflow via needs, GitHub evaluates the result by looking at individual jobs inside the reusable workflow rather than the reusable workflow as a whole. If any internal job is skipped (e.g. optional tests gated by an input flag), this non-success status leaks to the caller and auto-skips downstream jobs — even when the reusable workflow functionally succeeded.

Reusable workflows are meant to be opaque units of work. Callers should not need to know or care about internal job structure. But today, needs breaks this abstraction by evaluating individual sub-jobs instead of the workflow-level result.

Reproduction

# reusable.yml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo built
  optional-test:
    if: inputs.run_tests == true
    needs: [build]
    runs-on: ubuntu-latest
    steps:
      - run: echo tested

# caller.yml
jobs:
  pipeline:
    uses: ./.github/workflows/reusable.yml
    with:
      run_tests: false

  deploy:
    needs: [pipeline]
    runs-on: ubuntu-latest
    steps:
      - run: echo deployed

When run_tests: false, the optional-test job is skipped internally. The deploy job is then auto-skipped because needs sees the skipped sub-job — even though build succeeded and the reusable workflow as a whole completed without failures.

Expected behavior

needs: [pipeline] should report the result of the reusable workflow as a unit, not the results of individual jobs within it. A reusable workflow where all non-skipped jobs succeed should report success to the caller, regardless of how many optional internal jobs were skipped.

Current workaround

Use !cancelled() && !failure() on every job that depends on a reusable workflow:

  deploy:
    needs: [pipeline]
    if: "!cancelled() && !failure()"
    runs-on: ubuntu-latest
    steps:
      - run: echo deployed

This overrides the auto-skip but is a non-obvious workaround that every consumer must remember to apply. It defeats the purpose of reusable workflows being self-contained abstractions.

Proposal

needs should evaluate a reusable workflow's result at the workflow level, not by inspecting individual internal jobs:

• All non-skipped jobs succeed → success
• Any job fails → failure
• All jobs skipped → skipped
• Workflow cancelled → cancelled

This would make reusable workflows truly composable without requiring callers to know about their internal job structure.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[Anghel01]

Great write-up of the issue. You're right that this breaks the abstraction — reusable workflows are supposed to be opaque units but the current needs evaluation leaks internal job structure to callers.
The !cancelled() && !failure() workaround works but it's a footgun that every consumer has to remember, which defeats the point of encapsulation.
Your proposed behavior makes complete sense and aligns with how most CI systems handle composite steps — the parent unit succeeds if all required (non-optional) steps succeed, regardless of skipped optional ones.
This seems like a GitHub Actions product feedback item worth upvoting. In the meantime, another slightly cleaner workaround is adding a final workflow-result summary job inside the reusable workflow with if: always() that always exits with success — that way callers see a clean success status without needing the !cancelled() && !failure() guard on every dependent job.

[vvanouytsel]

I think it is about time that GitHub introduced the concept of ordering jobs without defining them as dependencies...
Today the only possible way to order your jobs is to declare them as dependencies via needs. Which indeed skips the dependent jobs if the job that it depends on is skipped, which makes perfect sense.

If they would allow us to order jobs without defining them as dependencies, all these ugly workarounds would no longer be necessary. For example a after and before keyword that you can specify at the job level.

[vvanouytsel]

@Anghel01, can you elaborate what you mean with the following statement:

another slightly cleaner workaround is adding a final workflow-result summary job inside the reusable workflow with if: always() that always exits with success — that way callers see a clean success status without needing the !cancelled() && !failure() guard on every dependent job.

What does this solve? If your workflow fails it will suddenly show up as green because of that? Am I seeing that wrong?