ci: use envs in GHAs and pin versions

[mdtro]

• Running these workflows is gated pretty well, but this mitigates the potential for a script injection attack by passing the input to an intermediary environment variable first.
  • See https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#example-of-a-script-injection-attack for more details.
• Using version tags or no specifier at all can open us up to dependency attacks. Pinning the SHA is a strong mitigation.
  • See: https://semgrep.dev/blog/2025/popular-github-action-tj-actionschanged-files-is-compromised/

[Jeffreyhung]

@mdtro I noticed you updated quite a few variable references from double curly brace to single curly brace
e.g ${{ inputs.unity-version }}' to "${UNITY_VERSION}"
Is that on purpose?

[mdtro]

@mdtro I noticed you updated quite a few variable references from double curly brace to single curly brace e.g ${{ inputs.unity-version }}' to "${UNITY_VERSION}" Is that on purpose?

Yes, it is intentional. With double curly brackets ${{...}} it is still using GHA's template expansion. Instead, those values are set in the env: clauses at the top of the workflow, job, or particular step -- depending on where they're needed.

Using single brackets ${VARNAME} means the environment variable is used and the shell itself does the variable expansion.

[bruno-garcia]

Thanks for opening this.

cc @getsentry/gdx @tustanivsky @vaind @jamescrosswell @limbonaut @bitsandfoxes something to keep in mind going forward