Skip to content

Add in dynamic version for telemetry using GITHUB_ACTION_REF - #614

Open
MaddyMicrosoft wants to merge 4 commits into
masterfrom
telemetry/action-ref
Open

Add in dynamic version for telemetry using GITHUB_ACTION_REF#614
MaddyMicrosoft wants to merge 4 commits into
masterfrom
telemetry/action-ref

Conversation

@MaddyMicrosoft

@MaddyMicrosoft MaddyMicrosoft commented Aug 17, 2026

Copy link
Copy Markdown
Member

Summary

Reports the action ref the consumer actually pinned in telemetry, instead of a hardcoded version string. Prevents manual changes and drift.

Change

setUserAgent built the AZURE_HTTP_USER_AGENT / AZUREPS_HOST_ENVIRONMENT strings with a hardcoded @v3. Because it was hardcoded, it silently goes stale across major bumps (the same class of bug that currently has the CLI action still reporting @v2 on its v3 release).

This reads GITHUB_ACTION_REF (set by the runner to the ref the workflow pinned, e.g. v3, v3.1.0, a SHA, or main) and uses it in the user-agent, falling back to unknown when it is not set:

let actionRef = process.env.GITHUB_ACTION_REF || 'unknown';
... `GITHUBACTIONS/${actionName}@${actionRef}_...`
  • fixed action concurrency lock

Why

  • The version string can no longer go stale on a major bump; it always reflects the real ref.
  • It is more accurate telemetry: it distinguishes consumers pinned to a major (@v3) from an exact version, a SHA, or main.

Notes

  • Behavior change for telemetry consumers: the value after @ is now the pinned ref rather than always @v3, so downstream parsing that assumed @vN should bucket the new values. Worth a heads-up to whoever owns the user-agent dashboards.

@MaddyMicrosoft
MaddyMicrosoft marked this pull request as ready for review August 17, 2026 06:23
…anch

The live-tests workflow used a fixed resource group name
(GitHubAction_CI_Group) plus a repo-wide concurrency group. Because the
test jobs run behind the Automation test approval gate, an unapproved run
sits in the 'waiting' state holding the shared concurrency lock, which
blocked live-tests on every other PR indefinitely.

Give each run its own resource group by suffixing the name with
github.run_id, and reference it via the RG_POSITIVE env var everywhere
(previously nine jobs used the literal name). With per-run isolation the
repo-wide lock is no longer needed to prevent collisions, so the
concurrency group is now scoped to the branch (github.ref) and only
prevents pile-ups on rapid pushes to the same ref - never across PRs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The per-run resource group name was referenced as the bash-style
"$RG_POSITIVE" in az group show/create/delete run steps. Those steps use
the runner default shell, which is PowerShell on windows-latest, so the
name expanded to an empty string there and az failed with "argument
--name/-n/--resource-group/-g: expected one argument".

Reference the value through the GitHub Actions env expression instead, so
it is substituted before the shell runs, making it shell-agnostic across
ubuntu, windows, and macos. The azure/powershell inline scripts keep
using the PowerShell env form, which is correct there.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant