Building Angular Apps Using GitHub Actions

Configuring a CI/CD workflow for Angular applications using GitHub actions

BG Image — Unsplash

GitHub Actions is the automation tool to add CI/CD workflow for projects on GitHub. It is currently available for the general public and is completely free to use for open-source projects.

In this piece, we’ll talk about the various steps to integrate the CI/CD workflow in an Angular project. We’ll be focusing on GitHub actions configuration in the Angular project. The basics of creating an Angular app and how it works are out of scope here.

Let’s go through the steps one by one.

1. Creating a GitHub Project

The first and obvious step is to create a GitHub project and connect your Angular project with the repository.

If you’ve successfully completed the sign-up process for Actions beta, you should be able to see a new “Actions” tab for your project, right next to “pull requests.”

Actions tab in the repository.

2. Adding the Workflow file

GitHub provides predefined workflows for many of the most popular platforms. You can also customize or create new ones in a visual editor.

But in this project, we’ll be taking the manual approach of creating a YAML file with the workflow commands.

In the root folder of your angular project, create a new folder, .github, and create a subfolder workflows. This is where our workflow YAML files will reside.

A project can have multiple workflow files like build, release, etc, but for the sake of simplicity, we’ll be using only one file for this project. Create one final file, named main.yml, in the workflow folder.

Creating a GitHub folder and adding the workflow file

3. Writing Commands

The first thing we define is the event on which we want our workflow to be triggered. This can be any GitHub event, such as push, pull_request, create, etc, based on your requirements.

In this project, we’ll be using the push event. We can also add a name to the workflow to identify it. Here’s the entire code for main.yml. For better understanding, we’ll go through each line and its use.

main.yml

• line 1: We want to trigger our workflow when someone pushes the code to our repo.
• lines 3–8: We are defining a job Build Angular which runs on ubuntu-latest. Each job runs in a fresh instance of a virtual environment. A job can contain one or more steps. We also define the NodeJS version we want to run.
• line 11: This is the first step in our workflow. We will pull the source code from our repository using a GitHub Action called [checkout](https://github.com/actions/checkout). This action checks out your repository to $GITHUB_WORKSPACE, so that your workflow can access the contents of your repository.
• lines 13–19: Since we need to install npm packages required for the project before building the app, we use a GitHub action called [cache](https://github.com/marketplace/actions/cache) to cache the node modules. We configure this step to track our package-lock.json for any changes to npm packages and if there is no chance we use the modules from the cache. This will help us in speeding up the build process.
• lines 20–23: Here we use the GitHub action setup-node which sets up a Node environment for use in actions. We use the reference to the node version that we set when we define our OS.
• lines 24–27: In this step, we run npm i to install the required packages and then run the Angular build command to create the build package. In this example, I am using npm run build:prod as that’s the build command I’ve defined in my package.json.

In the above step you can add any commands that you have defined in your *package.json*. For example, you can define a command that runs test cases first and then creates the build. This is completely up to your project scope and requirements.

• lines 28–32: Pushing the build files to releases section of the repository using a GitHub Action Create Release. Here, we specify the path where the build files are stored after building and specifying * to ensure that all the build files are pushed to release.
• The secrets.TOKEN is an API token that grants access to the repository. We will create one and add it to our project in the next step.

4. Adding a GitHub Token

Most of us would have created a GitHub token at some point for repository access. If you haven’t, the process very simple and straightforward.

• Go to the personal access tokens section in your GitHub settings.
• Generate a new token which has scope for repository access and copy its value.
• Go to the repository settings for your project at <repo url>/settings/secrets. In the “Secrets” tab, add a new secret with the same token name from your workflow file (TOKEN in this project) and paste the token value.

Adding a new token in repository settings.

5. Pushing Code With Tags

Once we’ve created the workflow files and added tokens to our project, we can push the code to GitHub with release tags and trigger the workflow.

In your local project, commit all the files including the main.yml and add a new tag using the git tag command and push the code along with the tag.

Example:

git tag v1.0

git push origin v1.0

Seeing the Workflow and Release in GitHub

Once you’ve pushed the code you can see the workflow in action by going to <repo URL>/actions and see the release files by going to <repo URL>/releases.

History of workflows triggered

Workflow commands getting executed for a push event

Build files in the release section of the repository

That’s it. You can find the complete source code of the project on GitHub. If you have any issues please post them in the comments section.