Automate your releases with GitHub Actions

Hey everyone. Hope you all are into the celebration vibes and eagerly waiting for 2023. It is the same for me as well. Waiting for all the new learnings in 2023 whilst reminiscing the memories of 2022. I am really excited to write this blog and share it with you all. The first thing is that this is my first ever blog after I joined Spritle and the next thing is that I learned some cool things in GitHub Actions.

For the past few days, I was reading about GitHub actions and also luckily got assigned some tasks regarding it. So, guys, I would like to share how I automated releases with GitHub Actions. We will go through it step-by-step. Let me do the honors!

Before we start, let us quickly brush that layer of dust off our minds and revise what GitHub Actions are, and its basics to help us to get a better understanding. And to people who are new to GitHub Actions, you can also refer to the blog by my fellow mate Muralitharan on why GitHub Actions with Firebase is the best way to distribute mobile apps automatically.

Introduction to GitHub Actions:

• GitHub Actions is a tool event-driven automation platform that allows you to run a series of commands after a specified event has occurred.
• For example, when a commit is made to your staging branch, and you want to build, and test, the changes to your staging environment. Actions allow you to automate tasks within your development lifecycle within GitHub.
• GitHub Actions can manage and operate workflows through Linux, Windows, and macOS operating systems.
• GitHub actions also support a variety of coding languages, such as C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Scala, and TypeScript.

Components of GitHub Actions:

Here I will be explaining the Workflow and how GitHub Actions Workflow is configured to trigger any event in your repository. Come let’s go!

Workflows-

• A process that runs one or more jobs is called a workflow.
• Workflows are defined in YAML & YML files and are stored in a .github/workflows directory at the root of the repo.
• A repository can have one or multiple workflows, each workflow can perform a different set of tasks.
• Running the workflows- They are 3 ways to trigger the workflows:
  • Workflows can be triggered by an event in our repository. Some common examples are creating a pull request, pushing our code, and adding a label.
  • They can be scheduled to trigger at a particular time. For example, running a workflow at 5 PM every day or 2 PM every Monday only.
  • They can be triggered manually to run. On the main page of the repository, We can manually go to Actions under the repository name and run our workflow manually anytime.

Events-

• Specific activity in the repository that triggers workflow execution.
• Some common example of events includes Creating a PR, Pushing code to a repo, Creating a new branch, Opening/ Closing an issue, etc.

Jobs-

• A set of steps in a workflow that runs on the same runner is called a job.
• Steps in the job are executed in order and are dependent upon each other.
• All steps of a job run in one runner, and data can be shared from one step to another.
• One job can be dependent or independent of other jobs as per our requirements.
• By default, Jobs run in an asynchronous manner.

Actions-

• Actions are custom applications that perform complex but frequently repeated tasks.
• You can use an action to help reduce the amount of repetitive code you write.

Runners-

• A runner is a server that runs your workflows.
• Runners can run a single job at a time.
• A runner listens for available jobs, runs one job at a time, and reports the progress, logs, and results back to GitHub.

These are the basics to know about GitHub actions. If you want to explore more GitHub actions, I have attached the reference links at the end of this blog.

Hey, wait! Don’t go off yet without learning about Git Release Automation.

Git Release Automation:

I will be explaining how to automate the git release when one set of code is merged to the main branch. For that, first, let us know what is git release and usage.

Git Release–

The release is a great way to provide packages in binary files. You can add release notes for every release of the software. It will help other people for reference.

Usage–

• Git Release is used to avoid storing largely generated binaries built from a project in a source control system like git.
• A deployable software iteration that can be packaged and made available for download and use by more users.
• Releases are based on git tags which are used to mark a specific point in your repo’s history.

Additionally, we can have some features by using this script:

• We can set the value for the Version bumping scheme by default or we can override the value by using pull request labels.
• Creates Release Notes automatically that are optional (with a list of commits since the last release)

Okay Now we can see the workflow to automate the git release.

This is the workflow to automate the release tag. The below-mentioned values would be used in bump_version_scheme.

• minor
• major
• patch
• No release will help us to not create the releases by default. The creation of the release depends upon the labels we added to the pull request.

We have some additional features using this workflow, let’s see what they are :

1. You can able to skip the creation of the release–

• Adding [norelease] label to your pull request (add new labels using the edit labels option in the create pull request page) that helps you to not create the release when the code is merged.
• Setting the action’s bump_version_scheme to no release. This is another way to set the disabled by default.

Like this, we can add a label to skip the release.

2. If the bumb_version_scheme sets to norelease by default, we have to change that bump version scheme to create the release right? In this situation, we are going to use the major, minor, and patch in our labels.

• If the label release:major, release:minor, or release:patch attached with the PR means, this will override bump_version_scheme.
• Only one of these labels should be present on a PR. If there are multiple, the behavior is undefined.

3. You can customize your release body message by adding the release_body tag to your script. The contents of this are appended to the release description.

Creating Release Tags with Release Notes:

We can automate GitHub release notes by using the use_github_release_notes tag to set it as true in our main.yml file. For doing this, we have to create the release.yml file inside the .github folder.

While creating the pull request or merging the pull request have to add a label to create the release notes for that release.

Changing the tag name and release name for every release:

Changing the Tag name and Release name for every release:

Yes, we can customize the tag name and release name by using the tag_prefix and release_name tag. All you have to do is add the below code in the last of your main script.

After completing the above-mentioned steps and after pushing your code to the main branch you would be getting the output as shown in the below video.

Summary

GitHub Actions helps us to create the release automatically whenever the code is merged to your specified branch. So in this blog, we saw what is GitHub actions and how to automate the release tag. In my next blog, we shall see how to create your own actions in GitHub. Until then keep expecting the best from us as always!

Have a happy and wonderful New Year 2023!

References:

1. To explore more things about GitHub action, please refer- https://docs.github.com/en/actions.
2. GitHub Repository for automating the GitHub release. Please refer-https://github.com/Ajithkumarparthasarathy/release-tag-one.
3. Script GitHub Repository, please refer- https://github.com/Ajithkumarparthasarathy/automate-release-action.