[JS] Git commands used in changelog generation are fragile and may cause silent failures

[kazrael2119]

Background
During changelog generation, the tool reads two types of files from a previously released package version:

• review/*.api.md — used for API diff to detect breaking changes and new features
• CHANGELOG.md — used as the base for the new changelog entry
  The primary path is to extract these files from the npm tarball via npm pack ${packageName}@${version}. However, when the files are not found in the tarball (e.g., review/ directory is not in the package's files field), the code falls back to reading them directly from the local git repository using git commands:

// In npmUtils.ts — tryCreateLastestStableNpmViewFromGithub
git --no-pager show ${tag}:${sdkFilePath}           // reads CHANGELOG.md from release tag
git --no-pager show ${tag}:${nodeApiFilePath}        // reads -node.api.md from release tag
git --no-pager show ${tag}:${standardApiFilePath}    // reads .api.md from release tag

// Additional git commands used to validate before calling the above
git tag -l ${tag}                                   // check if release tag exists locally
git ls-tree -d ${tag} ${relativePath}               // check if directory exists in tag

Problem
These git commands are not reliable in standard CI pipeline environments:

• CI pipelines typically use shallow clones (--depth=1), meaning release tags from previous versions are not fetched locally
• git tag -l ${tag} returns empty even when the tag exists remotely → incorrect false → fallback skipped
• git ls-tree -d ${tag} ... fails silently → wrong assumption about package structure
• git --no-pager show ${tag}:... produces empty content → API diff falls back to empty/default → breaking changes or new features suppressed in the generated changelog

Impact

• Wrong log generates or Wrong version bumps
  Case: [AutoPR @azure-arm-containerservice]-generated-from-SDK Generation - JS-5990415 azure-sdk-for-js#37575
  in this pr, the first generation(commit) contains the correct changelog and version
  but in the next commit, we can see so many info with Command failed in the generation pipeline: https://dev.azure.com/azure-sdk/internal/internal%20Team/_build/results?buildId=6019383&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=00be4b52-4a63-5865-8e02-c61723ad0692&l=2482
  which caused the wrong changelog generation

• Failed update UserAgentInfo
  Case: [AutoPR @azure-arm-resourcesdeploymentstacks]-generated-from-SDK Generation - JS-5803515 azure-sdk-for-js#37171
  in this pr, the first generation(commit) generates UserAgentInfo correctly:

but in the next generation
it can't update the version (PS: 1.0.0-beta.1 is a default value in codegen) after re-generation.
and in the next generation pipeline we can see it read nothing from git tag command, but it could read it in the first generation pipeline

@jeremymeng could we still export ./review and CHANGELOG.md in packed packages for the changelog generation?

[jeremymeng]

@kazrael2119 can we switch to normal git checkout for js repo since we need tags and historic version of the files? It probably adds one or two minutes to the pipeline time.

[skywing918]

@jeremymeng I have update the pipeline with full checkout for js repo.
Azure/azure-rest-api-specs#41609

[weshaggard]

CI pipelines typically use shallow clones

We use sparse clones not shallow clones. If tags are need then you should just fetch the tags before hand instead of doing a full clone.

[MaryGao]

@kazrael2119 and @skywing918 — could you help us understand the root cause of this instability? Specifically, why does it sometimes work and sometimes fail? Is this related to our use of sparse clones, where some data might not be available locally?
If the cloned repository is missing certain data, does that mean retries on our side will never succeed in those cases? Can we verify that?

We’ve been seeing these failures much more frequently recently(#14670 (comment)). Could we log a more deterministic error status when this happens? For example, if we detect that version v24 exists but we cannot list the corresponding release tag, that should be treated as a deterministic failure rather than a transient one.

How do we ensure if the fix could help: Azure/azure-rest-api-specs#41609 (review)? Can we verify that?

[skywing918]

Root Cause: azure-sdk/azure-sdk-for-js fork does not sync tags from upstream

The git tag / git ls-tree failures in SDK generation are caused by missing tags in the azure-sdk/azure-sdk-for-js private fork. This fork only contains 104 tags compared to 4164 tags in the upstream Azure/azure-sdk-for-js repository because GitHub's built-in fork sync mechanism syncs branches only — tags are not propagated to forks.

Why the first generation succeeds but the second fails:

The first SDK generation run (e.g., PRs #37171 and #37575) checks out from Azure/azure-sdk-for-js (the public upstream), which has all tags. The second generation run, however, is triggered against the azure-sdk/azure-sdk-for-js fork (as seen in this pipeline run, which checks out from the azure-sdk fork). Since the required tag (e.g., @azure/arm-purview_1.1.0) does not exist in that fork, the automation script fails when attempting to retrieve file contents via git ls-tree <tag> <path>.

first generation:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=5803515&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=d5873a6c-aa4d-5779-a4f7-44513dfead83&l=31

re-generation:

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=5866668&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=d5873a6c-aa4d-5779-a4f7-44513dfead83&l=31

CC: @MaryGao

[MaryGao]

Root Cause: azure-sdk/azure-sdk-for-js fork does not sync tags from upstream

@skywing918 if this is the root cause, do you know sometimes the version bump is correct - https://github.com/Azure/azure-sdk-for-js/pull/37830/changes#diff-a89991edc09e2b4dc0576aa2b75f5d22b131d419b3b1bfd082c1280793212392? will they fail every time?

[skywing918]

Root Cause: azure-sdk/azure-sdk-for-js fork does not sync tags from upstream

@skywing918 if this is the root cause, do you know sometimes the version bump is correct - https://github.com/Azure/azure-sdk-for-js/pull/37830/changes#diff-a89991edc09e2b4dc0576aa2b75f5d22b131d419b3b1bfd082c1280793212392? will they fail every time?

@MaryGao checked the pipleline. it's clone from azure, not azure-sdk, so get correct version.

https://dev.azure.com/azure-sdk/internal/_build/results?buildId=6062570&view=logs&j=83516c17-6666-5250-abde-63983ce72a49&t=d5873a6c-aa4d-5779-a4f7-44513dfead83&l=31