Github CI warns out deprecated `set-output` command

[dangowrt]

Warning: The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

@aparcar Any idea what to do about this?

[aparcar]

Sure, it's because some of the actions used here are "legacy" and no longer updated. I don't know why @github dropped support for those... If I find the time I'll refactor the workflow used here.

https://github.com/actions/create-release

[lectrical]

The specific warning is due to core of actions being updated and changing how outputs are created/handled. Mostly resolved by the developer of the action updating how it sets outputs.

https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

The reason you can't do this with the particular action used is that most of these official Github actions were sidelined as gh cli was developed and pushed to the forefront. It now provides many of these functions directly and is officially supported and included as as default app in all workflow images.

Here is the specific replacement.

https://cli.github.com/manual/gh_release_create and more generically https://cli.github.com/manual/gh_release

Ultimately, you could always do this via the API directly and don't need an action but gh cli is a better tool for doing this than curl/API calls in a workflow and you can also use it to work with the API. It really is the right tool for the job when working with Github workflows.

I think the example workflow i gave in the PR is a sensible and modern example of how it would be done, where you avoid third party actions as much as is practical. Though the linked https://github.com/ncipollo/release-action is certainly a good drop in replacement that works well, is actively developed and would fix the warning.

Either method would fix the issue and also streamline the workflow.

It's sensible to not to try to publish a release or assets if there is a failure in the build. The reason my example uses two jobs instead of alternate methods to skip/check previous steps is that i want to be able to upload the artifacts even if the publishing of the release was skipped. That would be correct for testing on pull requests where you don't want a release published but can get the artifacts to test.