Nota: Actualmente los ejecutores hospedados en GitHub no se admiten en GitHub Enterprise Server. Puede ver más información sobre la compatibilidad futura planeada en GitHub public roadmap.
Introducción
Esta guía te muestra cómo construir, probar y publicar un paquete de .NET.
GitHub tienen una caché de herramientas con software preinstalado, que incluye el SDK de .NET Core. Para obtener una lista completa del software actualizado y las versiones preinstaladas del SDK de .NET Core, vea Software instalado en ejecutores hospedados en GitHub.
Requisitos previos
Ya debes estar familiarizado con la sintaxis de YAML y con cómo se utiliza con GitHub Actions. Para obtener más información, vea «Sintaxis del flujo de trabajo para Acciones de GitHub».
Te recomendamos que tengas un entendimiento básico de .NET Core SDK. Para más información, vea Introducción a .NET.
Utilizar el flujo de trabajo inicial de .NET
GitHub proporciona un flujo de trabajo inicial de .NET que debería funcionar para la mayoría de los proyectos de .NET y esta guía incluye ejemplos que te muestran cómo personalizarlo. Para más información, vea el flujo de trabajo de inicio de .NET.
Para comenzar rápidamente, agregue el flujo de trabajo de inicio al directorio .github/workflows del repositorio.
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.1.x', '6.0.x' ]
steps:
- uses: actions/checkout@v3
- name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Test
run: dotnet test --no-restore --verbosity normal
Especificar una versión de .NET
Para usar una versión preinstalada del SDK de .NET Core en un ejecutor hospedado en GitHub, use la acción setup-dotnet. Esta acción busca una versión específica de .NET en la caché de herramientas en cada ejecutor y agrega los binarios necesarios a PATH. Estos cambios persistirán para el recordatorio del job.
La acción setup-dotnet es la forma recomendada de usar .NET con GitHub Actions, ya que garantiza el comportamiento coherente entre los distintos ejecutores y versiones de .NET. Si va a usar un ejecutor autohospedado, debe instalar .NET y agregarlo a PATH. Para más información, vea la acción setup-dotnet.
Utilizar versiones múltiples de .NET
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.1.x', '6.0.x' ]
steps:
- uses: actions/checkout@v3
- name: Setup dotnet ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ matrix.dotnet-version }}
# You can test your matrix by printing the current dotnet version
- name: Display dotnet version
run: dotnet --version
Utilizar una versión específica de .NET
Puede configurar el trabajo para que utilice una versión específica de .NET, como 3.1.3. Como alternativa, puedes utilizar una sintaxis de versión semántica para obtener el último lanzamiento menor. Este ejemplo utiliza el lanzamiento menor más reciente de .NET 3.
- name: Setup .NET SDK
uses: actions/setup-dotnet@v3
with:
# Semantic version range syntax or exact version of a dotnet version
dotnet-version: '6.0.x'
Instalación de dependencias
Los ejecutores hospedados en GitHub cuentan con el administrador de paquetes NuGet ya instalado. Puedes utilizar el CLI de dotnet para instalar dependencias desde el registro de paquetes de NuGet antes de compilar y probar tu código. Por ejemplo, el código YAML siguiente instala el paquete Newtonsoft.
steps:
- uses: actions/checkout@v3
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
Almacenar dependencias en caché
Puede almacenar dependencias de NuGet en caché mediante una clave única, lo que le permite restaurar las dependencias para flujos de trabajo futuros con la acción cache. Por ejemplo, el código YAML siguiente instala el paquete Newtonsoft.
Para obtener más información, vea «Almacenar en caché las dependencias para agilizar los flujos de trabajo».
steps:
- uses: actions/checkout@v3
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- uses: actions/cache@v3
with:
path: ~/.nuget/packages
# Look to see if there is a cache hit for the corresponding requirements file
key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
restore-keys: |
${{ runner.os }}-nuget
- name: Install dependencies
run: dotnet add package Newtonsoft.Json --version 12.0.1
Nota: Según el número de dependencias, puede ser más rápido usar la caché de dependencias. Los proyectos con muchas dependencias de gran tamaño deberían ver un aumento del rendimiento, ya que reduce el tiempo necesario para la descarga. Los proyectos con menos dependencias podrían no ver un incremento significativo del rendimiento e incluso podrían ver un ligero decremento, debido a cómo NuGet instala las dependencias almacenadas en el caché. El rendimiento varía de un proyecto a otro.
Construir y probar tu código
Puedes usar los mismos comandos que usas de forma local para construir y probar tu código. En este ejemplo se muestra cómo usar dotnet build y dotnet test en un trabajo:
steps:
- uses: actions/checkout@v3
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x'
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build
- name: Test with the dotnet CLI
run: dotnet test
Empaquetar datos de flujo de trabajo como artefactos
Después de que se completa un flujo de trabajo, puedes cargar los artefactos que se den como resultado para su análisis. 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. En el ejemplo siguiente se muestra cómo puede usar la acción upload-artifact para cargar los resultados de la prueba.
Para obtener más información, vea «Almacenar los datos de los flujos de trabajo como artefactos».
name: dotnet package
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
dotnet-version: [ '3.1.x', '6.0.x' ]
steps:
- uses: actions/checkout@v3
- name: Setup dotnet
uses: actions/setup-dotnet@v3
with:
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Test with dotnet
run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
- name: Upload dotnet test results
uses: actions/upload-artifact@v3
with:
name: dotnet-results-${{ matrix.dotnet-version }}
path: TestResults-${{ matrix.dotnet-version }}
# Use always() to always run this step to publish test results when there are test failures
if: ${{ always() }}
Publicar en registros de paquetes
Puedes configurar tu flujo de trabajo para publicar tu paquete de .NET a un registro de paquetes cuando pasen tus pruebas de IC. Puedes utilizar secretos de los repositorios para almacenar cualquier token o credenciales que se necesiten para publicar tu binario. En el ejemplo siguiente se crea y publica un paquete en GitHub Packages mediante dotnet core cli.
name: Upload dotnet package
on:
release:
types: [created]
jobs:
deploy:
runs-on: ubuntu-latest
permissions:
packages: write
contents: read
steps:
- uses: actions/checkout@v3
- uses: actions/setup-dotnet@v3
with:
dotnet-version: '6.0.x' # SDK Version to use.
source-url: https://nuget.pkg.github.com/<owner>/index.json
env:
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
- run: dotnet build --configuration Release <my project>
- name: Create the package
run: dotnet pack --configuration Release <my project>
- name: Publish the package to GPR
run: dotnet nuget push <my project>/bin/Release/*.nupkg