Github actions - the least you should know.
Tags: github, dotnet, azure, githubactions
Published: 2022-02-24 09:48:26

_GitHub Actions_ is nothing more than a workflow orchestrator. Through it we can build a workflow with several actions that will describe the necessary steps to compile, test, package, create releases and even deploy our system. GitHub Actions allows us to implement CI and CD techniques in a simple way within our repository, no longer having to integrate with other systems.

Another great advantage of this functionality is the possibility of using GitHub's own _agents_, without the need to create specific environments to be able to execute our CI and CD workflows. This further streamlines the process of configuring and executing our workflows and reduces the cost of deployment, as we already have an infrastructure ready to use.


**Agents**

_Github-Hosted Runners_ - These are OS agents you want, hosted by Github for up to 2000 free minutes if you prefer. you will only be concerned with how to instantiate, not with maintaining the runner.

_Self-Hosted Runner_ - A machine that manages and maintains the self-hosted agent installed on this machine, they offer more control over hardware, OS and software tools than Github's Hosted Agents. With private agents, you can choose to create a custom hardware configuration with more processing power or memory to run larger tasks, install software available on your local network, and choose an OS not offered by Hosted Github agents.


**Workflow**

Configurable automated process that you can define in your repository to build, test, package and/or deploy. Workflows are made up of one or more Jobs and can be scheduled or activated by an event / trigger.

_Features of a Workflow:_

- File is hosted in .github/workflows folder Uses.
- YAML, .yml or .yaml syntax.


**Job** 

Set of steps that run on the same agent. You can define dependency rules for how tasks are performed in a workflow. Jobs can run at the same time and in parallel or run in sequence, depending on the status of a previous job. For example, a workflow might have
two sequential jobs that create and test code. Where the test job depends on the status of the build job. If the build job fails, the test job will not run. For agents hosted on Github, each job in a workflow runs in a new instance of a virtual environment.


**Actions**

These are individual tasks that you combine as steps to create a job. Actions are the smallest block of a workflow. You can create your own Actions, use actions shared by the Github community, and customize public actions. To use an action in a workflow, you must
include it as a step.


**Command**

According to the type of workflow, we can execute specific commands provided by a specific technology.


**Artifact**

Are files that come up when you compile and test your code. For example, artifacts can include binary files or packages, test results, screenshots, or simply log files. Artifacts are associated with the workflow execution in which they were created and can be used or implemented by another job.


**Secrets**

Are available throughout a workflow, allowing the storage of sensitive data in an encrypted form (so that when the workflow runs we can use these secrets without any headache).


_You who have come this far, now enough of the rambling, let's show it in practice_, I took a project from github to start with an example, to create a workflow we must enter the action within the chosen repository.



![Github Polly Project](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ezf2cwzf2lpmm68a35dn.png)

There, github itself suggests some workflows that match your repository, in my case PollyProject is a .NET project and he suggested two workflows, one where I only run the compilation and tests, and another where I also publish the my project somewhere.


![Suggested github actions for my repository](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/h82fu8f9w56gwiqd4xp3.png)

_Github Actions_ shows me other modes of deployments, continuous integration and automations, Github for technology coverage we know they are the best, and let's not forget that it is from microsoft, they could very well do only for applications of the technology itself, but for to serve the public were smarter and opened the door to other platforms and languages as well.


![Deployment, Continuous integration and automation Options](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mtc1sw3op9dz13f53e2x.png)

Well let's go to the basics, I chose the suggestion of just building and testing my application, then I opened this .yml where my workflow will be.


![An workflow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/vwetd9d1gzb4v2vywoso.png)

In .yml, we can assume that it will be executed on every push and pull request to the master. In your job it will run on a linux machine with the latest available version of ubuntu and then we have some steps to execute:

- A checkout action to then download the code to be executed
- An action to call the initial setup in .NET, passing which version of framework he will use.
- An action to restore the project with `dotnet restore` 
- An action to build with `dotnet build –-no-restore`. 
- An action to test with the normal `dotnet test –-no-build –verbosity command`

Saving this .yml will run it in the project, as it was a push to the repository.


![All workflow list from repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/alhp5f3oedi0yh5nk2el.png)

Well, once added and executed, now let's move our .yml to a new step, the publish part (Deploy / publish), for that when editing the .yml I chose the azure platform to do this for me, so I searched for azure web app.


![Github Actions marketplace](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lqj8sh9xmbxgw1qi6v7c.png)

After selecting it, it gives me a code snippet to add to the .yml, I ended up putting it under the entire .yaml structure, after all, deploying is one of the last items you do.


![Deploy in .yml](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/3ubrtg7v3cmn05ez8cyr.png)

Let's go to the example above:

- My build is now in the release configuration `dotnet build –configuration Release --no-restore`
- My publish is also in the release configuration with the output to a variable global called **AZURE_WEBAPP_PACKAGE_PATH** which is created before my job 
- I don't change anything in my test 
- My deploy:  

1. _app-name_: name of the azure web service.
2. _package_: It is the place where the publish was given so that the deploy takes it from there 
3. _publish-profile_: It is a document in xml format obtained in your own azure web service by download. Once obtained, you must add the content to the secrets of our Github repository as shown in the image below


![Github Actions secrets](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wto9fcgy7x17sxg2u5kp.png)

After doing these steps, just commit and push, and the workflow will run again, now your project is in azure!

To add a status on my workflow I must add it through the option to create a status badge and add the content to the repository readme (badge).


![Adding new badge](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hyn87xdr4w40jkk6xdn1.png)


![Badge in readme.md](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/de53em1wfy93326tl2nd.png)

Well, if you've come this far, I can assure you that you have the basics of knowledge about Github Actions, didn't you find what you needed? no problem, comment below and I will probably help you!

See you soon!