microsoft / microsoft/aspire

aspire deploy ignores PublishAsScheduledAzureContainerAppJob and provisions a plain Container App instead of a Container App Job

Open
#17,581 1 comment 0 reactions 0 assignees View on GitHub
area-deployment triage:bot-seen
Dominant language
C#
Stars
6.3k
Forks
991
Avg merge
2d 15h
Merged PRs (30d)
196

Description

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

On a ProjectResource configured with PublishAsScheduledAzureContainerAppJob(...), aspire publish produces the correct artifact (Microsoft.App/jobs@2025-07-01 Bicep with triggerType: 'Schedule' and the cron expression I passed in), but aspire deploy routes the same resource through the plain Container App provisioning path. Its pipeline contains provision--containerapp and there is no equivalent …-containerappjob step anywhere in the tree, so a real deploy createsMicrosoft.App/containerApps/ instead of Microsoft.App/jobs/ — no cron, an idle replica running 24/7, and any tooling that looks for the resource at Microsoft.App/jobs/ (e.g. az containerapp job show) fails with "not found".

I hit this on aspire.cli 13.3.5 against Aspire.Hosting.Azure.AppContainers 13.3.5. A minimal public repro is here: https://github.com/keegan-caruso/aspire-scheduled-aca-job-repro

### Expected Behavior

aspire deploy honors PublishAsScheduledAzureContainerAppJob the same way aspire publish does, and provisions the resource as Microsoft.App/jobs/ with the configured cron schedule, parallelism, replica completion count, and replica timeout /retry limit. Concretely, I'd expect aspire deploy --list-steps to contain a provision--containerappjob step instead of provision--containerapp for resources that have PublishAsScheduledAzureContainerAppJob applied.

### Steps To Reproduce

Repro repo: https://github.com/keegan-caruso/aspire-scheduled-aca-job-repro

### Exceptions (if any)

_No response_

### Aspire doctor output

.NET SDK
✅ .NET 10.0.300 installed (x64)

Container Runtime
✅ Docker v29.5.2: running (auto-detected (default)) ← active

Environment
✅ WSL2 environment detected
Details:
If you experience container connectivity issues, ensure Docker Desktop WSL integration is enabled.
⚠️ HTTPS development certificate is only partially trusted
Set SSL_CERT_DIR in your shell profile: export SSL_CERT_DIR="$SSL_CERT_DIR:/home/linuxbrew/.linuxbrew/etc/openssl@3/certs:~/.aspnet/dev-certs/trust"
See: https://aka.ms/aspire-prerequisites#dev-certs
Details:
The certificate is in the trusted store, but SSL_CERT_DIR is not configured to include '~/.aspnet/dev-certs/trust'. Some applications may not trust the certificate. 'aspire run' will configure this automatically.

### Anything else?

_No response_

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.