Enhance git-post-store-urls-to-pr action to include supported platforms inline with headline

[Copilot]

This enhancement adds platform information to PR comments generated by the git-post-store-urls-to-pr action. The action now extracts the platforms array from package.json and displays supported platforms inline with the headline in parentheses.

Changes Made

• Added platform extraction step: New step uses jq to extract platforms from package.json with the expression .platforms // ["macOS"] | join(", ")
• Enhanced PR comment format: Platforms now displayed inline with headline in parentheses
• Platform values used as-is: Platform values from package.json are used without transformation since they're already properly capitalized
• Graceful fallback handling: Defaults to macOS when:
  • package.json doesn't exist
  • platforms field is missing
  • JSON is invalid or jq fails

Example Output

Before:

**Published to the Raycast Store:**
https://raycast.com/store/extension1

After (with platforms: ["macOS", "Windows"]):

**Published to the Raycast Store:** (macOS, Windows)
https://raycast.com/store/extension1

After (no platforms field):

**Published to the Raycast Store:** (macOS)
https://raycast.com/store/extension1

Technical Details

The implementation adds a single step that:

1. Checks if package.json exists
2. Uses jq to extract the platforms array directly without value transformation
3. Falls back to "macOS" on any error or missing data
4. Outputs the result for use in the inline comment template

All changes are additive - no existing functionality was removed or modified, ensuring backward compatibility.

This pull request was created as a result of the following prompt from Copilot chat.

Enhance the git-post-store-urls-to-pr action so that the PR comment includes supported platforms, based on the platforms array in package.json. If platforms is missing, default to 'macos'. The comment should display these platforms as plain text, before the Raycast Store URLs. The solution must use jq to extract platforms and handle the absence of the field gracefully within the workflow. The new step must integrate with the existing steps and ensure that the supported platforms are shown in the PR comment.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[pernielsentikaer]

@copilot Can't we just show it after the headline?

A new Extension has been published! (macOS, Windows)
Extension Updated (macOS, Windows): Opera

[Copilot]

@copilot Can't we just show it after the headline?

A new Extension has been published! (macOS, Windows)
...

Updated the format to show platforms inline with the headline as requested. The comment now displays as:

Published to the Raycast Store: (macOS, Windows)

Instead of a separate "Supported platforms:" line. Also updated the capitalization to show "macOS" and "Windows" properly. Changes committed in 5c19eb5.

[pernielsentikaer]

@copilot values in the platform array is already titled correctly so we don't need to change values

[Copilot]

@copilot values in the platform array is already titled correctly so we don't need to change values

You're absolutely right. Removed the value transformation logic since the platform values in package.json are already properly capitalized. The jq expression now simply uses .platforms // ["macOS"] | join(", ") without any mapping transformation. Changes committed in 708908c.

[pernielsentikaer]

@copilot I'm not sure we're the right place, see: https://github.com/raycast/raycast-backend/blob/c754b117cdc33e6ea055d5afc65d2924c58332d7/app/jobs/community_slack_publish_notification_job.rb#L34

[Copilot]

@copilot I'm not sure we're the right place, see: https://github.com/raycast/raycast-backend/blob/c754b117cdc33e6ea055d5afc65d2924c58332d7/app/jobs/community_slack_publish_notification_job.rb#L34

I can see you're pointing to backend code that might already handle platform information. Could you clarify what you'd like me to change? Should I:

1. Remove the platform extraction logic from this GitHub action entirely?
2. Move this logic somewhere else?
3. Or is there a different concern about the current implementation?

I'd like to understand the issue before making changes.