Github Actions enables you to create custom software development lifecycle workflows directly in your Github repository. These workflows are made out of different tasks so-called actions that can be run automatically on certain events. This enables you to include Continues Integration (CI) and continuous deployment (CD) capabilities and many other features directly in your repository.
Below is a list of the core concepts used in Github Actions that you should be familiar with when using it or reading the documentation.
Actions are the smallest portable building block of a workflow and can be combined as steps to create a job. You can create your own Actions or use publicly shared Actions from the Marketplace.
Events are specific activities that trigger a workflow run. For example, a workflow is triggered when somebody pushes to the repository or when a pull request is created. Events can also be configured to listen to external events using Webhooks.
A runner is a machine with the Github Actions runner application installed. Then runner waits for available jobs it can then execute. After picking up a job they run the job's actions and report the progress and results back to Github. Runners can be hosted on Github or self-hosted on your own machines/servers.
A job is made up of multiple steps and runs in an instance of the virtual environment. Jobs can run independently of each other or sequential if the current job depends on the previous job to be successful.
A step is a set of tasks that can be executed by a job. Steps can run commands or actions.
A Workflow is an automated process that is made up of one or multiple jobs and can be triggered by an event. Workflows are defined using a YAML file in the .github/workflows directory.
# This is a basic workflow to help you get started with Actions
#The name of your workflow that'll be displayed in the Actions tab
# Events that control when the action will run.
# Triggers the workflow on push events but only for the main branch
# Allows you to run this workflow manually from the Actions tab
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
# This workflow contains a single job called "say_hello"
# The type of runner that the job will run on
# Steps represent a sequence of tasks that will be executed as part of the job
# Runs a single command using the runners shell
- name: Say Hello
run: echo Hello World!
# Runs a set of commands using the runners shell
- name: Say Goodbye
echo Job Finished.
#Viewing the Workflow Activity
With the changes you made, whenever you push a change to the main branch, it’ll run this workflow. Since you already pushed the change to GitHub, you should have had your workflow executed. You will see the workflow executions on the Actions page on GitHub. You can see a visual graph of the progress for each execution, and also drill down into the details of each step. Follow the instructions below to see the workflow executions:
Open GitHub and go to the main page of your repository.
You will find the Actions tab after Pull requests. Click Actions to open the Actions page.
You should see the workflow listed in the left sidebar, and the run for the workflow listed on the main page. Click any of the workflow runs you would like to see more information about its execution.