Fix insufficient create-release condition in GitHub Action

[cliffhall]

Description

• In .github/workflows/release.yml
  • in create-release job condition
    • use always() to force evaluation, even if one or more dependencies failed or was skipped
    • check for all combinations of publish results that should lead to a release creation
      • pypi = success / npm = skipped
      • pypi = skipped / npm = success
      • pypi = success / npm = success

Motivation and Context

We still have a problem with Automatic Release Creation where if there are only changes to be published to npm OR pypi BUT NOT both, the final create-release job will not be run. See this recent Action where TypeScript changes were published to npm, but the create-release job was not run.

The problem

The original condition needs.update-packages.outputs.changes_made == 'true' in the create-release job was insufficient because it only checked whether changes were made to packages, but completely ignored the success or failure status of the dependent publishing jobs (publish-pypi and publish-npm). Also, since always() was not part of the condition, it was actually never evaluated in a mixed success case, because the needs field dependencies must all succeed before the condition is evaluated.

The fix

• Use always() to ensure the condition is evaluated even if some dependent jobs fail or are skipped. Without always(), if either publish-pypi or publish-npm failed or were skipped, the release job would be automatically skipped, even if the other publishing job succeeded.
• Verify that at least one publishing job was successful.

How Has This Been Tested?

🤞🏻

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

NOTE: When there have only been changes to the README, i.e., adding official/community servers to the list, but neither npm nor pypi changes to publish, the create-release script would not run.

[domdomegg]

I think the use of always() is not super obvious here - a comment might be useful to explain why it's there?

We might also be able to simplify this more - just checking that at least one has published successfully. If that's the case, even if the other has failed, I think we'd still want to create a GitHub release.

Have raised cliffhall#2 as a potential suggestion