Repositorio de configuraciones y workflows compartidos de la organización APS.

Workflow reutilizable para repositorios .NET que:

• ejecuta restore, build y test en push y pull_request;
• publica paquetes NuGet en GitHub Packages en workflow_dispatch;
• soporta uno o varios paquetes mediante el input packages;
• resuelve dependencias internas entre paquetes del mismo repositorio;
• crea tags y GitHub Releases tras una publicación satisfactoria.

Referencia completa: README-nuget.md.

Workflow reutilizable para repositorios que despliegan Azure Functions (Isolated Worker v4, .NET 8+). Patrón build → upload artifact → deploy.

Qué hace:

• instala el SDK de .NET, hace restore (con soporte a feeds NuGet privados), build, test y publish;
• sube el artefacto compilado entre jobs;
• hace login en Azure vía OIDC (Workload Identity Federation) y despliega con Azure CLI mediante az functionapp deployment source config-zip.

Inputs principales:

Secrets requeridos (propagados con secrets: inherit): AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID, APS_NUGET_TOKEN.

Caller mínimo (.github/workflows/deploy.yml en el repo consumidor):

name: Deploy

on:
  workflow_dispatch:
    inputs:
      environment:
        required: true
        type: choice
        options: [dev, int, pro]

jobs:
  deploy:
    uses: APS-Framework/.github/.github/workflows/azure-functions-deploy.yml@main
    with:
      environment:        ${{ inputs.environment }}
      function_app_name:  ${{ vars.FUNCTION_APP_NAME }}
      project_path:       src/My.FunctionApp
    secrets: inherit

Workflow reutilizable para repositorios que despliegan una Azure Container App. Patrón build .NET → docker build & push a ACR → az containerapp update.

Qué hace:

• instala el SDK de .NET, hace restore (con soporte a feeds NuGet privados), build y test;
• calcula el tag de imagen (input o primeros 7 caracteres del SHA del commit);
• hace login en Azure vía OIDC y en el ACR con az acr login;
• construye la imagen Docker y la sube al ACR; APS_NUGET_TOKEN se inyecta como --build-arg para que el Dockerfile pueda restaurar paquetes NuGet privados durante el build (requiere ARG APS_NUGET_TOKEN en el Dockerfile);
• actualiza la revisión activa de la Container App con la nueva imagen.

Inputs principales:

Secrets requeridos (propagados con secrets: inherit): AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_SUBSCRIPTION_ID, APS_NUGET_TOKEN.

Variables de GitHub necesarias (repo o por entorno): ACR_NAME, CONTAINER_APP_NAME, RESOURCE_GROUP, CONTAINER_REPOSITORY.

Caller mínimo (.github/workflows/deploy.yml en el repo consumidor):

name: Container App CI/CD

on:
  workflow_dispatch:
    inputs:
      environment:
        required: true
        type: choice
        options: [dev, int, pro]

jobs:
  deploy:
    uses: APS-Framework/.github/.github/workflows/container-app-deploy.yml@main
    with:
      environment:          ${{ inputs.environment }}
      acr_name:             ${{ vars.ACR_NAME }}
      container_app_name:   ${{ vars.CONTAINER_APP_NAME }}
      resource_group:       ${{ vars.RESOURCE_GROUP }}
      container_repository: ${{ vars.CONTAINER_REPOSITORY }}
    secrets: inherit

Variables de ejemplo para el entorno dev del proyecto ResiberAI:

Workflow reutilizable para repositorios que mantienen documentación operativa en Markdown y necesitan sincronizarla con un vector store compartido. Este workflow:

• sincroniza ficheros .md seleccionados mediante un glob repo-relativo (file_filter);
• publica cada documento con un nombre canónico {docs_prefix}/{ruta/relativa}; si se define docs_root, recorta ese prefijo antes de construir el nombre;
• converge el vector store al estado del repositorio creando, actualizando y eliminando adjuntos;
• evita sincronizaciones accidentales de más de 200 ficheros salvo confirmación explícita;
• deja intactas las entradas no canónicas o no gestionadas por el repositorio caller.

Referencia completa: README-docs.md.

Script invocado por nuget-ci-publish.yml durante la fase de publicación. Se encarga de:

• descubrir proyectos publicables bajo src/;
• calcular versiones stable o rc por paquete;
• ordenar la publicación según dependencias internas (ProjectReference);
• transformar temporalmente dependencias internas a PackageReference;
• consultar GitHub Packages para resolver la última versión publicada cuando aplica;
• publicar paquetes, crear tags y generar GitHub Releases.

Cada repositorio caller invoca el workflow centralizado que necesite con un fichero mínimo en .github/workflows/.

• Para CI y publicación NuGet, consulta la sección 6. Configurar un nuevo repositorio SDK en README-nuget.md.
• Para despliegue de Azure Functions, consulta la sección .github/workflows/azure-functions-deploy.yml más arriba en este README.
• Para despliegue de Azure Container Apps, consulta la sección .github/workflows/container-app-deploy.yml más arriba en este README.
• Para sincronización de ops-docs al vector store, consulta la sección 8. Workflow reutilizable: Sync Vector Store Docs en README-docs.md.