Github action is a CICD tool offered by GitHub itself. We can implement and use of GitHub and other tools along with it. It’s more or less like any other CICD tool but has its pros and cons. Here the pipeline is called workflow. For example, we can create a workflow that will label the issues created in the repository by itself. Here containers are also called virtual machines runner.

Jobs: Jobs are a set of steps in a workflow that is executed on the same runner. As the steps are executed in the same runner the data can be shared from one step to another. Building an application and testing the same application in the next step is an example.

Jobs can have dependencies, your end-term exam sheets can only be examined by your professor when you have attempted and submitted them. Here, your professor is dependent on you and can only upload marks when you have submitted your answer sheets. Similarly, you can configure to have many jobs running in the same step parallel to each other and can be compiled together the next time only when they all have been executed.

Actions: The term Github Actions in itself has the word in it. Reciprocating that Action is what makes Github Actions better than every other tool. Action is an application that performs a complex but frequently repeated task. Action is what makes it easy and defines the automation in DevOps. It just automates all your workflows.

Runner: They are a kind of virtual machine but cannot limit it to just that. GitHub provides all kinds of operating systems, each workflow provides new virtual machines or runners. There is a provision of self-hosted runners, which gives you the flexibility to create customized hardware setups according to your specific requirements. You can have more processing power or memory available to handle larger tasks. Additionally, you can install software that is available on your local network and choose an operating system that may not be supported by GitHub.

#githubactions #devops #cicd #virtual machines