Consider how we might offer resource code as an ARM resource

Summary of the new feature / enhancement

The intention would be for DSC resources to be published as an ARM resource. The motivation for such as solution would be to eliminate the machine configuration dependency on external artifacts, by modeling resources in ARM and writing them as a control-plane API.

This might be workable, based on Run Command resources. In that model, the script reference can either be in-line code or an external file.
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/run-command-managed#rest-api

Proposed technical implementation details (optional)

For very simple one-liners we could consider passing in the command syntax with the parameter input. This probably would be most useful in audit scenarios. Set scripts are more often complicated but Get scripts can sometimes be quite short.

If we followed the Run Command schema, this is what the json might look like.

{
  "source": {
    "get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"
  },
  "parameters": {
    "Status": "Running",
    "Name": "bits"
  }
}

So an end-to-end automation command would look something like this.

{"source": {"get": "$service = get-service -name $env:Name; @{Name = $service.Name; Status = $service.status}"},"parameters": {"Status": "Running","Name": "bits"}} | dsc resource

This would require the machine configuration service team to create a new resource type under Microsoft.GuestConfiguration. Then a configuration in JSON format in ARM could reference the script code as a dependency.

Comienza revisando el modelo de Azure Run Command REST API enlazado y la dependencia entre el servicio de configuración de máquinas y el tipo de recurso descrita en el issue. No se nombran archivos del repositorio ni pruebas; habría que acordar criterios de finalización para un esquema de recursos ARM, el manejo de scripts en línea y un flujo de recursos dsc de extremo a extremo.