Azure / Azure/azure-functions-host
[Compute Separation][PR-M10+HB4A] Publish the dedicated compute Host artifact
- Dominant language
- C#
- Stars
- 2k
- Forks
- 482
- Avg merge
- 2d 12h
- Merged PRs (30d)
- 38
Description
## Roadmap mapping
| Field | Value |
|---|---|
| Roadmap IDs | PR roadmap milestone 10 + `HB4A` |
| Lane | Host product artifact / image handoff |
| BYOC milestone | M1 |
| Parent | #11965 |
| Depends on | `HT8b` |
| Blocks | BYOC image build and [internal BYOC #219](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/219) |
| Pull request | One PR |
## Why this PR exists
HT7 creates the Linux `Azure.Functions.Host` executable shell and static Client-composition entrypoint. HT8a/HT8b populate the Client graph and prove its lifecycle in tests. The beta stamp still needs an immutable, deployable compute Host artifact and a versioned image-input contract.
This PR turns the existing executable into a published, isolated, runnable artifact. It does not create or rename the executable, composition, or `Program`.
## Source material
- Incremental roadmap milestone 10, compute executable artifact.
- `ga-plan.md`: standard/Client/WorkerProxy output isolation.
- Roadmap HB4A and integration gates.
- `platform-control-apis.md`, runtime pod composition.
- HT7 Linux executable shell and HT8a/HT8b runtime behavior.
- WorkerProxy executable/Dockerfile precedent and [internal BYOC #219](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/219).
## Current state
HT7 provides the Linux-only `Azure.Functions.Host` project, executable entrypoint, `ClientWorkerComposition` selection, solution wiring, and placeholder build/publish checks. HT8a/HT8b make that composition runnable in tests.
No official compute artifact, publish profile, CI publication, image-input contract, dependency/output isolation gate, or process/container smoke exists.
## Proposed implementation
1. Keep the existing `Azure.Functions.Host` project, executable name, `Program`, and Client composition; do not add another executable root.
2. Fail before accepting traffic when required platform environment settings are absent, with a clear non-zero exit where appropriate.
3. Add official CI and a Linux compute publish profile/artifact.
4. Add real publish-output and `.deps.json` tests:
- compute contains Rpc.Client, shared Grpc/Script/Core, and the Client product;
- compute excludes Rpc.Server local-process implementation, standard WebHost, bundled local workers, and WorkerProxy;
- standard excludes Rpc.Client, Azure.Functions.Host, and WorkerProxy.
5. Remove any HT7-only interim publish filtering once the Host references the final Hostable/Core layer directly.
6. Add a container input layout and reviewed handoff document: publish directory, entrypoint, exact HT8b environment names/defaults/errors, M1 config opt-in, explicit secret-storage setting, ports, base/runtime requirements, and artifact SHA/digest identification.
7. Add process/container smoke: start with zero workers, remain alive but non-routable, report health, and shut down cleanly.
### Ownership and lifecycle
Host owns artifact and input contract. Image owners own production image assembly, promotion, ACR, and pools. The existing `Program` owns only static composition selection; this PR does not re-express service ownership from HT8.
## Tests and evidence
- compute/standard publish file and deps inclusion/exclusion assertions;
- startup idle/non-routable and clean shutdown;
- missing required setting fails before traffic acceptance;
- reference direction: no Rpc.Server/standard WebHost in compute and no standard reference to Client product;
- solution/analyzer and CI artifact publication;
- attach both file lists, empty standard deps diff, and resulting artifact identifier for [internal BYOC #219](https://github.com/serverless-paas-balam/FlexConsumption-BYOC/issues/219);
- HT14 evidence.
## Explicit exclusions
- no new executable project, executable name, `Program`, or placeholder composition;
- no ACR/pool/promotion pipeline or production image hardening;
- no placeholder pools;
- no auth/certificates;
- no WorkerProxy sidecar packaging into this artifact;
- no customer host.json/app mount/code download;
- no link/capacity endpoints;
- no standard publish behavior change;
- no runtime topology flag;
- no Aspire automation or post-M1 scope.
## Acceptance criteria
- the existing `Azure.Functions.Host` publishes through official CI as an isolated Linux artifact;
- compute publish starts with the documented command and has exact output isolation;
- standard publish/deps is unchanged;
- idle process remains healthy/non-routable and shuts down;
- missing platform configuration fails clearly before traffic acceptance;
- image owner accepts the versioned layout/environment/port/artifact contract;
- CI publishes an immutable artifact identifier.
## PR stop condition
Stop when the existing dedicated executable publishes an isolated asserted artifact, starts/stops cleanly with no worker, and the image-input contract is reviewed. HT9, capacity publication, production image promotion, and stamp execution remain separate.
Contributor guide
Assessment
This issue has not been assessed yet.