Create GH release with buildenvs #158
Conversation
| gh release create --repo "${{ github.repository }}" "${RELEASE_NAME}" \ | ||
| --generate-notes \ | ||
| --latest \ | ||
| --target "${{ github.push.after }}" ${{ !endsWith( github.event.ref, '-rel' ) && '--prerelease' || '' }} |
There was a problem hiding this comment.
This will create a tag like "2.6-557befb" for every single commit. An set it to latest. We have always some issues with every new build. So I am not sure if this is a good idea.
How does the '-rel' thing work?
There was a problem hiding this comment.
I have here a branch which uses the build artifact directly form the action tab:
https://github.com/daschuer/mixxx/commits/vcpkg_update_direct/
This has the issue that it is removed after a while, but it works nicely during development.
Do we want to inc operate this model and do the GitHub Release after testing?
There was a problem hiding this comment.
That's a good point. We could make the non -rel branch create a pre-release instead, and reserve stable, latest releases for the rel branches. Am I right in thinking that -rel branch only gets updated upon successful tests?
There was a problem hiding this comment.
This happened probably implicit. The -rel branch mainly produces smaller archive because it only contains one set of files without debug builds.
There was a problem hiding this comment.
This happened probably implicit
Great then, I'll leverage that. FYI, a release can always be annually changed, I can we realise that rel release would tun out to be unstable
| if: ${{ github.event_name == 'push' }} | ||
| id: ghrelease | ||
| shell: bash | ||
| name: "Creates a release in GitHub if it doesn't exist yet" |
There was a problem hiding this comment.
We normally have the name on top. You seems to have reverted the sort order of elements.
Please keep the normal sort order.
There was a problem hiding this comment.
normal sort order
Does that mean just "name first" or is there some kind of bespoke ranking I should follow?
There was a problem hiding this comment.
I am not sure if there is something like this.
It is just a good practice to follow the examples in the GitHub Docs:
https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions
- name:
if:
env:
run:
There was a problem hiding this comment.
Not sure which example you are referring to. Only order I can find is the following:
It is just a good practice
Let's just agree to disagree here. However, I'm not willing to block this pressing optimisation over such a minor point. Here are the used keys:
runenvifidshellname
Please give me what order you want and I will update that.
| echo "wrote $outFile" | ||
| $chunkNum += 1 | ||
| } | ||
| (Get-FileHash -Algorithm SHA256 -Path "${{ matrix.vcpkg_path }}/${{ env.VCPKG_ASSET_PATH }}").Hash | Out-File -FilePath "${{ env.VCPKG_ASSET_PATH }}.sha256" |
There was a problem hiding this comment.
It would be nice to have the checksum as action artefact as well. You may also consider to remove the extra checksum generation from our deploy script, to have only a single place where it is done. Remember that it reads GBs.
There was a problem hiding this comment.
It would be nice to have the checksum as action artefact as well
Do you mean to generate the checksum on the flight, when uploading? While being a requested feature, it doesn't seem to be possible currently.
You may also consider to remove the extra checksum generation from our deploy script, to have only a single place where it is done.
Not sure what you mean - are you saying we shouldn't run the checksum on our buildenv script in the Mixxx repo?
Remember that it reads GBs.
Yes, but from a local SSD harddrive. This resource consumption can likely be negligible as we are probably talking <10Wh worth of induced current/month. Or did you mean read from somewhere else?
There was a problem hiding this comment.
No, it would be just a performance benefit to do the checksum calculation only once. Currently it is done in de deploy script and in the workflow.
It is a minor annoyance, that the windows sh256 file has a different format.
I have no experience what is most convenient for a manual check on the users systems though.
There was a problem hiding this comment.
it is done in de deploy script
Are you referring to vcpkg export?
and in the workflow
VCPKG workflow or Mixxx?
This is the first part of the proposal to also use GH release to reduce data round-trips on our runner and improve speed. The current test seems to yield about a ~5x improvement on CI and about the same performance locally, tho slightly slower as the speed tends to fluctuate more.
Note: it also restrains the
pushandpull_requestsCI trigger to prevent double builds