What are the next steps with this repo?

[mathieu-benoit]

We would like to capture here, roughly, the next steps that could be taken with this repo.

The idea is to capture a list of todo items that could be then scoped down as separate and individual issues that we could flag as help wanted/good first issue, etc.

First thing first, if you read this, could you please up-vote (👍) or down-vote (👎) on this issue description if you have interest (or not) seeing this implementation moving forward? The goal will be to see if there is any value/interest or not.

Top of mind here is what could be missing (but please add new comments about what you think could be missing on top of that):

• Governance on this repo to be compliant with other repo: main branch protected, etc.
• Release GHA (done here Catchup from other Score implementation repos in terms of CI/Release pipelines, Dependabot, Makefile, Dockerfile, etc. #28)
• score-aca --version (done here --version #32)
• Dockerfile (done here Catchup from other Score implementation repos in terms of CI/Release pipelines, Dependabot, Makefile, Dockerfile, etc. #28)
• First tutorial about how to use it as a .md file in this repo
• Documenting what's supported (or not) from the Score spec to ACA
  • Workload conversion versus Resources provisioning
• Release as a first official beta version (v0.0.1)?
  • What should be done before this?
• Add this new "implementation from the community", not yet official/GA here: https://docs.score.dev/docs/score-implementation/other-implementations/
• Announcement as a blog post
• Gathering feedback from users and community
• Later:
  • File issues as feature request to close the gaps about what could be missing
  • Call for contributions from the community
  • Add this repo to be listed in there https://clotributor.dev/search?foundation=cncf&project=score
  • Plan a rough roadmap based on the issues tracked above
  • Document what could be the graduation to official Score implementation supported
  • Release as first official GA version (v1.0.0)
  • Update official Score docs with this new implementation section in there: https://docs.score.dev/docs/score-implementation/

@giesan, could you please shed some lights here and share your thoughts here based on all the knowledge and experience you have with this implementation?

@astromechza @chris-stephenson @sujaya-sys, could you also share your thoughts on this please?

This is also a good exercise to document this process for future Score implementation that could be adopted from the community in the future.

[giesan]

I find the ongoing development of this repo very exciting, even though I am not currently using it myself.

It is important to involve the community in this process and take their opinions, needs, and ideas into account.

Overall, the list looks good and I agree with most points. Here are my thoughts on the individual items:

Governance for this repo to be consistent with other repos: protected main branch, etc.
Yes, we should do that.

Release workflow (GitHub Actions)
Good idea. We should align with the other repos.

score-aca --version
Sounds reasonable. We should introduce a version number.
It should follow the same format as the other repos.

Dockerfile
Yes, a Dockerfile would be useful to containerize the application.
Again, we should align with the other repos.

First tutorial on how to use it as a .md file in this repo
Good idea. A simple tutorial would help new users get started faster.

Document what is supported (or not) from the Score spec to ACA
Important to clarify what the implementation covers.

Release as a first beta version (v0.0.1)?
Before releasing, ensure the key features are stable and well documented.

Add this new “community implementation,” not yet official/GA, here: https://docs.score.dev/docs/score-implementation/other-implementations/
Yes, add it to increase visibility.

Announcement as a blog post
A blog post would be a great way to inform the community and gather feedback.

Gather feedback from users and the community
Actively solicit feedback to improve the implementation.

Create issues as feature requests to close identified gaps
Good idea to structure ongoing development.

Call for contributions from the community
Encourage community contributions.

List this repo here: https://clotributor.dev/search?foundation=cncf&project=score
This would also engage the community more. Sounds good.

Plan a rough roadmap based on the issues tracked above
A roadmap would help clearly define the next steps.

Document criteria for graduation to an official, supported Score implementation
Important to provide transparency.

Release as the first official GA version (v1.0.0)
Only do this when the implementation is stable and well documented.

[mathieu-benoit]

@giesan, great!

I think where you could help on a very short term is by starting this based on what you have implemented so far:

• Documenting what's supported (or not) from the Score spec to ACA (Workload conversion versus Resources provisioning)
• First tutorial about how to use it as a .md file in this repo

Could you help on these? I let you see what's the best way to share your content/knowledge around these, but maybe as .md in this repo? Or as comments in this issue? Or creating dedicated issues? Thanks in advance for your help, and again thanks for your contribution!

[giesan]

@mathieu-benoit I hope that helps.

Score Specification Feature Implementation for Azure Container Apps

⚠️ Warning

This document was generated with the help of AI and may contain inaccuracies. Please review carefully.
This overview can serve as a foundation for further development and feature prioritization, but does not replace thorough manual analysis.

Overview

The current implementation of the score-aca project implements a subset of the Score v1b1 Specification for Azure Container Apps.
The following describes the implementation status of individual Score features.

Feature Implementation Matrix

Score Feature	Implementation Status	Azure Container Apps Mapping	Comments
Core Structure
apiVersion	✅ Complete	Version validation	score.dev/v1b1 is validated
metadata	✅ Complete	Parameter generation	Name is used for Bicep parameters
metadata.name	✅ Complete	environmentName, containerAppName	Used as basis for resource names
metadata.annotations	⚠️ Partial	-	Read but not mapped to Bicep
Container
containers	✅ Complete	template.containers[]	Full support
containers[].image	✅ Complete	containers[].image	1:1 mapping
containers[].command	✅ Complete	containers[].command[]	Arrays are supported
containers[].args	✅ Complete	containers[].args[]	Arrays are supported
containers[].variables	✅ Complete	containers[].env[]	Environment variables
Container Resources
containers[].resources	✅ Complete	containers[].resources	CPU/Memory support
containers[].resources.limits	⚠️ Warning	-	Not supported - warning is issued
containers[].resources.requests	✅ Complete	containers[].resources	CPU (float64) and Memory (string)
containers[].resources.requests.cpu	✅ Complete	containers[].resources.cpu	Parsing "500m" → 0.5
containers[].resources.requests.memory	✅ Complete	containers[].resources.memory	Direct transfer (e.g., "1Gi")
Health Probes
containers[].livenessProbe	✅ Complete	containers[].probes[]	HTTP GET probes
containers[].readinessProbe	✅ Complete	containers[].probes[]	HTTP GET probes
containers[].livenessProbe.httpGet	✅ Complete	probes[].httpGet	Path, Port, Scheme, Host
containers[].readinessProbe.httpGet	✅ Complete	probes[].httpGet	Path, Port, Scheme, Host
containers[].livenessProbe.exec	❌ Not implemented	-	Only HTTP GET probes supported
containers[].readinessProbe.exec	❌ Not implemented	-	Only HTTP GET probes supported
Container Files & Volumes
containers[].files	✅ Processed	-	Not mapped to Bicep
containers[].files[].content	✅ Processed	-	Content is processed but not mounted
containers[].files[].source	✅ Processed	-	Files are read but not mapped
containers[].files[].noExpand	✅ Supported	-	Placeholder expansion is respected
containers[].volumes	❌ Not implemented	-	No volume support
Service & Networking
service	✅ Complete	configuration.ingress	Ingress configuration
service.ports	✅ Complete	configuration.ingress.targetPort	First port used for ingress
service.ports[].port	✅ Complete	configuration.ingress.targetPort	Public port
service.ports[].targetPort	✅ Complete	configuration.ingress.targetPort	Preferred over port
service.ports[].protocol	⚠️ Ignored	-	Not considered (HTTP/HTTPS)
Resources & Dependencies
resources	✅ Framework	-	Framework present, but no providers
resources[].type	✅ Framework	-	Type is processed
resources[].class	✅ Framework	-	Class is processed
resources[].id	✅ Framework	-	ID is processed
resources[].params	✅ Framework	-	Parameters are processed
resources[].metadata	✅ Framework	-	Metadata is supported

Detailed Implementation Notes

✅ Fully Implemented Features

1. Container Basic Configuration: Image, Command, Args, Environment Variables
2. Resource Requests: CPU and Memory requirements
3. HTTP Health Probes: Liveness and Readiness probes via HTTP
4. Service Ingress: External accessibility via ingress configuration
5. Metadata Processing: Name and annotations are processed

⚠️ Partially Implemented Features

1. Resource Limits: Recognized but not supported (warning is issued)
2. Protocol Specification: TCP/UDP not considered in ingress
3. Annotations: Read but not transferred to Bicep templates

❌ Not Implemented Features

1. Volume Mounts: No support for persistent volumes
2. File Mounts: Files are processed but not mounted in Container Apps
3. Exec Probes: Only HTTP GET probes, no command-based probes
4. Resource Provisioning: Framework present, but no Azure providers implemented
5. Multiple Ports: Only the first service port is used for ingress

Azure Container Apps Specific Limitations

1. Resource Limits: Azure Container Apps only supports Resource Requests, not Limits
2. Volume Support: Currently no implementation of Azure Files/Blob Storage mounts
3. Multiple Services: Only one ingress port per Container App
4. Exec Probes: Azure Container Apps only supports HTTP/HTTPS probes

Bicep Template Structure

The generated Bicep template contains:

// 1. Parameters for names and location
param environmentName string = 'workload-name-environment'
param containerAppName string = 'workload-name-container-app'
param location string = resourceGroup().location

// 2. Container App Environment (Managed Environment)
resource containerAppEnvironment 'Microsoft.App/managedEnvironments@2024-03-01'

// 3. Container App with Configuration and Template
resource containerApp 'Microsoft.App/containerApps@2024-03-01'

// 4. Output: FQDN of the Container App
output containerAppFQDN string = containerApp.properties.configuration.ingress.fqdn

Recommendations for Future Development

1. Volume Support: Implementation of Azure Files/Blob Storage mounts
2. Resource Provisioning: Azure-specific Resource Providers (Storage, Databases, etc.)
3. Multiple Ingress Ports: Support for multiple service ports
4. Advanced Networking: Traffic splitting, custom domains
5. Secrets Management: Integration with Azure Key Vault

Conclusion

The score-aca project implements a solid foundation of the Score v1b1 specification for Azure Container Apps with approximately 70% coverage of core features.

Main Strengths:

• Complete container configuration (Image, Command, Args, Env)
• HTTP Health Probes (Liveness/Readiness)
• Service Ingress with external accessibility
• Resource Requests (CPU/Memory)
• Clean Bicep template generation

Main Gaps:

• No volume/file mount support
• Missing resource providers for Azure services
• Only HTTP probes (no exec probes)
• Resource limits are not supported