feat(compute): add an Azure Virtual Machines adapter

[TheSaifZaman]

Extends the existing compute category to Azure.

No catalog row and no new CloudResource type — compute and 'instance'
already exist — so this is an adapter, a schema function and one registry line. It
does not touch the shared SPI surface, so it will not conflict with the other open
service PRs.

This corrects a recorded assumption about floci-az

Our notes said the Azure runtime answers 501 for everything beyond blob storage and
Cosmos. That holds for the legacy endpoints (/functions, /Tables) but not
for ARM — the Microsoft.Compute provider paths are real handlers.

I checked it was not a catch-all stub before building on it: a bogus provider 404s
with Unsupported Microsoft.Compute path: notAThing rather than returning an empty
list.

Verified against the runtime: create returns 201, delete returns 204 and the VM
is actually gone, instanceView reports a real PowerState, and
powerOff/start/restart genuinely move a VM between running, stopped and
deallocated.

Decisions that follow from probing

• Resources are addressed as resourceGroup/name. ARM cannot address a VM
  without its resource group and the generic route passes a single id. The id
  survives the route because HttpClient.ts:257 encodes path params.
• create verifies the resource group exists first. The runtime creates a VM in
  a nonexistent resource group and returns 201, while real Azure answers
  ResourceGroupNotFound — so the check has to live in the adapter or the console
  would create resources that could never exist against a real provider.
• The subscription is discovered, never presented. /subscriptions is read once
  to keep emitted resource ids honest, but the runtime returns the same resources
  for any subscription id — including totally-made-up. A subscription selector
  would therefore be fake data for exactly the reason the region selector was
  deferred, so none is offered.
• start/stop/reboot are implemented and work, but advertised as
  coming_soon with a reason. There is no generic resource actions route yet —
  only invoke and the object routes — so the console cannot call them. Advertising
  a control that cannot be reached would break the schema-is-a-promise contract that
  cloudProxy.test.ts exists to protect. They light up for free once the generic
  actions route lands.
• Power state is a per-VM instanceView fan-out, so a failure degrades the row
  with metadata.powerStateUnavailable rather than failing the whole list.
• The create form picks an image from a short list of known-good references rather
  than asking for all four imageReference fields; the map is shared with the
  schema so form and request cannot drift.

Verification

lint, type-check, test and build pass from the repo root. 16 adapter tests;
hermetic — the compute, capability-guard and catalog suites (100 tests) pass with
globalThis.fetch replaced by a throw.

End to end through the route: the Azure nav entry is now available, plus create,
list, inspect by encoded id, delete, the resource-group rejection returning 400, and
the schema reporting the three lifecycle verbs as coming_soon.

Also worth knowing

Resource group DELETE returns 200 and does nothing on this runtime, so resource
groups are deliberately not managed here — they have to pre-exist.

[greptile-apps]

Greptile Summary

Adds an Azure Virtual Machines compute adapter on the existing compute/instance surface.

• Registers AzureComputeAdapter and documents Azure compute as available in the README matrix.
• Implements list/get/create/delete plus lifecycle helpers; schema marks start/stop/reboot as coming_soon.
• Resolves resource groups case-insensitively and emits the runtime’s casing in paths and ids.
• Routes non-AWS compute create UI through DynamicFormRenderer instead of the EC2 launch form.

Confidence Score: 5/5

This PR appears safe to merge; the prior resource-group casing issue is fixed and no blocking failures remain.

resolveResourceGroup matches resource groups case-insensitively and returns the runtime spelling for paths and ids, with tests covering acceptance and casing; no remaining blocking failure was identified on the follow-up path.

Important Files Changed

Filename	Overview
packages/api/src/adapter-azure/AzureComputeAdapter.ts	Azure compute adapter with RG existence/case resolution, ARM CRUD, and degraded power-state enrichment.
packages/api/src/cloud-spi/computeSchema.ts	Azure VM schema, image/size/location constants, and coming_soon lifecycle capabilities.
packages/api/src/cloudProxy.ts	Registers AzureComputeAdapter in the cloud adapter registry.
packages/frontend/src/components/DynamicResourceView.tsx	Limits LaunchInstanceForm to AWS compute so Azure uses schema-driven create.
packages/api/src/adapter-azure/AzureComputeAdapter.test.ts	Hermetic coverage including case-insensitive RG accept and runtime spelling on PUT/id.

_{Reviews (4): Last reviewed commit: "fix(frontend): gate the EC2 launch form ..." | Re-trigger Greptile}

[greptile-apps]

Want your agent to iterate on Greptile's feedback? Try greploops.

[hectorvent]

Thank you for this one, the runtime probing behind it really shows: correcting the recorded assumption that floci-az is 501 beyond blob and Cosmos, checking that Microsoft.Compute is not a catch-all stub before building on it, and the resource group existence check with the runtime's casing are exactly the kind of grounding that makes an adapter trustworthy. The hermetic tests and the honest coming_soon on start/stop/reboot (instead of advertising controls the console cannot reach) fit the capability guard's intent perfectly.

One blocker, then this is ready:

Create in the console is still the EC2 form for Azure. DynamicResourceView renders LaunchInstanceForm whenever service === "compute", with no cloud check (the inline create branch). ComputePanel gates itself on cloud !== 'aws', but the create form does not, so on Azure the Create button opens the AWS launch form: an AMI ID field, EC2 dropdowns that query the legacy /api/ec2 routes, and a submit payload of imageId/instanceType that your adapter will correctly reject with "resourceGroup is required". Could you gate that branch to service === "compute" && cloud === "aws" so Azure falls through to DynamicFormRenderer? The schema you wrote is exactly what that renderer needs, so it should light up your image and size selects for free. The README line saying create works through the generic table would then be accurate too.

Two small notes, neither blocking:

• The cloudProxy.ts registration block and the README service matrix row are shared with your sibling adapter PRs, so expect small rebase conflicts there depending on merge order.
• stop mapping to powerOff rather than deallocate is the right call for a console stop button, and the doc comment saying so is appreciated.

Everything else checked out against the current pattern: no catalog row needed since compute and the instance type already exist, availability derives from the registration, the id encoding survives the route, and the per-VM instance view degrade keeps the list honest. Nice work.

[TheSaifZaman]

Rebased onto fd3bd2f after #147, #152 and #155 merged. This one rebased with no textual conflicts — its CONFLICTING state was GitHub's merge computation against the moved base rather than a real clash.

One thing the rebase surfaced that is worth flagging: this branch never updated the README capability table. service-matrix.ts generates | Compute | Compute | … | Yes (list, inspect, create, delete) | No | once the Azure VM adapter is registered, but the committed table still said No for Azure. Governing rule 3 makes README drift part of the definition of done for any change to visible navigation, so I regenerated it in a separate commit (6170111). Nothing else changed.

Gate green after the rebase: lint, type-check, 444 tests, build.

[TheSaifZaman]

@hectorvent Confirmed and fixed — thank you, this was a real hole and I had only exercised create through the API, never through the console.

Fixed: the inline create branch in DynamicResourceView is now gated to service === "compute" && cloud === "aws", so every other cloud falls through to DynamicFormRenderer as you suggested. I left a comment at the branch explaining why it is AWS-only — that it is an EC2 form querying the legacy /api/ec2 routes and submitting imageId/instanceType — so the next person does not helpfully re-generalise it.

The fallback does light up the adapter's own schema for free, as you expected. GET /api/clouds/azure/services/compute/schema returns:

name (text, required) · resourceGroup (text, required) · vmSize (select, required)
image (select, required) · location (select) · adminUsername (text)

Scope of what I verified: the gate, the build, and that the schema carries the right fields and select options. I have not driven the Azure create through the browser UI end to end, so if you want that confirmed before merge, say so and I will.

ComputePanel already self-gates on cloud !== 'aws', so nothing was needed there.

Also worth flagging from the rebase pass: this branch had never updated the README capability table — service-matrix.ts generates Yes for Azure Compute once the adapter is registered, but the committed table still said No. Regenerated in 6170111.

Gate green: lint, type-check, 444 tests, build.

[hectorvent]

Fixed, and thank you for the comment above the condition explaining why the EC2 form is AWS only. That will stop someone simplifying it back later.

I checked it both ways, since a gate like this can break the path it was protecting. On Azure the Create button now opens your schema-driven form: VM Name, Resource Group with the hint that it must already exist, and the VM Size and Image selects, with no AMI field anywhere. On AWS the EC2 launch form is untouched, still asking for AMI, instance type and key pair. Exactly as hoped, your schema lit up the selects for free once the form fell through to the generic renderer.

I also ran the adapter end to end: a missing resource group comes back as a typed 400 rather than a 500, an invalid image lists the four valid ones, and a real create returns a normalized VM whose compound id survives the round trip.

No blockers from my side.

[hectorvent]

🎉 This PR is included in version 0.3.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀