Instead of creating the release by hand and then having a workflow triggered
to add the release, which is not possible if immutable releases are enabled,
we will now:
- run the release workflow on "tag" instead of "release"
- the workflow creates a DRAFT release based on the tag that triggered
- the workflow then attaches the PHAR to the release
- maintainer must then review the release, ensure it is correct, then publish
Once the release is published (assuming immutable releases are enabled):
- the tag is immutable
- the attached assets on the release are immutable
- the flag that dictates pre-release/latest release status is immutable
- the release changelog may still be changed
- the release title may still be changed
- a release attestation is added to the release which can be verified
The release can be verified with:
```shell
gh release verify <release-tag>
```
A given `pie.phar` on your machine can be verified as the release asset with:
```shell
gh release verify-asset <release-tag> pie.phar
```
For more documentation, see:
https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/immutable-releases
