{"meta":{"title":"Compilar y probar PowerShell","intro":"Aprende a crear un flujo de trabajo de integración continua (IC) para compilar y probar tu proyecto de PowerShell.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/es/enterprise-cloud@latest/actions/tutorials","title":"Tutoriales"},{"href":"/es/enterprise-cloud@latest/actions/tutorials/build-and-test-code","title":"Crea y prueba tu código"},{"href":"/es/enterprise-cloud@latest/actions/tutorials/build-and-test-code/powershell","title":"PowerShell"}],"documentType":"article"},"body":"# Compilar y probar PowerShell\n\nAprende a crear un flujo de trabajo de integración continua (IC) para compilar y probar tu proyecto de PowerShell.\n\n## Introducción\n\nEsta guía te muestra cómo utilizar PowerShell para la CI. Describe cómo usar Pester, instalar dependencias, probar el módulo y publicar en el PowerShell Gallery.\n\nLos ejecutores hospedados en GitHub tienen un caché de herramientas con software pre-instalado, lo cual incluye a PowerShell y a Pester.\n\nPara obtener una lista completa de software actualizado y las versiones preinstaladas de PowerShell y Pester, consulta [Ejecutores hospedados en GitHub](/es/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\n\n## Requisitos previos\n\nDeberías estar familiarizado con YAML y la sintaxis para las GitHub Actions. Para más información, consulta [Escritura de flujos de trabajo](/es/enterprise-cloud@latest/actions/learn-github-actions).\n\nTe recomendamos tener un entendimiento básico de PowerShell y de Pester. Para más información, consulte:\n\n* [Introducción a PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)\n* [Pester](https://pester.dev)\n\n## Agregar un flujo de trabajo para Pester\n\nPara automatizar tus pruebas con PowerShell y con Pester, puedes agregar un flujo de trabajo que se ejecute cada que se sube un cambio en tu repositorio. En el ejemplo siguiente, se usa `Test-Path` para comprobar que existe un archivo con el nombre `resultsfile.log`.\n\nEste archivo de flujo de trabajo de ejemplo se debe agregar al directorio `.github/workflows/` del repositorio:\n\n```yaml\nname: Test PowerShell on Ubuntu\non: push\n\njobs:\n  pester-test:\n    name: Pester test\n    runs-on: ubuntu-latest\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n      - name: Perform a Pester test from the command-line\n        shell: pwsh\n        run: Test-Path resultsfile.log | Should -Be $true\n      - name: Perform a Pester test from the Tests.ps1 file\n        shell: pwsh\n        run: |\n          Invoke-Pester Unit.Tests.ps1 -Passthru\n```\n\n* `shell: pwsh`: configura el trabajo para que use PowerShell al ejecutar los comandos `run`.\n\n* `run: Test-Path resultsfile.log`: comprueba si existe un archivo con el nombre `resultsfile.log` en el directorio raíz del repositorio.\n\n* `Should -Be $true`: usa Pester para definir un resultado esperado. Si el resultado es inesperado, entonces GitHub Actions lo marca como una prueba fallida. Por ejemplo:\n\n  ![Captura de pantalla de una falla en la ejecución del flujo de trabajo para una prueba de Pester. El informe de la prueba dice \"Se esperaba $true, pero se obtuvo $false\" y \"Error: Proceso finalizado con el código de salida 1\".](/assets/images/help/repository/actions-failed-pester-test-updated.png)\n\n* `Invoke-Pester Unit.Tests.ps1 -Passthru`: usa Pester para ejecutar pruebas definidas en un archivo denominado `Unit.Tests.ps1`. Por ejemplo, para realizar la misma prueba que se ha descrito antes, `Unit.Tests.ps1` contendrá lo siguiente:\n\n  ```powershell\n  Describe \"Check results file is present\" {\n      It \"Check results file is present\" {\n          Test-Path resultsfile.log | Should -Be $true\n      }\n  }\n  ```\n\n## Ubicaciones de los módulos de PowerShell\n\nEn la siguiente tabla se describen las ubicaciones para varios módulos de PowerShell en cada ejecutor hospedado en GitHub.\n\n<div class=\"ghd-tool rowheaders\">\n\n|                                           | Ubuntu                                           | macOS                                             | Windows                                               |\n| ----------------------------------------- | ------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------- |\n| **Módulos de sistema de PowerShell**      | `/opt/microsoft/powershell/7/Modules/*`          | `/usr/local/microsoft/powershell/7/Modules/*`     | `C:\\program files\\powershell\\7\\Modules\\*`             |\n| **Módulos de complementos de PowerShell** | `/usr/local/share/powershell/Modules/*`          | `/usr/local/share/powershell/Modules/*`           | `C:\\Modules\\*`                                        |\n| **Módulos instalados por el usuario**     | `/home/runner/.local/share/powershell/Modules/*` | `/Users/runner/.local/share/powershell/Modules/*` | `C:\\Users\\runneradmin\\Documents\\PowerShell\\Modules\\*` |\n\n</div>\n\n> \\[!NOTE]\n> En los ejecutores de Ubuntu, los módulos de Azure PowerShell se almacenan en `/usr/share/` en lugar de la ubicación predeterminada de los módulos de complemento de PowerShell (es decir, `/usr/local/share/powershell/Modules/`).\n\n## Instalación de dependencias\n\nLos ejecutores hospedados en GitHub tienen PowerShell 7 y Pester instalados. Puede usar `Install-Module` para instalar dependencias adicionales desde el PowerShell Gallery antes de compilar y probar el código.\n\n> \\[!NOTE]\n> Los paquetes preinstalados (Pester) que usan los ejecutores hospedados en GitHub se actualizan frecuentemente y pueden introducir cambios significativos. Como resultado, se recomienda especificar siempre las versiones de paquete necesarias mediante `Install-Module` con `-MaximumVersion`.\n\nTambién puede almacenar en caché sus dependencias para acelerar su flujo de trabajo. Para más información, consulta [Referencia de almacenamiento en caché de dependencias](/es/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\nPor ejemplo, el siguiente trabajo instala los módulos `SqlServer`y `PSScriptAnalyzer`:\n\n```yaml\njobs:\n  install-dependencies:\n    name: Install dependencies\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Install from PSGallery\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module SqlServer, PSScriptAnalyzer\n```\n\n> \\[!NOTE]\n> De forma predeterminada, PowerShell no confía en ningún repositorio. Al instalar módulos desde la galería de PowerShell, debe establecer explícitamente la política de instalación para `PSGallery` en `Trusted`.\n\n### Almacenar dependencias en caché\n\nPuedes almacenar dependencias de PowerShell en caché con una clave única, lo que te permite restaurar las dependencias para flujos de trabajo futuros con la acción [`cache`](https://github.com/marketplace/actions/cache). Para más información, consulta [Referencia de almacenamiento en caché de dependencias](/es/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\nPowerShell guarda sus dependencias en caché en ubicaciones diferentes, dependiendo del sistema operativo del ejecutor. Por ejemplo, la ubicación `path` usada en el siguiente ejemplo de Ubuntu será diferente para un sistema operativo Windows.\n\n```yaml\nsteps:\n  - uses: actions/checkout@v6\n  - name: Setup PowerShell module cache\n    id: cacher\n    uses: actions/cache@v4\n    with:\n      path: \"~/.local/share/powershell/Modules\"\n      key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer\n  - name: Install required PowerShell modules\n    if: steps.cacher.outputs.cache-hit != 'true'\n    shell: pwsh\n    run: |\n      Set-PSRepository PSGallery -InstallationPolicy Trusted\n      Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop\n```\n\n## Probar el código\n\nPuedes usar los mismos comandos que usas de forma local para construir y probar tu código.\n\n### Utilizar PSScriptAnalyzer para limpiar el código\n\nEn el ejemplo siguiente se instala `PSScriptAnalyzer` y se usa para el lint de todos los archivos `ps1` del repositorio. Para obtener más información, vea [PSScriptAnalyzer en GitHub](https://github.com/PowerShell/PSScriptAnalyzer).\n\n```yaml\n  lint-with-PSScriptAnalyzer:\n    name: Install and run PSScriptAnalyzer\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Install PSScriptAnalyzer module\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module PSScriptAnalyzer -ErrorAction Stop\n      - name: Lint with PSScriptAnalyzer\n        shell: pwsh\n        run: |\n          Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues\n          $errors   = $issues.Where({$_.Severity -eq 'Error'})\n          $warnings = $issues.Where({$_.Severity -eq 'Warning'})\n          if ($errors) {\n              Write-Error \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\" -ErrorAction Stop\n          } else {\n              Write-Output \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\"\n          }\n```\n\n## Empaquetar datos de flujo de trabajo como artefactos\n\nPuedes cargar artefactos para ver después de que se complete un flujo de trabajo. Por ejemplo, es posible que debas guardar los archivos de registro, los vaciados de memoria, los resultados de las pruebas o las capturas de pantalla. Para más información, consulta [Almacenamiento y uso compartido de datos con artefactos de flujo de trabajo](/es/enterprise-cloud@latest/actions/using-workflows/storing-workflow-data-as-artifacts).\n\nEn el ejemplo siguiente se muestra cómo puede usar la `upload-artifact` acción para archivar los resultados de la prueba recibidos de `Invoke-Pester`. Para más información, vea la [acción `upload-artifact`](https://github.com/actions/upload-artifact).\n\n```yaml\nname: Upload artifact from Ubuntu\n\non: [push]\n\njobs:\n  upload-pester-results:\n    name: Run Pester and upload results\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Test with Pester\n        shell: pwsh\n        run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml\n      - name: Upload test results\n        uses: actions/upload-artifact@v4\n        with:\n          name: ubuntu-Unit-Tests\n          path: Unit.Tests.xml\n    if: ${{ always() }}\n```\n\nLa función `always()` configura el trabajo para que el procesamiento continúe aunque se produzcan fallos en las pruebas. Para más información, consulta [Contextos de referencia](/es/enterprise-cloud@latest/actions/learn-github-actions/contexts#always).\n\n## Publicación en PowerShell Gallery\n\nPuede configurar el flujo de trabajo para publicar el módulo de PowerShell en el PowerShell Gallery cuando se superen las pruebas de CI. Puedes utilizar los secretos para almacenar cualquier token o credencial que se necesiten para publicar tu paquete. Para más información, consulta [Uso de secretos en Acciones de GitHub](/es/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions).\n\nEn el ejemplo siguiente se crea un paquete y se usa `Publish-Module` para publicarlo en el PowerShell Gallery:\n\n```yaml\nname: Publish PowerShell Module\n\non:\n  release:\n    types: [created]\n\njobs:\n  publish-to-gallery:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Build and publish\n        env:\n          NUGET_KEY: ${{ secrets.NUGET_KEY }}\n        shell: pwsh\n        run: |\n          ./build.ps1 -Path /tmp/samplemodule\n          Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose\n```"}