[CI] Migrate set-output commands to new format

[TheRealKeto]

Github announced this year that they've begun deprecating the old pattern for set-output (and save-state) commands, detailed on the link below. This PR migrates all of the used workflows to this breaking change.

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

Other changes in this PR include:

• Upgrade all actions used to their latest version, removing any warnings about old versions of NodeJS
• Add a title to each job on all workflows to indicate the build type (e.g Build (rootless) should be clear enough to users and developers that job is building the project with rootless support)

[kirb]

Add a title to each job on all workflows to indicate the build type

Thank youuuu, I couldn’t figure that out from the docs. Must have totally missed it.

Not super related but there’s an annoying problem with the release action where the website repo has multiple commits in a few minutes (the non-rootless and rootless builds), and one action gets cancelled while another succeeds. Any ideas of how I can ensure correct ordering by any chance? Not the biggest deal because it seems to work in the right order, but I fear it’ll end up racing and not building the repo in the right order at some point, one build gets deployed to Packages but not the other.

[TheRealKeto]

The current behavior of the release workflow (where one action gets cancelled and another succeeds) might be caused by the cancel-in-progress field under the concurrency section of both workflows.

Looking at the docs, it seems that this behavior is intended when the mentioned field is set to true.

When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. Any previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.

https://docs.github.com/en/actions/using-jobs/using-concurrency#overview

Both workflows are assigned the same concurrency group and contain two jobs that are identical (one for a normal build and another for rootless, respectively), which would cause this behavior to occur.

The best approach, from what I understand, is to remove that field. This should simply queue any other job(s) or workflow(s) even when they have the same concurrency group (which would also not required the need to wait for an already running workflow with one concurrency group to finish in order to trigger the next). Hoping that explains things well!

[kirb]

Squashed and merged with the mentioned fix in 4894b4a4 💪