[DEV] workflows: replace deprecated set-output and bump action versions

[treee111]

This PR…

• Removes the deprecated ::set-output workflow command from all three release workflows.
• Bumps actions/checkout and actions/setup-python off their deprecated node runtimes.

Supersedes #303, which targeted the release branch and only fixed git-release-pre.yml.

Considerations and implementations

::set-output

All three release workflows turned GITHUB_REF into a step output just to use it as part of the .zip file name:

- name: Set output
  id: vars
  run: echo ::set-output name=tag::${GITHUB_REF#refs/*/}
...
  env:
    GITHUB_REF_VARIABLE: ${{ steps.vars.outputs.tag }}

::set-output is deprecated by GitHub. It still works today — the pre-release run for 4.4.0a1 used it — but it is slated for removal, and when that happens ${{ steps.vars.outputs.tag }} becomes empty rather than failing. The assets would silently be named wahooMapsCreator-device_themes-.zip.

The usual replacement is writing to $GITHUB_OUTPUT, but the whole step is unnecessary: ${{ github.ref_name }} already is the short name of the branch or tag. So the step is deleted and the context used directly:

  env:
    GITHUB_REF_VARIABLE: ${{ github.ref_name }}

This matters for git-release.yml in particular. It is triggered by a tag, so GITHUB_REF is refs/tags/v4.3.0 — a ${GITHUB_REF#refs/heads/} style fix would have been wrong there. github.ref_name is correct for both trigger types, so all three workflows now use one idiom.

copyFilesToDist.sh is unchanged, and the resulting file names are identical:

push to branch release-v4.4.0  ->  wahooMapsCreator-device_themes-release-v4.4.0.zip
push of tag     v4.3.0         ->  wahooMapsCreator-device_themes-v4.3.0.zip

Action versions

	before	after
git-release.yml, git-release-pre.yml, git-release-test.yml	actions/checkout@v2	@v7
tests.yml	actions/checkout@v3	@v7
tests.yml	actions/setup-python@v3	@v7

@v2 and @v3 run on node runtimes GitHub has deprecated. v7 is the current major of both actions.

The majors in between were checked for anything that would affect this repository:

version	change	relevant here
checkout v5	node 24, needs runner >= v2.327.1	no, GitHub-hosted runners
checkout v6	credentials persisted to a separate file	no, no later git operation needs them
checkout v7	blocks fork-PR checkout for pull_request_target / workflow_run, ESM	no, only push and pull_request are used
setup-python v6	node 24	no
setup-python v7	removes the pip-install input, ESM	no, input is not used

tests.yml is exercised by this PR's own pylint check.

Not addressed here

• docker://antonyurchenko/git-release:latest in all three release workflows is an unpinned third-party image that receives GITHUB_TOKEN. Pinning it to a fixed version tag would be worth a separate PR.
• tests.yml runs on push only for develop, so release branches get pylint only through pull requests.

Note on git-release-test.yml

That workflow is triggered by a push to the git-release branch. For a push event GitHub reads the workflow from the branch being pushed, so the copy that actually runs is the one on git-release — and that copy differs from the one on develop:

   UNRELEASED: "update"
   ALLOW_EMPTY_CHANGELOG: true
+  DRAFT_RELEASE: true          # only on the git-release branch

That flag is why every run of it left behind another draft release on tag latest. Four of those had accumulated and have been deleted.

The change to git-release-test.yml in this PR therefore has no immediate effect — it applies once develop is merged into git-release. It is included so all four workflow files stay consistent.

How to test

1. This PR's own Run pylint tests check exercises the tests.yml changes.
2. Push to a release-* branch — the pre-release is built and the asset is named wahooMapsCreator-device_themes-release-x.y.z.zip, unchanged from before.
3. Push a vX.Y.Z tag — the release asset is named wahooMapsCreator-device_themes-vX.Y.Z.zip, unchanged from before.
4. Neither run logs a set-output deprecation warning any more.

Pull Request Checklist

• Reviewed the Contributing Guidelines
  • Especially the Pull-Requests section
• Commits (and commit-messages) are understandable
• Tested with macOS / Linux
• Tested with Windows

🤖 Generated with Claude Code