You may use Github Actions to construct unique software development lifecycle workflows right in your Github repository. These workflows are made up of many activities, or actions, that can be executed automatically in response to particular triggers.
This allows you to incorporate features like continuous integration (CI) and continuous deployment (CD) right in your repository.
In this tutorial, we’ll go over the fundamentals of Github Actions and even go over how to make your custom workflows.
1. Why are Github Actions important?
- Github Actions and what advantages they give.
Built into Github: Github Actions is completely integrated into Github and so does not require a separate website. This means it can be managed alongside your other repository-related features like pull requests and bugs in the same place. - Multi-container testing
Multi-container is a technique that involves testing multiple containers at the same time. By adding support for Docker and docker-compose files to your workflow, you can test multi-container setups. - Multiple CI templates are available:
Github offers a variety of templates for various CI (Continuous Integration) configurations, making it relatively simple to get started. You can also make your templates, which you can then share on the Github Marketplace as an Action. - Excellent free plan:
Every open-source repository receives free actions, including 2000 free build minutes per month for all your private repositories, comparable to most CI/CD free plans. If that isn’t enough for your needs, you can upgrade to a different plan or go self-hosted.
2. The fundamental ideas
The basic principles utilized in Github Actions are listed below, and you should be familiar with them before using them or reading the instructions.
- Actions:
Actions are the simplest and most portable building blocks of a process, and they can be combined to form a job. You can build your Actions or use Actions from the Marketplace that have been posted publicly. - event:
An event is a specific activity that causes a workflow to run. When someone pushes to the repository or creates a pull request, a workflow is initiated. Webhooks Runner can also be used to configure events to listen for external events: - runner:
A runner is a computer that runs the Github Actions runner program. The runner then waits for jobs to become available, which it can subsequently execute. They run the task’s actions after picking up a job and report the progress and outcomes to Github. Runners can be self-hosted on your machines/servers or hosted on Github. - Job:
A job is made up of numerous phases that run in a virtual environment instance. Jobs can execute in parallel or in sequence, depending on whether the current job relies on the success of the prior one. - step:
A step is a collection of tasks that a job can do. Steps can be used to execute instructions or operations. - Workflow:
A Workflow is an automated procedure that can be initiated by an event and is made up of one or more jobs. Workflows are defined in the.Github/workflows directory using a YAML file.
3. Using action and workflow templates
Using one of the many process and action templates available on the Github Marketplace is the simplest way to get started with your workflow. If you’re not sure which activities would be useful, have a look at the Github suggestions, which are tailored to each repository.
- Adding a workflow template entails the following steps:
- Navigate to Actions on the main page of your repository. Then select a template from the drop-down menu and click Set up this workflow. Template for a Node.js actionFinally, using the Start commit button, you can make modifications in the editor and commit the action to your repository.Editor for workflows
- Adding an action template to your workflow consists of the following steps:
Action templates are available on the Github Marketplace and in the workflow editor on the far right.In the workflow editor, there are action templates. By copying the actions’ code and putting it into your.yml file, you may add the template. The uses keyword must be used to define the unique action name and version number.
Installation of action
4. Creating a workflow
You may be curious about the syntax used to write and configure workflows now that you know how to use templates for your workflow.
- Creating a workflow file entails the following steps:
- By adding a.yml workflow file to the.Github/workflows directory, workflows can be constructed. Add.github/workflows/continuous-deployment.yml to your project, for example.You can begin working on your workflow after you’ve created the file.
- Syntax in general:
Github Actions files have either a.yml or.YAML file extension and are authored in YAML syntax. If you’re new to YAML and want to learn more, I recommend reading, Learn YAML in Five Minutes” or, Introduction to YAML.”
The workflow file’s most essential concepts are listed below.
Name:
This is the name that appears on the Github activities page for your process. If you leave this area blank, the file name will be used.
Continuous Deployment is the name of the project.
The on keyword specifies which Github events will start the workflow. You can schedule a workflow with a single event, an array of events, or a configuration map.
on:
[pull request, problems] or on: [push #]
Jobs:
One or more jobs make up a workflow run. Jobs describe the functionality that will be executed in the process and, by default, runs in parallel.
jobs: my-job: my-job-name: my-job-name: my-job-name: my-job-name
-on: ubuntu-latest -on: ubuntu-latest -on: ubuntu-la
title: Run the following command to print a greeting: | echo Good day, there! More about that in the next part.
Env:
Env is a map of environment variables that all jobs and steps in the process can access. You can also define environment variables that are exclusive to a job or a stage. CI: true env
5. Choosing a situation
It’s critical to test your workflows in the correct conditions to ensure that they’ll work in real-world scenarios. We’ll go over how to specify which OS and software versions your process will operate on, as well as how to set up your build matrix to execute a workflow in different environments, in this part.
- Runs-on:
The runs-on keyword allows you to specify the OS (Operating System) that your workflow should run on, such as Ubuntu’s newest edition.
ubuntu-latest is the operating system that it operates on.
- Create a matrix:
You can test across different operating systems, platforms, and language versions with a build matrix. The strategy keyword can be used to provide a build matrix, which is then sent to runs-on.
runs-on:
$$$$$$
strategy:
os: [ubuntu-16.04, ubuntu-18] matrix .04]
[6, 8, 10] node
You run your project on two distinct operating systems and three different Node.js versions. Visit the docs for more information on a build matrix and the strategy keyword.
6. Dependencies on caching:
Workflow runs frequently reuse the same output as previous ones, thus they can be cached to improve performance. Every task running on Github-hosted runners begins in a fresh virtual environment and does not use caching by default.
- Parameters to enter:
The key (required) identifies the cache and is generated when the cache is saved.path (Required): The directory’s file path to cache or restore.
If no cache hit was found for the key, restore-key (optional): An ordered list of alternative keys to use to find the cache.
- Parameters for the output:
cache-hit:A boolean variable that indicates if the cache action was successful.Saving the npm cache as an example:
Caching with npm is the name of the project.
on:press
jobs: build: ubuntu-latest-latest-latest-latest-latest-latest-latest-latest-latest-latest
steps:– actions/checkout@v1 is used
– name: Cache node modules; path: node modules; actions/cache@v1; name: Cache node modules; name: Cache node modules; name: Cache node modules; name: Cache node modules; name: Cache
hashFiles(‘**/package-lock.json’) key: $ runner.OS -build-$ hashFiles(‘**/package-lock.json’)restore
-build-$ env.cache-name -build-$ env.cache-name -build-$ env.cache-name
– build-$ env.cache-name -build-$ env.cache-name -build-$ env.cache-name
– $ runner.OS -build- $ runner.OS -$ runner.OS -$ runner.OS -$ runner.OS -$ runner.OS -$ runner.OS
Install Dependencies is a term for a program that installs dependencies. npm install is a command that may be used to install npm modules.
– name:npm build; npm build; npm build; npm build; npm build;
– title:npm test is used to execute the test.
In this example, we cache the node modules directory of a Node project so that dependencies don’t have to be installed with each workflow execution.
7. Workflow data that lasts:
Artifacts allow you to transfer data across jobs in progress and save it once the workflow is finished. A file or set of files created during a workflow run is referred to as an artifact.
- To share data between jobs, do the following:
Before the job is finished, save the file to an archive.
The file can be utilized in other jobs within the same workflow after it has been uploaded.
There are a few frequent scenarios in which artifacts are saved.
Files containing logs
Failures, test results, and screenshots
The output of the stress test and the code coverage results
Data transfer across jobs:
To communicate data between tasks in a workflow, use the upload-artifact and download-artifact actions.
name:Data should be shared between jobs.
[push] [push] [push] [push] [push]
upload-data-job: name: Upload data to artefact runs jobs: upload-data-job: name: Upload data to artefact runs jobs: upload-data-job: name
-on: ubuntu-latest -on: ubuntu-latest -on: ubuntu-la
– bash run: | echo Hello World! > hello-world.txt – shell: bash run:
Upload – name actions/upload-artifact@v1 is used in the hello world file.
hello-world.txt is the name of the file.
download-data-job: name: Needs to download data from artifact: upload-data-job runs
-on: windows-the most recent steps:
– shell: bash run: | value=cat hello-world/hello-world.txt echo $value > – name: Download hello world file uses: actions/download-artifact@v1 with: name: hello-world – shell: bash run: | value=cat hello-world/hello-world.txt echo $value > hello-world/hello-world.txt
– name: Upload hello world to artefact with: name: hello-world path: hello-world.txt uses: actions/upload-artifact@v1 with: name: hello-world path: hello-world.txt
In this example, one service creates a file and publishes it to the artifact that uses the upload-artifact action. The file is subsequently downloaded and printed to the console by the download job.
Visit the official documentation for more examples of workflow data persistence.
Taking care of a workflow
On the workflow page of your repository, you can observe and manage your workflow runs. It enables you to start, cancel, and restart jobs and view the outcomes of those that have already been completed.
A page dedicated to the workflow You’ll see a list of all the workflows that have run in your repository, and you can drill down into each one by clicking on it.
A detailed page on the workflow
The official documentation contains more information. Taking Actions You can write custom code that interacts with your repository to produce actions, which you can then use in your workflows or publish on the Github Marketplace.
- You may create Docker and Javascript actions on Github, and both require action. Use a YAML metadata file to identify your operation’s inputs, outputs, and principal entry points.
8. Metadata syntax is as follows:
As previously noted, both Docker and javascript actions necessitate a metadata file named action.yml. Here’s a rundown of the various fields, along with a brief description of what they do.
name (required) – The name of the action that will be used in each task to identify it.
brief description (Required) – A brief description of the action’s functionality (required) – The command that will be executed after the operation is completed author (Optional) – The action’s author’s name is entered (Optional) – A list of input parameters that can be used to generate runtime output (Optional) – A list of output parameters that will be used by following actions in the workflow.
An example of a file could be as follows:
‘Hello World’ is the name of the program. Its description is ‘Greet someone and keep track of the time.’
who-to-greet: who-to-greet: who-to-greet: who-to-gre
‘Who to greet’ is a requirement: true
‘World’ is the default setting.
time: outputs
‘The time we greeted you’ is a description.
‘node12’ is being used.
‘index.js’ is the primary file.
- JavaScript actions
Javascript actions can be run directly on any of the GitHub-hosted virtual machines, removing the action code from the environment. When compared to the Docker alternative, they run faster and are easier to build. - Docker Action
Docker action By packaging your action’s code with the environment in a Docker container, you may build a more consistent and reliable unit of work. You can use specific versions of an operating system, dependencies, tools, and code in a Docker container.
Conclusion
You persevered to the end! I hope this article has given you a better understanding of Github actions and how to utilize them to automate your Github workflow.
