Add SHA256 checksums to release artifacts #1226
Conversation
|
Example release: https://github.com/317project/digger/releases/tag/v0.4.6 I guess the Windows executables automatically get an |
|
Hey @sikha-root ! Thanks for this contribution. It looks good to me. One thing - we can't yet remove cli_release.yml although it duplicates because the action.yml downloads that specific one explicitly (see #1215). We would need to replace it with some os.arch but when running on ubuntu it doesn't actually translate to the same values that go maps to so its a peice of work to figure out in the future. TL/DR; not yet ready to remove the cli_release.yml but rest of the changes look good |
|
@motatoes OK! I need to take care of some things with my git setup but will remove that change once I'm ready. |
Cool! Tag me again when ready @sikha-root |
|
ping @sikha-root any updates? :) just need to bring back cli_release.yml and we are good to go |
|
@sikha-root Closing for now but would love for you to re-open once the file is removed to get it merged, since I love the functionality of having a sha checksum for artefacts and it would be great to have your name on this PR :) |
sikha-root
force-pushed
the
feature/release-checksums
branch
from
497b422
to
2fdb089
Compare
|
@motatoes thanks, I rebased and left out the commit that removed cli_release.yml. |
| uses: actions/upload-release-asset@v1 | ||
| env: | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| - name: Build and publish binary artifact to GitHub |
There was a problem hiding this comment.
I'm getting anxoius about this particular change. I realise that the official action is now unmaintained but I also get anxious about using other third party actions. I'm not sure what the best course of action here is but would rather keep this change out of this PR for a future discussion on the best action to use.
What do you think ?
There was a problem hiding this comment.
I don't think there's much reason for concern when using third-party actions as long as we're pinning to the specific commit like we're doing so here. The code can't change from underneath you (as opposed to using tags that could get redefined). Unless licensing is your concern?
As for keeping this change out of the PR...that's kind of difficult since it technically is the bulk of this PR and iirc I couldn't figure out how to get and upload checksums in separate steps otherwise. But I'm more familiar with Actions now than I was when I opened this PR (using Digger actually is the first time I've used Actions) so maybe I could figure something out. Not sure.
Then again my original incentive for this PR was that I wanted to add download verification to my Ansible role for deploying self-hosted Digger before publishing it but I've recently started using the helm release so it might take a bit before I try to do anything else with this PR.
There was a problem hiding this comment.
OK, its mainly a security concern. The fact that its a hardcoded commit helps. I also would need to make not to not merge rennovate bumps unless the new version also reviewed. Lets merge it for now until we find a new solution
|
|
||
| - name: Build and publish binary artifact to GitHub | ||
| id: build-and-release-binary | ||
| uses: wangyoucao577/go-release-action@8fa1e8368c8465264d64e0198208e10f71474c87 # v1.50 |
There was a problem hiding this comment.
same as my other comment below
This replaces the action used in release workflows with a Go-specific release action, but the build and release process more or less remains the same as before. We effectively only add an additional checksum generation and publish step with this update.
We also remove
cli_release.ymlbecause it buildsdigger-cli-Linux-X64which is the same as thedigger-cli-linux-amd64artifact built bycli_release_multiarch.yml. If this isn't desired, we can remove that commit on request.