En este post vamos a ver como subir nuestras librerías escritas en .NET a nuget directamente desde Github Actions.
Índice
1 - Qué son las GitHub actions?
Antes de entrar en materia debemos comprender y entender que son las github actions.
De una forma resumida podemos decir que las GitHub Actions son flujos de trabajo (workflow) que nos permiten tener continuous integration y continuos delivery así como test, desplegar código, etc directamente desde GitHub.
En mi caso me parece un gran avance, ya que yo personalmente nunca subía ningún proyecto a nuget, mas que nada por la pereza de crear el paquete, te logueas, etc. pero si se puede hacer automaticamente, por que no?
2 - Qué es nuget?
Llegados a este punto entiendo que todo el mundo sabe que es nuget. Nuget principalmente es el sistema de paquetes de .NET, es donde, todos los developers que crean librerías suben el contenido.
Lo podemos encontrar en visual studio cuando hacemos click derecho -> administrar paquetes nuget
.
3 - Cómo subir un paquete a nuget?
Para subir un paquete a nuget, primero de todo debemos crearnos una cuenta en www.nuget.org, ya que estos paquetes irán enlazados a nuestro usuario.
Una vez tenemos la cuenta, debemos tener en cuenta que para que este paquete se cree correctamente con toda la información necesaria, tal como nuestro nombre, licencia, repositorio, etc, vamos a tener que especificarla.
Para ello vamos a la librería que queremos convertir en un paquete y abrimos su .csproj.
Y dentro de la etiqueta <PropertyGroup>
donde tenemos el TargetFramework
le ampliamos la información como podemos ver a continuación:
<PropertyGroup>
<TargetFramework>netstandard2.1</TargetFramework>
<RootNamespace>Netmentor.DiContainer</RootNamespace>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<Nullable>enable</Nullable>
<Authors>Ivan Abad</Authors>
<Company>NetMentor</Company>
<Version>1.0.2</Version>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<RepositoryUrl>https://github.com/ElectNewt/Netmentor.DiContainer</RepositoryUrl>
<Description>Dependency container which allow to build modular applications</Description>
</PropertyGroup>
3.1 - Crear un paquete nuget desde línea de comandos
Ahora debemos crear el paquete, la primera vez que creamos un paquete lo debemos hacer de forma manual, esto es debido a que nuget “la primera subida” pide que sea de forma manual, para así poder cambiar la información que aparecerá asociada al paquete, o cancelar la subida si crees que es necesario.
Para ello, nos ubicamos con powershell en la ruta donde esta nuestro .csproj
y ejecutamos el siguiente comando
dotnet pack -c Release
Es importante indicar que hemos añadido -c Release
, esto es para que cuando creemos el paquete lo haga con la configuración de release, ya sabemos que cuando ejecutamos el modo debug por detrás el compilador crea informacion adicional (para poder debugear) pues con los paquetes lo mismo.
El paquete se nos crea en ~\bin\Release\
y únicamente debemos arrastrarlo al drag and drop de la ventan de uploads de nuget.
y vemos que nos pide verificar la información que hemos añadido en el .csproj anteriormente. hacemos scroll hasta abajo y enviamos (submit) .
Ahora como podemos observar el paquete ya está disponible en nuestra ventana de paquetes.
Nota: en este ejemplo no está explicado cómo actualizar la versión de nuestro paquete de forma automática, así que ese commit lo realizo manual (versión 1.0.2).
4 - Cómo subir un paquete a nuget con GitHub Actions
Hemos visto cómo subir el paquete manualmente, pero subir el paquete manualmente es una castaña, queremos automatizar el proceso.
Lo primero que tenemos que hacer es permitir a otras aplicaciones que se conecten en nuestro nombre a nuget. Para ello, nuget nos provee de una API key
, que la podemos encontrar en el menú superior (donde el nombre de usuario) haciendo click en API Key
.
Y creamos una o modificamos una existente, en mi caso tengo una para acceder desde GitHub, simplemente la actualizo para permitir el paquete nuevo.
Ahora debemos enlazar GitHub, para ello, vamos a nuestro repositorio y pulsamos en settings y desde settings en secrets
Ahí debemos añadir el código que nos ha dado la API Key de nuget, en mi caso la he llamado NUGET_API_KEY
pero puedes utilizar el nombre que quieras.
4.1 - Añadir el despliegue a Nuget a una GitHub Action
Ahora únicamente nos queda añadir la acción de publicar la librería en nuget, y para ello utilizaremos las github actions.
En este post no quiero extenderme sobre las github actions, pero cuando tienes un proyecto de .NET y pulsamos en “actions” aparece un workflow por defecto, eset workflow contiene build + test, y nos servirá como base para lo que queremos hacer.
Así que lo añadimos.
Como he indicado el workflow hace la build y posteriormente los test, lo que nos viene perfecto, porque así nos aseguramos que para desplegar en nuget los test tienen que pasar de forma satisfactoria.
Así que al final del documento vamos a añadir nuestro nuevo paso:
- name: Despliegue en nuget
uses: brandedoutcast/[email protected]
with:
PROJECT_FILE_PATH: src/Netmentor.DiContainer/Netmentor.DiContainer.csproj
TAG_FORMAT: '*'
NUGET_KEY: ${{secrets.NUGET_API_KEY}}
Aquí estamos indicando que utilice un paquete en concreto para publicar en nuget, asi como cierta información, como es la ruta de nuestro fichero .csproj
o la API key de nuget a través de los secrets.
Una vez guardamos, implica hacer un commit
, y con ello el workflow se ejecutará y lo veremos ejecutarse.
Como podemos observar, todos los apartados tienen un tick, con lo que quiere decir que todo ha funcionado como esperábamos, así que si vamos a nuget podemos ver la segunda versión.
Y finalmente si vamos a cualquier proyecto en visual studio y buscamos en nuget, también lo tendremos disponible.
Conclusión
- En este post hemos visto cómo crear y desplegar paquetes nuget directamente desde GitHub Actions.
- Personalmente pienso que es una gran mejora a GitHub ya que muchos developers van a empezar a poner sus proyectos open source en nuget de manera automática.
- FInalmente decir que a mí personalmente me ayuda mucho, ya que son paquetes que utilizo en múltiples proyectos y anteriormente los iba copiando y pegando, ahora los tengo siempre en la última versión.