Weekly DevOps Roundup: Secretless CI, GitHub at Scale, Agent Ops

by TechHub

This week in DevOps, the theme is clear: reduce friction while tightening control across collaboration, CI/CD, and governance. GitHub CLI takes a step toward fully terminal-first workflows (including inline media), while enterprise teams get practical tooling for live GHES-to-cloud migrations, runner lifecycle planning, and more precise token permissions. Supply-chain hardening continues with npm OIDC improvements, CodeQL updates for pipeline security, and concrete guidance for trusting third-party Actions, and on the ops side, agents and Azure governance move closer to production patterns with clearer boundaries, auditable workflows, and more “as code” outputs.

This Week's Overview

GitHub CLI becomes a more complete terminal-first collaboration tool

GitHub CLI v2.99.0 added a repeatable --attach flag that lets you upload local images or videos and reference them inline in issue bodies, pull request descriptions, and comments, which pairs neatly with last week's GitHub auth hardening (refresh tokens and cleaner redirect setups) by making it easier to keep more of the collaboration loop in scripted, terminal-first flows without extra UI steps. This closes a long-standing gap for terminal-driven workflows where you could author Markdown quickly, but still had to switch to the web UI to include screenshots, screen recordings, or repro media.

The feature supports common GitHub authentication methods and keeps the rest of your Markdown intact, so you can treat media attachments like another part of a scripted or template-driven PR flow. GitHub is also emphasizing accessibility by allowing alt text alongside the file path, which matters if your team standardizes on CLI-driven PR templates and wants to keep reviews readable for everyone.

GitHub platform changes that affect enterprise operations

This week tied together several changes that matter if you run GitHub at scale: migrating GitHub Enterprise Server, tightening supply-chain posture, and integrating AI features into review and governance without losing auditability, extending the same “reduce friction without losing control” thread we started last week with more surgical token handling and incident response options.

Enterprise Live Migrations from GHES to GitHub Enterprise Cloud (GA)

Enterprise Live Migrations (ELM) reached general availability for near-zero-downtime moves from GitHub Enterprise Server (GHES) to GitHub Enterprise Cloud with Data Residency (ghe.com). The key operational win is continuous sync with a fast cutover, which reduces the long freeze windows that typically make large enterprise migrations painful, especially for monorepos and high-commit teams.

Management happens through the gh elm GitHub CLI extension, which drives migrations via the GHES REST API and fits better into scripted runbooks than one-off UI steps. If you already use GitHub Enterprise Importer (GEI), ELM becomes the option to evaluate when the business requirement is minimizing downtime rather than accepting longer maintenance windows.

GitHub Actions updates: runner timelines, Dependabot permissions, and reusable workflow visibility

GitHub Actions shipped an API for runner version deprecation timelines, which gives platform teams a clearer way to track when hosted runner images (or runner versions) approach end-of-support. That helps you turn “surprise breakage” into planned work by wiring the timeline data into internal dashboards or scheduled dependency reviews.

Actions also added a new vulnerability-alerts permission for GITHUB_TOKEN, allowing workflows to read Dependabot alerts without broadening permissions unnecessarily, continuing the shift toward tighter, more explicit token use we highlighted last week. Finally, extra job context properties make it easier to identify the source of reusable workflows, which is useful when you are tracing provenance in large orgs with shared pipeline libraries.

Privacy-safe star history via the REST API

GitHub introduced a REST API endpoint to retrieve repository star history as counts with timestamps, without exposing stargazer identities. This fills a practical analytics gap after stargazer listing endpoints were restricted to admins and collaborators, letting maintainers still chart adoption trends and correlate spikes with releases or blog posts.

For DevOps teams that generate weekly metrics, this shifts star trend reporting toward privacy-safe aggregation and away from identity-based scraping. It also makes it easier to keep dashboards compliant without needing elevated access to repo social data.

npm trusted publishing expands OIDC configurations and adds safer staged approvals

npm improved trusted publishing with GA support for multiple OIDC configurations per package, which is a practical upgrade for organizations that publish from more than one CI system or from multiple GitHub repositories. It reduces the pressure to funnel releases through a single pipeline just to satisfy identity constraints.

Staged approvals can now be blocked until malware scanning completes, and npmjs.com offers richer staged and version history for maintainers. If your release process depends on human approvals, this nudges you toward a more reliable “scan then approve” flow that is still compatible with OIDC-based, secretless publishing.

Copilot code review approvals (public preview) and budget controls (GA)

Copilot code review can now add an explicit approval assessment in its overview comment, and admins can optionally allow it to submit approvals that count toward required-approvals rules. Because this impacts merge gating, teams will want to decide where AI approvals are acceptable (for example, low-risk dependency bumps) and where they should remain advisory-only.

On the governance side, GitHub billing added expiration dates for individual user budget overrides via an expires_at field in the Budgets REST API, which fits the same “surgical controls” direction as last week's token-type-specific revocation by letting teams grant and automatically unwind time-boxed access without broad, disruptive resets. That is useful for time-boxed Copilot rollouts, incident-driven temporary access, or contractor onboarding where you want the system to revert users automatically to the default budget without manual follow-up.

Supply chain and pipeline trust: fewer secrets, stronger verification

This week had a clear theme: reduce long-lived credentials, make build and deployment provenance easier to verify, and give teams sharper tools for assessing what code actually runs in CI, reinforcing last week's focus on hardening authentication and improving incident response without increasing day-to-day friction.

GitHub CLI Linux signing key rotation (immediate action)

GitHub warned that the PGP signing key used for the gh Linux APT/RPM repositories expired on September 5, 2026. After that date, repository metadata and new RPMs will be signed only with the replacement key, and systems installed from the official repos before April 8, 2026 may need updated key setup.

For fleet owners, this is the kind of change that breaks unattended upgrades and golden image rebuilds if you do not update trust stores ahead of time. Treat it like any other package repository key rotation: verify the replacement key out of band, update your APT/RPM configuration, and confirm your CI images and developer workstations can still install and update gh.

A practical checklist for trusting third-party GitHub Actions

Jesse Houwing published a two-tier checklist for evaluating whether a third-party GitHub Action is safe to run, focusing on maintenance signals, dependency hygiene, release integrity, and governance. The guide is especially useful for teams standardizing intake rules for Actions Marketplace dependencies across dozens or hundreds of repositories.

It also compares SHA pinning, immutable releases, and GitHub's action lock files (including gh-actions-lock) as ways to ensure the code you reviewed is the code that executes. That is the operational heart of supply-chain hardening in Actions: you want reproducibility and auditability, not just “it looked fine when we skimmed it.”

CodeQL 2.26.4 improved security detections with changes that affect both code and pipelines: Go 1.27 support, more precise Rust data flow alert locations, and new taint models for Java/Kotlin and Python. It also updated GitHub Actions query behavior and improved C# query behavior, which can change what alerts appear in code scanning.

If you run CodeQL in CI, expect some alert churn as models and data-flow precision change. Plan for a short tuning window to review new findings, adjust baselines where appropriate, and validate that your security gates still match your team's risk tolerance.

Secretless CI/CD patterns on Azure and beyond

Microsoft's developer news recap called out CI/CD pipelines connecting to Azure Cosmos DB “without storing secrets,” alongside progress on agent security moving closer to production readiness. The practical takeaway is that more teams are expected to lean on identity-based authentication patterns (for example, federated credentials and short-lived tokens) rather than embedding database keys in pipeline variables.

This aligns with the broader shift you can see across tooling this week: OIDC for npm publishing, OIDC trust for generated deployment workflows, and more explicit token scopes in GitHub Actions. The common operational outcome is fewer static secrets to rotate and fewer places where credential leakage turns into a full environment compromise.

Agentic DevOps workflows: orchestration, grounding, and production readiness

Across GitHub Copilot, VS Code, and Azure, the new work is less about “chat in an IDE” and more about making agents fit real delivery workflows: multiple concurrent tasks, enforceable boundaries, and observable behavior, which builds on last week's theme that the token and identity model is part of the control plane you need for accountable automation.

Orchestrating Copilot cloud agents from GitHub Actions (and why it is constrained)

Jesse Houwing explained why GitHub Copilot cloud agent sessions cannot be created from GitHub Actions using GITHUB_TOKEN, tying the limitation to GitHub's accountability model (identity, billing, and auditability). In practice, this means you cannot treat Copilot cloud agents as a simple sub-job that any workflow can spawn without thinking about who pays and who is responsible for the output.

The post outlines workable orchestration patterns using gh-aw, including in-run sub-agents, gated multi-workflow flows, and PAT-backed cloud agent sessions when you truly need server-to-server initiation. For teams experimenting with agent-driven automation, this is a useful reality check: the token model is part of the control plane, not an inconvenience to “work around.”

Grounding agents in real source to reduce hallucinations

A separate guide focused on grounding Copilot agents in a local clone instead of letting them guess about dependency code. The approach is straightforward: add the dependency repository to the VS Code workspace, instruct the agent to cite file-and-line evidence, and use GitHub MCP (Model Context Protocol) to pull in issues and PR context as structured inputs.

This is a practical pattern for DevOps and platform teams because it scales better than ad-hoc prompt warnings. It turns “please be accurate” into a repeatable workflow rule (cite evidence), which is easier to review and safer to automate.

VS Code and Copilot updates: model choice, Agent Merge, and safer exclusions

GitHub Copilot's weekly release added new model options (Claude Fable 5.1 and Gemini 3.8 Flash) and expanded content-exclusion protections into Copilot app/CLI agentic workflows. On the IDE side, VS Code 1.136 highlighted Agent Merge and improved agent session handling, continuing the shift toward managing longer-running agent tasks as first-class development artifacts.

The broader VS Code 1.133-1.136 recap reinforced the same direction: Agent Plugins support, prompt UX improvements, chat search, and detailed per-turn usage tracking. For teams watching token spend and trying to standardize agent behavior across repos, usage metering and shared plugin standards start to look like operational necessities rather than “nice to have.”

Copilot app parallel agents using Git worktrees

The GitHub Copilot app now supports parallel agent sessions by isolating each one with its own Git worktree and preserving per-session context. The workflow example (feature work, accessibility review, and tests running concurrently) maps directly onto how developers already split tasks, but it removes the context collision that typically happens when you try to do this in one chat thread.

For teams, this is also a nudge toward worktree literacy: if agents and IDEs increasingly use worktrees under the hood, it becomes easier to adopt worktree-based patterns for human developers too (separate branches without stashing, faster context switching, and cleaner experimentation).

Azure SRE Agent and MCP tooling: connectors, ServiceNow routing, and production guardrails

Azure SRE Agent guidance continued to mature around “tools and control.” Azure Connector Namespace provides a managed way to host MCP servers and connect them to Azure SRE Agent, with an end-to-end example deploying an Azure SQL MCP server using azd and securing access via managed identity.

On the incident-management side, advanced ServiceNow response plans can now use more precise filters (assignment group scoping, custom u_ fields, AND-based matching) and include a preview flow so you can tune routing before enabling the plan. The same post also frames autonomy explicitly (Autonomous vs Review) and how the responder is selected (Meta Agent vs a custom agent), which is the kind of operational clarity you need before letting an agent touch production tickets.

Azure environment design, governance, and resiliency move toward “as code”

Azure guidance this week leaned heavily toward repeatability: define environments consistently, enforce compliance scope automatically, and treat resiliency posture as something you can assess and remediate with generated infrastructure code, echoing last week's emphasis on making controls auditable without blocking delivery.

Structuring Dev/UAT/Staging/Prod in Azure (subscriptions vs resource groups)

ChethanRaj's environment-structure guidance focused on the real trade-off most teams face: separate environments by resource group for simplicity, or by subscription for stronger isolation and clearer blast-radius boundaries. The posts emphasize production isolation, shared services placement, and how naming/tagging and CI/CD conventions influence whether your environment model stays maintainable as the org grows.

If you are designing landing zones or standard pipelines, this is a reminder to align the “where things live” decision (RG vs subscription) with identity boundaries, policy scope, and deployment mechanics like blue/green or staged rollouts. The wrong structure can lock you into awkward access patterns and brittle promotion pipelines later.

Designing RBAC and identity with least privilege (people, apps, pipelines)

A companion post tackled Azure RBAC design across humans, applications, and deployment pipelines, with a focus on least-privilege scoping and common mistakes. It calls out scenarios that often break in real systems: Key Vault access patterns, environment boundaries that leak privileges, and privileged access management through PIM (Privileged Identity Management).

The practical DevOps angle is that pipeline identity is not just an implementation detail. If you want safe promotions and clear audit trails, you need managed identities and correct scope assignment from the start, plus a plan for just-in-time elevation for operators instead of permanent “Owner” sprawl.

Compliance scope enforcement with Azure Policy (compliance as code)

One of the more actionable governance items showed a repeatable workflow to enforce compliance scope using Azure Policy. The approach extracts Microsoft's C5 service-scope tables from the Service Trust Portal, maps them to ARM resource types, then applies parameterized policies (deny/audit) with time-bound exemptions where necessary.

For teams managing regulated workloads, this is a strong pattern because it converts a documentation table into enforceable controls you can review in pull requests. It also acknowledges reality by including exemption management as part of the workflow rather than pretending everything is always “deny by default” with no operational escape hatch.

Resiliency Agent in Azure Copilot (public preview)

Azure Copilot introduced a Resiliency Agent built on Azure Infrastructure Resiliency Manager to assess zonal resiliency posture and prioritize remediation with cost-aware indicators. It can generate deployment-ready Bicep/Terraform and scripts, which makes it easier to turn an assessment into an actual backlog of changes you can apply and review.

For SRE and platform teams, the appeal is not the assessment itself but the handoff: if the agent outputs IaC artifacts, you can run them through the same PR review, policy checks, and staged deployment flow you already use. It also suggests Azure is formalizing “resiliency posture” as a service-group concern, not just a one-time architecture review.

GitOps-style tooling and operational visibility for Azure services

Two releases stood out for teams that want to manage platform configuration like application code: extract it, review it, promote it, and troubleshoot it with better introspection, which complements the governance-through-auditability direction we have been tracking in GitHub.

APIOps CLI for Azure API Management

APIOps CLI is a new open-source tool that extracts and publishes Azure API Management configuration as source-controlled artifacts. The goal is a pull-request-driven workflow where API definitions, policies, and configuration changes can be reviewed and then promoted across environments using GitHub Actions or Azure DevOps pipelines.

For DevOps teams supporting multiple APIM instances, this helps reduce drift and makes promotions repeatable, especially when paired with environment structure and RBAC guidance. It also makes APIM changes easier to audit because the “what changed” story lives in Git history.

Logic App Storage Inspector for Logic Apps Standard

Logic App Storage Inspector is a read-only Kudu site extension for Azure Logic Apps Standard that helps inspect workflow history, workflow versions, and underlying storage/queue health. The post includes installation via Kudu and configuration options for storage access, including managed identity.

This is the kind of tool that matters when your incident runbooks involve verifying whether a Logic App is stuck due to storage issues or message backlog rather than logic errors. Because it is read-only, it also fits better into restricted operational environments where you want visibility without giving every operator broad write privileges.

Testing and developer workflow improvements that impact delivery pipelines

MSTest 4.4 adds Native AOT test execution via source generation

MSTest 4.4 added support for publishing and running test projects as Native AOT executables using source generation. The key DevOps benefit is you can run tests under the same trimming and reflection constraints as production Native AOT deployments, which helps catch issues that only appear after trimming removes unused code paths.

The post walks through configuration plus publish/run commands, and it also flags migration limits when moving from VSTest to the Microsoft Testing Platform. If your organization is adopting Native AOT for services or CLI tools, this makes “test what you ship” more literal by aligning runtime characteristics between CI tests and production artifacts.

Other DevOps News

GitHub and Visual Studio kept iterating on day-to-day review ergonomics: reviewing PRs inside Visual Studio, adding PR context into Copilot Chat, and reducing context-switching when juggling multiple tasks, which matches the same productivity-with-guardrails arc as last week's GitHub auth and incident-response hardening. Visual Studio 2026's Git worktrees support and scoped per-solution settings (stored in settings.VisualStudio.json and optionally committed) both push teams toward more repeatable, less error-prone local setup when multiple solutions are open at once.

Microsoft Fabric also published more CI/CD learning content, plus guidance on dbt job patterns (preview) across Lakehouse and Warehouse medallion designs. If you run data pipelines alongside app pipelines, these resources help standardize how infra (Terraform), deployment tooling (Fabric CLI / fabric-cicd), and orchestration (Azure DevOps pipelines or Fabric pipelines) fit together.

Finally, Microsoft's Physical Security Engineering Team shared a concrete hybrid-ops scaling story using Azure Arc and Azure Virtual Desktop, standardizing patching, governance, and observability with Azure Policy, Azure Monitor, and Log Analytics. Case studies like this are useful when you need to justify investments in consistent governance and telemetry across a messy hybrid estate.