Add GitHub Actions workflows to attach release assets. Fix #427

[BrianHenryIE]

Adds two GitHub Actions workflows, one running MacOS and the other Ubuntu, triggered by new releases, each of which updates the version number and runs swift build --disable-sandbox -c release, zips the file and attaches it to the release.

I'm not sure why it uses --disable-sandbox, I copied that from Iron-Ham/swift-format-linter-action but maybe it's unnecessary?

The MacOS asset also contains disable-codesigning.sh which contains the command xattr -c swift-format because otherwise :

"swift-format" cannot be opened because the developer cannot be verified

While I say fixes #427, rather than trigger on tag, this is triggered on release.

Main isn't building for me so I branched at 508.0.1 and tested on that: https://github.com/BrianHenryIE/swift-format/releases

[allevato]

I appreciate the effort here, but I believe this repository (and many of Apple's Swift repositories) doesn't have Github Actions enabled (the Actions tab is hidden at the top).

I'd prefer to get swift-ci triggers working directly in this repository, since I currently have to use a fake paired PR in swift-syntax to kickstart it (@shahmishal @ahoppen). I'm not personally privy to the policy decisions around which repositories have Github actions and which don't (the only one I know of without checking is swift-protobuf), but since swift-format is integrated into toolchain builds, at a minimum we do need swift-ci to ensure that swift-format doesn't break any other components.

Once we have that, even if we could use Github actions for other things, I don't know if having to maintain both kinds of checks would be worth the effort.

[natikgadzhi]

@BrianHenryIE, thank you for putting these together! I've had a similar itch + formatting #610.

Similar conversations re: GitHub Actions in apple/swift-org-website: swiftlang/swift-org-website#217 (comment). Most other Apple repos use @swift-ci.

[BrianHenryIE]

the Actions tab is hidden at the top

Oh, it never occurred to me to check!

I don't know if having to maintain both kinds of checks would be worth the effort.

For the general lint CI step, I think it is valuable to have GitHub Actions running here as documentation for other projects to copy.

For this particular issue, the assets will need to be attached to the release via some GitHub API, so this might be an easy option. I presume to fix the unverified developer warning, a private key would have to be uploaded to GitHub Actions Secrets, and it's probably preferred to keep that inside Apple infrastructure.

I'll take a look at @swift-ci and see what I can learn. I had been planning to write another Action to automatically update the version number (as done in this PR, additionally in the README) and commit to main on new releases.

[jesus-mg-ios]

Can Xcode Cloud be used to build the binary and notarize it? It could be a simpler and more secure way to do it and post the release binaries elsewhere when the Xcode cloud ends. @natikgadzhi