Publishing an artifact on Github Actions of a .Net 6 + Blazor applications

Hey folks,

In this article, I would like to show how simple is to create and publish a build artifact of a .Net 6 application.

The reason to publish this artifact is that this is the “file” that will be released on the app service server and will be our new version published.

If you came directly to this article, I’d suggest you pause here and go to the previous article (link below) where I created a .Net 6 application and configured a Github Action to run the build and unit tests just to make sure my application is ready to be published. This is a continuation of that project and would be easier if you follow the correct sequence:

Configuring Github Actions for .Net 6 + Blazor applications

Great, now we are all aligned with this project let’s open the file .github/workflows/dotnet.yml to analyze what’s is the current tasks there.

Ok! So at the moment we have the tasks only to: Restore the Nuget Packages, Build our application to confirm the code is OK and Run Unit Tests to make sure the changes didn’t break anything.

Basically, what we need to do next are 2 steps: Execute a dotnet publish to generate the files ready to be released and execute the command to zip this published folder to create an artifact. Let’s do it one by one!

First of all, we’ll add the task, at the end of the file, to execute a command to publish with the path where we have our main .csproj file and set a configuration to run it as a release :

- name: Publish
  run: dotnet publish DotNet6WithGithubActions/DotNet6WithGithubActions.csproj -c Release -o release — nologo

After that, your file will look like this:

Let’s commit it and see what happens:

Let’s go to the repository on Github, check the Actions and click on the newest build (after the commit):

As we could see, the task publish ran and publish the built files on the folder /release (last line).

Now, let’s add the task to build the artifact. It will zip the released files to be able to release them. The 2 arguments we will use in this task are: the name of the build (it will be necessary when we start to configure the release tasks to publish the application) and the path where the released files are been published in the previous task dotnet publish.

- name: Upload Build Artifact
  uses: actions/upload-artifact@v2
  with:
    name: Application_Artifact
    path: /home/runner/work/DotNet6WithGithubActions/DotNet6WithGithubActions/release/

Let’s commit it to see the results now:

Now, if we see the newest item on Actions, we’ll see an artifact published in the overview of the action:

If you want, you can click to download and will be able to download it as a zip. Just remember this is not the purpose of this article because in the next article we’ll be able to integrate it with Azure Releases to publish it in a Web App Service.

If we check the tasks of this action, we’ll be able to see the log to upload this build artifact:

The last part we have to do is deploy the release files into a specific branch to be published. So, we are going to add the last task on dotnet.yml to do that:

- name: Commit release to GitHub Pages
  uses: JamesIves/github-pages-deploy-action@3.7.1
  with:
     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     BRANCH: release
     FOLDER: release

This task will use your personal GitHub key token to create/use a branch named release and will publish the files which are in the folder release. If we commit it we’ll be able to check the actions running:

After that, we can come back to the code and see the new branch created with the files. This will allow us to deploy these files through an Azure Release Pipeline to publish in a Web App Service.

That’s done, folks!

Now, our project is able to check if the code is OK to be released and generate the file which is going to be published by a releases tasks on Azure Dev Ops.

The next articles will be to configure an Azure Release on Azure DevOps to integrate with Github and be able to recognize these artifacts each time of a new commit on the main branch.

After that, the next article will be the last one to show how to configure a Web App Service on Azure Portal and configure it on Azure Releases Pipelines to be able to see the flow happening completely. We’ll finish it by developing a new change on our code, committing and seeing the magic happen to publish a new version automatically in our web app.

I hope the article is clear enough for you guys to start to implement it in your projects. Please let me know if you have any questions or suggestions!

Cheers!!!