update: workflow optimization

[32teeth]

Pull Request Summary: Build and Release Retro-Go Firmware

This PR introduces a GitHub Actions workflow titled Build and Release Retro-Go Firmware, designed to automate the firmware build and release process for the Retro-Go project.

🚀 Trigger Conditions

• On manual dispatch (workflow_dispatch)
• On pull request closure, only if merged

🔧 Workflow Highlights

• Version Management: Automatically increments the firmware version based on the latest Git tag.
• Build Process:
  • Uses ESP-IDF CI action to build .img and .fw files.
  • Skips the qtpy-gamer target.
  • Validates build success per target and format.
• Artifact Handling:
  • Uploads all firmware binaries as GitHub Actions artifacts.
• Release Automation:
  • Creates a GitHub Release with:
    • New version tag
    • Firmware files
    • Installation instructions
    • Auto-generated file list

📈 Impact

• Eliminates manual steps in firmware delivery.
• Ensures consistent versioning and release documentation.
• Improves traceability and reproducibility of firmware builds.

🧠 Notes

• Uses technology abstraction principles: CI/CD, artifact management, versioning, and release orchestration.
• GitHub token permissions scoped to contents and packages for secure release publishing.

[ducalex]

I don't think generating releases for each PR makes a lot of sense. I don't use a PR workflow myself when I work on retro-go, so it would only be triggered by the rare contribution. And I usually don't want those events to create releases.

But I would be interested in adding a manually triggered pre-release workflow. Basically what you did but pre-release instead of release and with only the workflow_dispatch, and also not replacing the current ci.yml.

That certainly would be convenient to make dev binaries accessible to everybody.