💬 Proposal: Simplify Release Workflow

[DevTwilight]

I propose simplifying release pipeline by:

1. Flattening downloaded artifacts using merge-multiple
2. Replacing softprops/action-gh-release with gh cli
3. Reducing dependency on third-party GitHub Actions

This keeps the workflow simpler, more explicit, and more maintainable.

🔧 Current Behavior

Artifact structure (current)

Without merge-multiple, downloaded artifacts are extracted into separate directories:

artifacts/
  linux-build/
    gdscript-formatter.zip
  windows-build/
    gdscript-formatter.zip

This requires recursive globbing:

artifacts/**/*.zip

Release creation

We currently use:

  softprops/action-gh-release@v2

which abstracts release creation and asset upload behind a third-party action.

🚀 Proposed Changes

1. Flatten artifact structure

  - uses: actions/download-artifact@v4
    with:
      path: artifacts
      merge-multiple: true

Result

  artifacts/
    linux.zip
    windows.zip
    macos.zip
    addon.zip

This allows simpler asset handling:

  artifacts/*.zip

2. Replace softprops/action-gh-release with GitHub CLI

Replace:

  uses: softprops/action-gh-release@v2

with

  - name: Release
    run: |
      gh release create "$VERSION" artifacts/*.zip \
        --verify-tag \
        --title "GDScript formatter $VERSION" \
        --notes "A fast code formatter for GDScript in Godot 4.
  
  You can learn how to install, use, configure, and integrate the formatter into your workflow on this page:
  
  https://www.gdquest.com/library/gdscript_formatter/"
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      VERSION: ${{ github.ref_name }}

📊 Benefits

✔ Simpler artifact handling

• flat directory structure
• no recursive globbing

✔ More explicit release logic

• release creation and uploads are visible directly in workflow code
• easier to debug and maintain

✔ Reduced dependency on third-party actions

• relies on official GitHub CLI (gh)
• reduces external action maintenance and supply-chain risk
• fewer external dependencies in release infrastructure

✔ Easier extensibility

Future enhancements become easier:

• changelog generation
• release validation
• conditional uploads
• release discussions
• automated notes

✅ Conclusion

This proposal simplifies the release stage by flattening downloaded artifacts and using the official GitHub CLI for release management while keeping the overall workflow structure unchanged.

If this approach is considered acceptable, I would be happy to contribute the implementation.

[NathanLovato]

Swapping a dependency (release action) with another (gh), even if one is considered official, does not reduce the risk of supply chain attacks by much as both are ultimately programs that could run malicious code and the widely used gh program could also get targeted.

I'm generally in favor of reducing dependencies all around and notably in CI, so if we could replace all actions with a single program I'd be interested. Alternatively, pinning package versions to known sane version and not touching them is fine by me.

[DevTwilight]

The motivation behind the recent Node 24 update PR was mainly to keep the workflow compatible with GitHub’s upcoming Actions runtime changes rather than to reduce dependencies. GitHub is deprecating Node 20 for Actions runners and transitioning workflows toward Node 24 as the supported runtime. Because of this, Actions that still depend on older runtimes may eventually require compatibility flags or stop working correctly on updated runners. The PR was therefore intended as forward-compatibility maintenance to ensure the CI pipeline continues working on the standard supported runner environment without relying on deprecated execution behavior.
Reference
#228

For the release workflow proposal, I agree that replacing one dependency with another does not significantly eliminate supply-chain risk on its own, since both the release Action and gh are still executable programs interacting with the GitHub API and repository secrets. My reasoning for suggesting the official gh cli is instead centered around workflow transparency, maintainability, and reducing workflow-level Action dependencies. It gives us more control over release behavior through explicit commands rather than an abstraction layer, and it is already available on GitHub-hosted runners, which avoids introducing an additional external Action dependency. This keeps the workflow closer to the standard runner environment while still retaining full flexibility over release operations.