Esta versión de GitHub Enterprise se discontinuó el 2021-09-23. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Compilar y probar PowerShell

Puedes crear un flujo de trabajo de integración continua (IC) para compilar y probar tu proyecto de PowerShell.

Nota: GitHub Actions estuvo disponible para GitHub Enterprise Server 2.22 como un beta limitado. El beta terminó. GitHub Actions está ahora disponible habitualmente en GitHub Enterprise Server 3.0 o superior. Para obtener más información, consulta la sección de notas de lanzamiento para GitHub Enterprise Server 3.0.


Nota: Los ejecutores hospedados en GitHub no son compatibles con GitHub Enterprise Server actualmente. Puedes encontrar más información sobre el soporte que se tiene planeado en el futuro en el Itinerario público de GitHub.

Introducción

Esta guía te muestra cómo utilizar PowerShell para la IC. Describimos cómo utilizar Pester, instalar dependencias, probar tu módulo y publicarlo en la galería de PowerShell.

Los ejecutores hospedados en GitHub tienen un caché de herramientas con software pre-instalado, lo cual incluye a PowerShell y a Pester.

Para encontrar una lista completa de software actualizado y de las versiones preinstaladas de PowerShell y Pester, consulta la sección "Especificaciones para los ejecutores hospedados en GitHub".

Prerrequisitos

Deberías estar familiarizado con YAML y la sintaxis para las GitHub Actions. Para obtener más información, consulta la sección "Aprende sobre GitHub Actions".

Te recomendamos tener un entendimiento básico de PowerShell y de Pester. Para obtener más información, consulta:

Utilizar ejecutores auto-hospedados en GitHub Enterprise Server

Cuando utilices acciones de configuración, (tales como actions/setup-LANGUAGE) en GitHub Enterprise Server con ejecutores auto-hospedados, tal vez necesites configurar el caché de las herramientas en los ejecutores que no tienen acceso a internet. Para obtener más información, consulta la sección " Configurar el caché de herramientas en ejecutores auto-hospedados sin acceso a internet".

Agregar un flujo de trabajo para Pester

Para 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 siguiente ejemplo, se utiliza Test-Path para verificar la presencia de un archivo que se llama resultsfile.log.

Este ejemplo de archivo de flujo de trabajo debe agregarse al directorio .github/workflows/ de tu repositorio:

name: Test PowerShell on Ubuntu
on: push

jobs:
  pester-test:
    name: Pester test
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository code
        uses: actions/checkout@v2
      - name: Perform a Pester test from the command-line
        shell: pwsh
        run: Test-Path resultsfile.log | Should -Be $true
      - name: Perform a Pester test from the Tests.ps1 file
        shell: pwsh
        run: |
          Invoke-Pester Unit.Tests.ps1 -Passthru
  • shell: pwsh - Configura el job para que utilice PowerShell cuando ejecutas los comandos de run.

  • run: Test-Path resultsfile.log - Revisa si un archivo que se llama resultsfile.log está presente en el directorio raíz del repositorio.

  • Should -Be $true - Utiliza Pester para definir un resultado esperado. Si el resultado es inesperado, entonces GitHub Actions lo marca como una prueba fallida. Por ejemplo:

    Prueba fallida de Pester

  • Invoke-Pester Unit.Tests.ps1 -Passthru - Utiliza Pester para ejecutar las pruebas que se definen en un archivo que se llama Unit.Tests.ps1. Por ejempo, para realizar la misma prueba que se describe anteriormente, el Unit.Tests.ps1 contendrá lo siguiente:
    Describe "Check results file is present" {
        It "Check results file is present" {
            Test-Path resultsfile.log | Should -Be $true
        }
    }
    

Ubicaciones de los módulos de PowerShell

En la siguiente tabla se describen las ubicaciones para varios módulos de PowerShell en cada ejecutor hospedado en GitHub.

UbuntumacOSWindows
Módulos de sistema de PowerShell/opt/microsoft/powershell/7/Modules/*/usr/local/microsoft/powershell/7/Modules/*C:\program files\powershell\7\Modules\*
Módulos complementarios de PowerShell/usr/local/share/powershell/Modules/*/usr/local/share/powershell/Modules/*C:\Modules\*
Módulos instalados por el usuario/home/runner/.local/share/powershell/Modules/*/Users/runner/.local/share/powershell/Modules/*C:\Users\runneradmin\Documents\PowerShell\Modules\*

Instalar dependencias

Los ejecutores hospedados en GitHub tienen PowerShell 7 y Pester instalados. Puedes utilizar Install-Module para instalar dependencias adicionales de la galería de PowerShell antes de compilar y probar tu código.

Note: Los paquetes pre-instalados (tales como Pester) que utilizan los ejecutores hospedados en GitHub se actualizan frecuentemente y pueden introducir cambios significativos. Como resultado, se recomienda que siempre especifiques las versiones de los paquetes requeridos utilizando Install-Module con -MaximumVersion.

Cuando utilizas ejecutores hospedados en GitHub, también puedes guardar las dependencias en el caché para acelerar tu flujo de trabajo. Para obtener más información, consulta la sección "Almacenar las dependencias en caché para agilizar los flujos de trabajo".

Por ejemplo, el siguiente job instala los módulos de SqlServer y PSScriptAnalyzer:

jobs:
  install-dependencies:
    name: Install dependencies
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install from PSGallery
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module SqlServer, PSScriptAnalyzer

Note: Predeterminadamente, PowerShell no confía en ningún repositorio. Cuando instales módulos desde la galería de PowerShell, debes configurar explícitamente la política de instalación de PSGallery en Trusted.

Almacenar dependencias en caché

Cuando utilizas ejecutores hospedados en GitHub, puedes guardar dependencias de PowerShell en el caché utilizando una clave única, lo cual te permite restaurar las dependencias para flujos de trabajo futuros con la acción cache. Para obtener más información, consulta la sección "Almacenar las dependencias en caché para agilizar los flujos de trabajo".

PowerShell guarda sus dependencias en caché en ubicaciones diferentes, dependiendo del sistema operativo del ejecutor. Por ejemplo, el path de la ubicación que se utiliza en el siguiente ejemplo de Ubuntu será diferente a aquél de un sistema operativo Windows.

steps:
  - uses: actions/checkout@v2
  - name: Setup PowerShell module cache
    id: cacher
    uses: actions/cache@v2
    with:
      path: "~/.local/share/powershell/Modules"
      key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer
  - name: Install required PowerShell modules
    if: steps.cacher.outputs.cache-hit != 'true'
    shell: pwsh
    run: |
      Set-PSRepository PSGallery -InstallationPolicy Trusted
      Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop

Probar tu código

Puedes usar los mismos comandos que usas de forma local para construir y probar tu código.

Utilizar PSScriptAnalyzer para limpiar el código

El siguiente ejemplo instala PSScriptAnalyzer y lo utiliza para limpiar todos los archivos ps1 en el repositorio. Para obtener más información, consulta PSScriptAnalyzer en GitHub.

  lint-with-PSScriptAnalyzer:
    name: Install and run PSScriptAnalyzer
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Lint with PSScriptAnalyzer
        shell: pwsh
        run: |
          Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues
          $errors   = $issues.Where({$_.Severity -eq 'Error'})
          $warnings = $issues.Where({$_.Severity -eq 'Warning'})
          if ($errors) {
              Write-Error "There were $($errors.Count) errors and $($warnings.Count) warnings total." -ErrorAction Stop
          } else {
              Write-Output "There were $($errors.Count) errors and $($warnings.Count) warnings total."
          }

Empaquetar datos de flujo de trabajo como artefactos

Puedes 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 obtener más información, consulta "Conservar datos de flujo de trabajo mediante artefactos".

El siguiente ejemplo ilustra cómo puedes utilizar la acción upload-artifact para archivar los resultados de las pruebas que se recibieron de Invoke-Pester. Para obtener más información, consulta la acción upload-artifact.

name: Upload artifact from Ubuntu

on: [push]

jobs:
  upload-pester-results:
    name: Run Pester and upload results
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Test with Pester
        shell: pwsh
        run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml
      - name: Upload test results
        uses: actions/upload-artifact@v2
        with:
          name: ubuntu-Unit-Tests
          path: Unit.Tests.xml
    if: ${{ always() }}

La función always() configura el job para seguir el procesamiento aún si existen fallos en las pruebas. Para obtener más información, consulta "always".

Puedes configurar tu flujo de trabajo para que publique tu módulo de PowerShell en la galería de PowerShell cuando pasen tus pruebas de IC. Puedes utilizar los secretos para almacenar cualquier token o credencial que se necesiten para publicar tu paquete. Para obtener más información, consulta "Crear y usar secretos cifrados."

El siguiente ejemplo crea un paquete y utiliza a Publish-Module para publicarlo en la galería de PowerShell:

name: Publish PowerShell Module

on:
  release:
    types: [created]

jobs:
  publish-to-gallery:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build and publish
        env:
          NUGET_KEY: ${{ secrets.NUGET_KEY }}
        shell: pwsh
        run: |
          ./build.ps1 -Path /tmp/samplemodule
          Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose