feat(web): add AppService 2025-05-01 for FlexConsumption function apps

[andreidorin-oprea]

What

Add AppService 2025-05-01 to the web group so FlexConsumption function apps can be expressed.
The web group is currently pinned at 2022-03-01, which predates FlexConsumption — there is no way
to set Site.Properties.functionAppConfig (deployment storage + runtime + scale/concurrency).
2025-05-01 is the latest stable AppService API version in the pinned specs and models
functionAppConfig.

Depends on #5504 (generator receiver / import-alias fix). That fix is required for the
generated web code to compile: the new FunctionsDeploymentStorage type would otherwise yield a
method receiver named storage, shadowing the storage conversion-package import when the
conversion body constructs storage.FunctionsDeploymentStorageAuthentication. #5504 appears as the
first two commits in this branch and drops out of the diff once it merges. Please do not merge
before #5504.

Change

azure-arm/web.yaml: add a 2025-05-01 block (coexisting with 2022-03-01), exporting Site /
ServerFarm / SitesSourcecontrol at $supportedFrom: v2.21.0, and labelling the ARM-ID
properties the generator flags for this version:

• SiteProperties.ServerFarmId, SiteProperties.VirtualNetworkSubnetId,
  SiteProperties.ManagedEnvironmentId
• ServerFarmNetworkSettings.VirtualNetworkSubnetId
• DefaultIdentity.UserAssignedIdentityResourceId
• FunctionsDeploymentStorageAuthentication.UserAssignedIdentityResourceId

2025-05-01 uses the consolidated TypeSpec-generated openapi.json, so its model names differ from
the older split-swagger versions (e.g. SiteProperties rather than Site_Properties_Spec).

The regenerated Site_Spec.FunctionAppConfig exposes Deployment.Storage{Authentication,Type,Value}
/ Runtime{Name,Version} / ScaleAndConcurrency{AlwaysReady,InstanceMemoryMB,MaximumInstanceCount, Triggers}.

How generated

Regenerated with the canonical task controller:generate-crds pipeline against the pinned
azure-rest-api-specs submodule (controller-gen v0.19.0, gofumpt v0.10.0). The run is idempotent —
re-running produces no diff, and verify-no-changes is green. Adding the newest version repoints the
existing 2022-03-01 storage conversions to the new 2025-05-01 hub, so those files change (as expected
for a version addition — they are not, and should not be, byte-identical).

Tests (local)

• go build ./api/web/..., go vet ./internal/controllers/ → ok
• go test ./api/web/... (incl. v20250501 + arm + storage conversion round-trips) → ok
• check_samples.py → ok (samples present for the new version)
• No intended 2022-03-01 API-surface change; its generated storage conversions are regenerated as
  expected because the conversion hub moves to 2025-05-01.

Samples

Added samples/web/v20250501/{serverfarm,site,sitessourcecontrol}.yaml, mirroring the existing
2022-03-01 samples.

Remaining work (needs Azure)

I don't have an Azure subscription to record against, so the following still need to be captured by
someone with cloud access:

• The sample recording Test_Web_v20250501_CreationAndDeletion.yaml (the samples suite
  auto-discovers the new folder and needs it in replay).
• A CRUD test + recording in internal/controllers. I've included compiling skeletons
  (web_serverfarm_crud_v20250501_test.go, web_site_crud_v20250501_test.go, copied from the
  2022-03-01 tests with versions bumped) as a starting point; they need their recordings captured
  against Azure.

Happy for a maintainer to record these, or to guide me if there's a way to run them against a test
subscription.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[andreidorin-oprea]

@microsoft-github-policy-service agree

[theunrepentantgeek]

Looks like a little work is needed before we can approve the workflows and do a proper review.

Generated files were produced by a local, web-scoped generator run (verified to reproduce the committed web types byte-identical).

I'm not sure what this means. Skimming the generated types under v2/api/web, the changes to existing files look correct for the addition of the new version - those files are not byte-identical, and shouldn't be.

No resource sample / envtest recording added yet — happy to add.

Our CI both enforces the presence of samples, and runs a test cycle (using a recording) to ensure they work. We've got some docs on this (see Create a sample) but will be happy to answer any questions you have. Oh, and the /testing-aso-recordings skill may be useful too.

We'll also need to add a CRUD test to the internal/controllers test suite and record its use. Copying the existing one and bumping the imported resource versions would be a good place to start. See Write a test for the resource.

Maintainers may prefer a newer AppService version (2024-11-01 / 2025-05-01 are also published) —
2024-04-01 is the minimum that has functionAppConfig.

Pulling a later stable release would be preferable, yes.

One final note - given we just released ASO v2.20, you'll need to tweak $supportedFrom to v2.21.

Thanks for the contribution, very much appreciated.

[theunrepentantgeek]

CI was failing because the generated index files for the documentation were out of date - as soon as you added samples, our code generator started linking to them from the index files.

I took the liberty of updating those files and pushing the change to your branch, hope that's ok.