ci: remove Azure Artifacts publishing

[akshaylive]

Summary

Removes the private UiPath Azure Artifacts (coder_eval) feed as a publish target.

• Deleted .github/workflows/publish-dev.yml — its sole purpose was building per-PR dev wheels and uploading them to the Azure feed (via the build:dev label). Nothing else referenced it.
• .github/workflows/release.yml — removed the Publish to coder_eval feed twine step and updated the stale Azure references in the header/job comments.

Public PyPI publishing (OIDC Trusted Publishing), the GHCR agent image, and the v<version> git tag are untouched. pr-checks.yml's use of the Azure feed as a dependency index (install source, not publish target) is intentionally left in place.

🤖 Generated with Claude Code

[github-actions]

Claude finished @akshaylive's task in 1m 24s —— View job

---

Code Review In Progress

Review Checklist:

• Read review guidelines from .github/code_review.md
• Read project conventions from CLAUDE.md
• Examine the full PR diff
• Review deleted file: .github/workflows/publish-dev.yml
• Review changes to: .github/workflows/release.yml
• Check cross-file consistency
• Analyze what might be missing
• Provide comprehensive review feedback

Starting review now...

[uipreliga]

Review: coder_eval — pr:11

Scope: pr:11 · branch pr-11 (akshaya/remove_azure_publish) · 2082dcc · 2026-07-09T22:31Z · workflow variant

Change class: simple — removes the Azure Artifacts publish step from release.yml and deletes publish-dev.yml; no job dependencies or control flow affected, the PyPI + GHCR release path is unchanged.

coder_eval is in excellent health — all eight axes score 9.9–10 with zero critical/high/medium findings and no defect that can change a task's score or final_status for identical agent output — so the only real risk is documentation drift (one stale CI comment), and the bottom line is that the codebase is ship-ready with cosmetic cleanup only.

Summary

Axis	Score	🔴	🟠	🟡	🔵	Top Issue
1. Code Quality & Style	9.9 / 10	0	0	0	1	Stale comment: runner-choice justification still lists twine, but the PR removed the only twine step
2. Type Safety	10 / 10	0	0	0	0	—
3. Test Health	10 / 10	0	0	0	0	—
4. Security	10 / 10	0	0	0	0	—
5. Architecture & Design	10 / 10	0	0	0	0	—
6. Error Handling & Resilience	10 / 10	0	0	0	0	—
7. API Surface & Maintainability	10 / 10	0	0	0	0	—
8. Evaluation Harness Quality	10 / 10	0	0	0	0	—

Overall Score: 10 / 10 · Weakest Axis: Code Quality & Style at 9.9 / 10
Totals: 🔴 0 · 🟠 0 · 🟡 0 · 🔵 1 across 8 axes.

Blockers

None.

Non-blocking, but please consider before merge

None.

Nits

1. [Axis 1] Stale comment: runner-choice justification still lists twine, but the PR removed the only twine step (.github/workflows/release.yml:35) — Line 35 reads # \uipath-ubuntu-latest` pool. uv, twine, and the docker buildx -> GHCR— it justifies the GitHub-hostedruns-on: ubuntu-latestchoice by listing the tools that "run fine here." This PR deleted the only twine invocation in the workflow (the removedPublish to coder_eval feedstep, which ranuv tool run --from twine twine upload ...). The retained PyPI publish now uses the pypa/gh-action-pypi-publishaction (line 162), anduv build(line 82) builds — notwineis invoked anywhere in the final file (grep confirms line 35 is the soletwineoccurrence). The removal thus left a half-removed reference: droptwinefrom the comment so it matches the code (e.g.# uv and the docker buildx -> GHCR push all run fine here.`). Cosmetic only; no effect on execution.

What's Missing

Daily/nightly:

• 🟠 Unstated daily/nightly blast radius: the release job's Azure coder_eval feed publish (release.yml) and the per-PR dev-wheel publish (publish-dev.yml) were the private UiPath distribution channel, but the nightly/eval-runner pipeline lives in the separate coder-eval-uipath repo and this PR does not state whether that pipeline installs coder-eval from the Azure feed. If it does, released versions now land only on public PyPI and the nightly's internal index goes stale, breaking it under version skew — the cross-repo contract change is unaddressed. (trigger: .github/workflows/release.yml)

Downstream consumers:

• 🟡 No migration note for consumers pinned to the Azure feed: any UiPath-internal consumer with uv/pip index config pointing at pkgs.dev.azure.com/uipath/ML%20Platform/_packaging/coder_eval/pypi/simple/ stops resolving new releases, and deleting publish-dev.yml removes the build:dev per-PR dev-wheel channel authors used to hand an installable pre-release wheel to downstream repos for integration smoke-tests. Public PyPI (and the TestPyPI dry-run job) are viable alternatives, but the PR points no consumer at them. (trigger: .github/workflows/publish-dev.yml)

Harness & Lint Improvements

Nothing identified.

Top 5 Priority Actions

1. No scoring/final_status-affecting defects were found, so no fix is required to protect determinism — the harness produces identical scores for identical agent output.
2. Fix the stale runner-choice comment at .github/workflows/release.yml:35 by dropping the now-removed twine reference (the PR deleted the only twine step; publishing now goes through pypa/gh-action-pypi-publish at line 162 and uv build at line 82).
3. Add a lightweight CI/lint guard that flags references to removed tools in workflow comments so half-removed mentions like this twine reference are caught mechanically rather than in review, per CLAUDE.md's 'could a lint rule have prevented this?' guidance.
4. Sweep the remaining GitHub workflow comments once for other post-refactor drift (tool names, step names, pool justifications) while release.yml is already open, since this class of staleness is cosmetic but recurs after CI restructures.
5. Keep the current bar in place — treat the 10/10 result as a baseline and re-run the 8-axis review on the next substantive change rather than adding speculative hardening, consistent with the project's YAGNI/KISS principles.

---

Stats: 0 🔴 · 0 🟠 · 0 🟡 · 1 🔵 across 8 axes reviewed.