Codecov Report

Patch and project coverage have no change.

Comparison is base (04361c9) 67.23% compared to head (abd4762) 67.23%.

@@           Coverage Diff           @@
##             main      #24   +/-   ##
=======================================
  Coverage   67.23%   67.23%           
=======================================
  Files          11       11           
  Lines        1419     1419           
=======================================
  Hits          954      954           
  Misses        405      405           
  Partials       60       60           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Also, I think it can be helpful to also add a cross-compile Make target that will build Alizer for multiple platforms. This will simplify the release.yaml workflow.

Because of the filename of the executable needs to be passed to the next step of the release (Release with Notes and Binaries), I cannot find a way to clearly simplify it (the filename will need to be computed twice or to be passed between the workflow and the build script).

Also, I think it can be helpful to also add a cross-compile Make target that will build Alizer for multiple platforms. This will simplify the release.yaml workflow.

Because of the filename of the executable needs to be passed to the next step of the release (Release with Notes and Binaries), I cannot find a way to clearly simplify it (the filename will need to be computed twice or to be passed between the workflow and the build script).

I just read that the files input parameter of this Action can be a glob expression that could match all the binaries produced by the previous step. So that could be a solution, I guess..

Actually, I was even thinking that this softprops/action-gh-release action may not be needed, since the official gh release CLI can be used to create a release and upload assets as well. So the steps for cross-compiling, and creating a release with the assets, could all be scripted and called in this Workflow. But maybe that can be a separate issue on its own.

Also, I think it can be helpful to also add a cross-compile Make target that will build Alizer for multiple platforms. This will simplify the release.yaml workflow.

Because of the filename of the executable needs to be passed to the next step of the release (Release with Notes and Binaries), I cannot find a way to clearly simplify it (the filename will need to be computed twice or to be passed between the workflow and the build script).

I just read that the files input parameter of this Action can be a glob expression that could match all the binaries produced by the previous step. So that could be a solution, I guess..

Actually, I was even thinking that this softprops/action-gh-release action may not be needed, since the official gh release CLI can be used to create a release and upload assets as well. So the steps for cross-compiling, and creating a release with the assets, could all be scripted and called in this Workflow. But maybe that can be a separate issue on its own.

Yes, I would prefer to handle this as a different issue, to have the opportunity to discuss these choices with @thepetk

Also, I think it can be helpful to also add a cross-compile Make target that will build Alizer for multiple platforms. This will simplify the release.yaml workflow.

Because of the filename of the executable needs to be passed to the next step of the release (Release with Notes and Binaries), I cannot find a way to clearly simplify it (the filename will need to be computed twice or to be passed between the workflow and the build script).

I just read that the files input parameter of this Action can be a glob expression that could match all the binaries produced by the previous step. So that could be a solution, I guess..
Actually, I was even thinking that this softprops/action-gh-release action may not be needed, since the official gh release CLI can be used to create a release and upload assets as well. So the steps for cross-compiling, and creating a release with the assets, could all be scripted and called in this Workflow. But maybe that can be a separate issue on its own.

Yes, I would prefer to handle this as a different issue, to have the opportunity to discuss these choices with @thepetk

We have already a small item to fix the release.yaml devfile/api#1212
I think we can add some more improvements to this workflow and re-refine it again after we update the acceptance criteria.
cc @feloy @rm3l

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: feloy, rm3l, thepetk

The full list of commands accepted by this bot can be found here.