Add release automations

[jamesadevine]

No description provided.

[github-actions]

🔍 Rust PR Review

Summary: Has a critical bug — checksum verification will always fail in generated pipelines due to filename mismatch.

Findings

🐛 Bugs / Logic Issues

• templates/base.yml (and 1es-base.yml): SHA256 checksum verification will always fail

  The release workflow (release.yml) generates the checksum by running:

  sha256sum ado-aw-linux-x64 > ado-aw-linux-x64.sha256

  This produces a file whose content is: (hash) ado-aw-linux-x64

  But the download scripts in the templates do:

  curl -fsSL -o "$DOWNLOAD_DIR/ado-aw" "$DOWNLOAD_URL"        # saved as "ado-aw"
  curl -fsSL -o "$DOWNLOAD_DIR/ado-aw.sha256" "$CHECKSUM_URL" # checksum references "ado-aw-linux-x64"
  cd "$DOWNLOAD_DIR"
  sha256sum --check ado-aw.sha256                              # looks for "ado-aw-linux-x64" — doesn't exist!

  sha256sum --check reads the filename embedded in the checksum file (ado-aw-linux-x64) and tries to verify it. That file doesn't exist in $DOWNLOAD_DIR — only ado-aw does. This will produce sha256sum: ado-aw-linux-x64: No such file or directory and abort every generated pipeline.

  Fix — download the binary using its original name, then rename after verification:

  curl -fsSL -o "$DOWNLOAD_DIR/ado-aw-linux-x64" "$DOWNLOAD_URL"
  curl -fsSL -o "$DOWNLOAD_DIR/ado-aw-linux-x64.sha256" "$CHECKSUM_URL"
  cd "$DOWNLOAD_DIR"
  sha256sum --check ado-aw-linux-x64.sha256
  mv ado-aw-linux-x64 ado-aw
  chmod +x ado-aw

  This is the same fix needed in all six download blocks across both template files.

⚠️ Suggestions

• release.yml: Unpinned action versions — googleapis/release-please-action@v4, dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2, and actions/checkout@v4 are all referenced by branch/tag rather than commit SHA. For a release workflow that uploads binaries to GitHub Releases, supply-chain pinning (e.g., googleapis/release-please-action@v4.1.3) is worth considering.

• release.yml: No set -e in Prepare release assets step — the run: block uses cd + cp + sha256sum without set -euo pipefail. If cd target/release fails the subsequent cp would operate in the wrong directory and silently upload a wrong or empty file. Adding set -euo pipefail at the top of that block is a low-effort safety improvement.

✅ What Looks Good

• Using env!("CARGO_PKG_VERSION") at compile time is the right call — it ensures pipelines are always pinned to the exact compiler version that compiled them, no drift possible.
• curl -fsSL with -f (fail on HTTP error) is correct; a 404 from GitHub Releases will abort the step instead of silently downloading an HTML error page.
• The release-please setup with release-type: rust will correctly bump Cargo.toml version, keeping env!("CARGO_PKG_VERSION") in sync.
• The new test assertions in compiler_tests.rs cover the right invariants (no pipeline 2437 reference, GitHub Releases URL present, checksum step present).

Generated by Rust PR Reviewer for issue #14 · ◷

[github-actions]

🔍 Rust PR Review

Summary: Looks good — clean migration from internal ADO artifact to public GitHub Releases with checksum verification. Two minor issues worth addressing.

Findings

⚠️ Suggestions

• [.github/workflows/release.yml:55] gh release upload without --clobber
  If the upload job fails mid-way (e.g., ado-aw-linux-x64 uploads but .sha256 doesn't), re-running the workflow will fail with "asset already exists". Adding --clobber makes the step idempotent and safe to retry:

  gh release upload ${{ needs.release-please.outputs.tag_name }} \
    target/release/ado-aw-linux-x64 \
    target/release/ado-aw-linux-x64.sha256 \
    --clobber

• [tests/compiler_tests.rs:107-150] Tests check raw templates, not compiled output
  The new assertions (contains("{{ compiler_version }}"), contains("sha256sum --check")) verify the pre-compilation template content, not the final compiled YAML. There's no test confirming the compiled output doesn't contain the literal string {{ compiler_version }} as a leftover unreplaced marker. Consider adding a test that compiles a fixture through StandaloneCompiler and asserts !compiled.contains("{{ compiler_version }}").

✅ What Looks Good

• env!("CARGO_PKG_VERSION") is the right call — version is embedded at compile time with zero runtime injection risk, and the URL construction (v${COMPILER_VERSION}/ado-aw-linux-x64) correctly matches the v0.x.y tag format that release-please generates.
• SHA256 verification before execution is solid. The sha256sum --check approach (checking against the downloaded .sha256 file) is correct: the file format from sha256sum ado-aw-linux-x64 > ado-aw-linux-x64.sha256 is compatible with --check.
• All three download sites in 1es-base.yml and all three in base.yml are updated consistently — no leftover references to pipeline 2437.
• GitHub Actions steps are pinned to SHAs, not just tags. Good supply chain hygiene.
• github.com and *.githubusercontent.com (the redirect target for release asset downloads) are both in the AWF allowed domains list, so the curl download will work within the network-isolated agent environment.

Generated by Rust PR Reviewer for issue #14 · ◷

[github-actions]

🔍 Rust PR Review

Summary: Looks good — clean migration from ADO pipeline artifacts to GitHub Releases with SHA256 verification. One actionable concern worth fixing before merge.

Findings

⚠️ Suggestions

• templates/base.yml and templates/1es-base.yml — download steps missing set -e: The 6 new bash: download steps don't include set -euo pipefail. Azure Pipelines bash steps don't enable set -e by default — only the last command's exit code determines step success. If curl -fsSL on the binary download silently fails (e.g. transient network error before HTTP response), the script continues to sha256sum --check, which then fails with a confusing "no such file" error rather than a clear "download failed" message. The release workflow's own "Prepare release assets" step correctly uses set -euo pipefail — the template steps should match. This is particularly important because curl -f exits non-zero for HTTP errors (4xx/5xx) but silent partial reads or network drops won't be caught without set -e.

  Suggested fix for each download block:

  - bash: |
      set -euo pipefail
      COMPILER_VERSION="{{ compiler_version }}"
      ...

• templates/base.yml:175,332 — two DownloadPipelineArtifact@2 steps remain: These are correctly left for the AWF binary (pipeline: 2450), and the tests correctly only assert pipeline: 2437 is gone. Just confirming this is intentional and not a missed migration — it is, since AWF is a separate binary with a different distribution story.

✅ What Looks Good

• SHA256 verification pattern is solid: curl -fsSL + sha256sum --check in the same directory is the correct approach. The cd "$DOWNLOAD_DIR" before sha256sum ensures the relative filename in the .sha256 file resolves correctly.
• Compile-time version pinning via env!("CARGO_PKG_VERSION"): Baking the version into the binary at compile time is the right call — no runtime version drift, and the generated pipelines are always pinned to the exact compiler version that produced them.
• GitHub Actions pinned to commit SHAs: Both release-please-action and all other actions use full commit SHA pins rather than mutable tags.
• Test coverage: The new test_compiled_output_no_unreplaced_markers integration test is a valuable regression guard — it actually compiles a fixture and scans the output for leftover {{ }} markers. The ${{ exclusion logic (line.replace("${{", "")) is correct for distinguishing ADO pipeline expressions from template markers.
• release.yml structure: The two-job design (release-please → build) with if: ${{ needs.release-please.outputs.release_created }} is the canonical pattern — prevents spurious builds on every push to main.

Generated by Rust PR Reviewer for issue #14 · ◷