Add CI job to build and upload artifact bundle for releases

[calda]

This PR adds a GitHub Actions CI job that builds swiftformat.artifactbundle.zip for each new release and automatically uploads / attached it to the release page.

• Here's an example release using this: https://github.com/calda/SwiftFormat/releases/tag/0.54-test-upload-release-artifact-3
• And here's the action run that buildtand uploaded the swiftformat.artifactbundle.zip file to that release: https://github.com/calda/SwiftFormat/actions/runs/9454508406

I cut new releases regularly over in https://github.com/calda/SwiftFormat/releases, so automating this process would be helpful. To use this job in that repo I have to upstream it here. I don't know how you're managing this today, but hopefully automating this is helpful for you as well!

I verified that the artifact bundle can be consumed properly by Swift Package Manager.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.23%. Comparing base (b0d492f) to head (ae906cb).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1721      +/-   ##
===========================================
+ Coverage    95.19%   95.23%   +0.04%     
===========================================
  Files           20       20              
  Lines        23248    23248              
===========================================
+ Hits         22131    22141      +10     
+ Misses        1117     1107      -10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[nicklockwood]

This is super-helpful, thank you! Creating the artifact bundle is certainly one of the more annoying manual steps in the release process.

[nicklockwood]

I'm not sure I understand how this is triggered? I was expecting it to run automatically when the release was created, but that didn't happen. Do I need to create build jobs with particular names as you have done?

[calda]

When I was testing in my fork, this ran automatically after tagging a new release.

I see here that no runs of the job have been triggered: https://github.com/nicklockwood/SwiftFormat/actions/workflows/release.yml

So, I don’t know what the problem could be… maybe try again now that the commit with that job is merged to the default branch (master in your repo)? Not sure if that could be relevant or not

I'll see if I can figure out what the issue could be

[nicklockwood]

I merged it prior to tagging the release, so I don't think that's it. It might be easier just to give it a manual trigger anyway, as the release process is sometimes a bit chaotic anyway if something fails and I have to rebase and re-tag.

[calda]

Looking at the documentation here. Right now the job uses a release: [created] trigger:

Note: Workflows are not triggered for the created, edited, or deleted activity types for draft releases. When you create your release through the GitHub browser UI, your release may automatically be saved as a draft.

This is probably the most likely explanation.

It sounds like the recommended trigger is published rather than created:

on:
  release:
    types: [published]

[calda]

Maybe #1730 will fix it

[calda]

Here's another permission you could check: https://github.com/skx/github-action-publish-binaries#github_token

That permission being incorrect would probably make the job fail, rather than just not start in the first place. So, unlikely to be related to this specific issue. But still important to have it configured as needed.