Github Actions for Angular Projects: Pipeline for Testing, Building and ng update

Hey everyone, if you're like me and have multiple angular projects in your GitHub account, it can be time consuming keeping every project up to date. So why not automate these tasks and let GitHub do all the heavlifting for us. So by the end of this video, we'll have a GitHub actions pipeline created for testing, building and updating angular applications.

We'll also enable depandabot for automatic dependencies updates. Let's get to it. So for this exercise, we'll create a brand new project from scratch so we can do it all together.

So open in the terminal I navigated to the place where I would like to create my project and I will use angular CLi to create it. But before we get started, let me just check the version that I'm using. I'm using right now, 17 one one and angular just released 17.

3. So we are a little bit behind and this is exactly what we need so we can showcase the angular actions in practice. So I'm going to be using the command ng new and the name of my project, which I'm going to call angular GitHub actions.

So I'll choose CSS. I'm not going to enable SSR, it's going to be a very simple project. So now that's done, I'm just going to open the folder and I'll open it in my favorite editor, which is vs code.

So in vs code we can just double-check the version in the package. Json it's 17 10 and we're good to go. We're going to be committing this project into GitHub.

And to do so, I'm just going to create new repository angular GitHub actions. You can give it a description. This is going to be public.

I'm not going to initialize because angular has already all the files for me and create repository. So with this in place, all we have to do is just push an existing repository from the command line. So I'm just going to copy this line so I can connect my code to GitHub.

So on the terminal I'm just going to paste this is going to add the origin to my local repository. We already have the main branch and all we have to do is publish the branch. Once that's done, let's go back and our source code is now available on GitHub.

So the first thing we're going to do is double check if GitHub actions will have access to create pull requests in our repo. So let's go to settings on the sidebar, select actions general and just scroll down to the workflow permissions. We want GitHub actions to be able to read and write and also allow GitHub actions to create and approve pull requests.

We're not going to automatically merge pull requests, but we're going to allow our GitHub actions to create pull requests for us and save. Make sure that this is enabled, otherwise your GitHub actions will fail. Next, what we can do is go back to security and we're going to enable dependable by default, dependent bots are disabled, so we're going to enable the dependent bot alerts.

You can read route this page as well and select if you like to enable any other options. But for now we're going to enable our dependent bot alerts. The next configuration that we would like to enable is the Dependabot security updates.

This option will actually enable Dependabot to create pull requests for us, and the third option is dependent bot version updates. So we're going to enable this. By doing so, it's going to create a dependabot Yaml file under the GitHub folder.

And here is where we can configure what kind of packages that we would like to scan. So in case of angular, we're using the NPM and the schedule. You can set the interval that you like.

I usually find weekly the best because it's going to scan once a week, and once a week I'll be able to keep all my dependencies up to date. So we're going to commit the chains we can commit directly to the main branch since this is a brand new application. Otherwise I would suggest you to create a new branch and then create a pull request.

So now that this is done, we're going to be enabling our first action. So let's go back to the actions we can search by angular. Press enter.

We can use node JS, since angular relies on NPM for dependency management configure, and here we can customize according to our needs. In this case, we're only going to be running this workflow whenever we are pushing on the main branch or when we're doing pull requests for this particular workflow, we're not going to be deploying. I usually like to have a separate workflow just for deployment purposes.

So this way whenever I'm raising pull requests, I'm able to check if my pull request is not breaking my application. Also, the other thing that I would like to do is just call this build or angular or something different other than Node Js Yaml we can also set up what's the node version. So I usually go with version 20.

We're going to be checking out our code using the node JS. If you want to, you can also specify the location of your package lock JSON. I usually like to add this information as well.

Then we're going to run the NPM CI. This is going to install all of the dependencies not based on your package JSon, but based on your package lock JSON. Then I like to create a new step for test.

First I'm just going to give a name so I know that this is running the tests and this is going to run the NPM run test CI. And the last step is the build. And here I'm going to run the NPM run build.

We can remove this last options. I'm going to commit these changes and once that's done and the workflow is going to be triggered shortly after we commit to our main branch again, this is going to fail because we don't have the NPM run test CI. And the reason is whenever we go back to our angular project, if we open the package JSon, this script doesn't exist.

So if we run the NPM run test, this is going to run the NG test behind the scenes. And whenever we're running the NG test, by default we have karma and Jasmine and we can see that this is going to open a browser. But whenever we are running in our CI pipeline, we don't have a browser.

So we have to modify this so we don't use a browser. I'm going to add a new script. I'm going to call test CI same way that we did in our Emo file.

And we're going to run the engine test. We're going to run this only once. I don't need to know the progress, so I'm just going to disable the progress.

And for the browsers I'm going to use a chrome headless. So this is still going to run all the tests behind the scenes. We don't have to open a browser.

Let's just run this locally so we can see exactly what's the result. So NPM run test CI. And there we go.

We have a total of three test cases that were executed and it is a success. And this is exactly what we need to have in our CI pipeline. So what I'm going to do is first I'm going to open the source control.

I'm just going to get all the changes first before I commit, and then I'm going to stage my changes and I'm going to add the test CI and push the changes to the origin. So once we do this, if you go back to the actions and we refresh, the workflow has been triggered once again. And after running we can see that all steps have completed.

And if we like to see the details for the run tests, we can also see all the logs. And again we're going to have the exactly same output. One of the things that I don't like with the dependabot is especially when working with angular projects, whenever there is a new angular version, we have several different packages that are going to be updated.

You cannot update the animations package without updating the core package, for example. So all these upgrades, they have to be done together. Even if you have dependent bot enabled, we're still going to struggle in keeping the angular dependencies up to date.

This is great for other packages like the follow redirects or for the typescript or zone JS, but for angular itself, we still need another solution. There is another GitHub action that's called Ng update, which allows us to do the angular update altogether for our projects so we can view it on marketplace to use it. We can create a new workflow and copy this content.

So let's go ahead and do that. So I'm just going to create a new file which is called Ng update. And to do so, we have to go in the GitHub and we're going to add a new file.

So I'm going to create a new file and I'm just going to copy the content that's provided by the documentation. So here we have a few different options. This is the update angular action on the documentation.

It's saying that this is going to run on the push, but since this is the angular update, this is going to run the NG update behind the scenes. What I want to do is actually run this on a schedule. So I'm going to enable a cron job here.

So here two spaces there is a link that we can see exactly when we would like to run. So if we search by cron, we'll see the options here. First one is the minute, second one is the hour.

So this cron job is going to run at 530 in the morning. You can specify the day of the month and the month as well. And the last parameter is the day of the week.

So one is going to be Monday, three is going to be Wednesday. So I'm just going to run this as 530 in the morning. I'm not going to specify a day or a month, and you can run this once a week, twice a week however you like.

So here it's Monday, Wednesdays and Friday. There is no need to run this three times a week. So usually on Wednesdays is okay.

Usually by Wednesdays is also when the dependent bot is going to run. So if I want to keep all my projects up to date, I can select one day of the week for this action to run, and then I can just march all the pull requests. The next thing that I'm going to do is actually modify the Ng update.

If we go back to this action, and if we go to the GitHub repo, the release is actually the V one and not the master. So here instead of add master, I'm going to specify the V one. Otherwise this is going to break.

And the other thing that I'm going to do, that this repo is still using the master branch as the base branch. So I'm going to specify what's my base branch here as well. My main branch is actually called main, and this is a secret that's provided by GitHub.

We don't have to configure anything so we can commit the changes. I'm actually going to create a new branch for this and then start a pull request. Just make sure we're not breaking anything.

One of the benefits is that whenever we create a pull request, you can see that the node JS CI that we have created is now going to get triggered. We should wait for all the checks to pass to make sure that any changes that we are introducing to our project is not going to break the main pipeline. Now that all checks have passed, we can safely merge the pull request, and then we can delete the branch.

And now that our pipeline is in place, let's see it in action in another repository which has been running with this GitHub actions for a while. I have some dependent bot alerts, but I also have two pull requests for the angular dependencies. One was open two weeks ago, so if I check this out, it's from the version 17 two one to 17 two.

So usually this is not going to have any breaking changes and it's safe to merge. However, Angular also has released the 17 three version. So here I have my existing version, the 17 two one, and we can also update to 17 three.

Everything is passing so that it is fine. So I'm going to go ahead and merge this pull request. Now that this is merged, I can safely delete this branch and the actions are going to be triggered.

So what's going to happen next is all of the pentabot pull requests that we have open here. They're going to get closed automatically. All we have to do is just wait for this action to run and see all of the other pull requests get closed.

And anything that's remaining we can review and choose to merge or to reject the pull request. So everything is okay with the build. Now let's check again the pull requests and we'll see that we only have three pull requests left.

Now this one is for an older version. We don't need this anymore. This is going to trigger again the check.

So there are conflicts here. And again this is going to be downgrading the version. What we will do is actually close this pull request because this is no longer needed and we can also delete the branch.

Now let's take a look at the last pull request, which is the redirects from 115 four to 115 six. This one is also okay to merge, so we're going to go ahead and do that as well. And there we have it.

Now our project is up to date using the latest angular version, and all we had to do is just set up the actions once and in a weekly basis. We just check the pull request and we can go ahead and safely merge the ones that have all the checks passed. One last item is in case you have full stack projects or you have repositories where you have multiple projects under it in your workflow.

You can also set up where you like to get the dependent bot updates done. So for example, I have a Java spring project under the crud spring, so I'm using the maven dependabot and under the crud angular I have the NPM dependabot so I can specify the directory where I would like to scan for any dependencies. Likewise, we can go to the workflows and in the NG update as well.

We can also specify what's the project path, and in the same way in our build Yaml file we can also set up the working directory so we can run our CI pipeline as well. I hope this video was useful. Let me know in the comments if you're planning to use these GitHub actions in your code, or if you have any other GitHub actions that you're using and would like to share.

Thank you for watching and see you soon.