Publish immutable releases

[msusta]

Describe the enhancement

Switch to immutable releases for this repository.

Additional context

Github is offering a functionality to set releases as immutable - once the git tag or release asset is created, it cannot be changed or deleted.

This was considered a best practice anyhow, but become more of a pressing issue after the latest string of issues surrounding Trivy. As a tool used to deliver infra, this tool will usually have access to very strong credentials and any additional security layer can help.

I'm not sure how the full release process looks like in Gruntwork, but I'd not expect this to be a major undertaking with big negative effects.

[yhakbar]

Hey @msusta ,

I'm not sure we can support this in Terragrunt, but we're open to discussing this.

We've previously encountered issues with GitHub Release assets being successfully uploaded, but being inaccessible for download due to issues on the Azure blob store backend for GitHub (see #3220). In those situations, we've had to re-upload release assets clobbering the previous release asset to bypass the issue with the backend.

When assets are uploaded, and can be reliably downloaded without issue, we don't overwrite them, but I believe enabling that immutable release setting would prevent us from fixing release assets when the storage backend fails to make them available for download.

I'm not sure there's a way around this issue.

[jpalomaki]

@yhakbar Would it help if you initially create a draft release, then attach assets, verify that the assets are truly downloadable, and finally publish the draft (which then makes the release immutable)?

See https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases#best-practices-for-publishing-immutable-releases

[yhakbar]

Oh, I had no idea we could do that. Seems sensible. Ya, I think that addresses our concerns. We can look to support this post-1.0 barring any other issues.