For demo’s I host my code in GitHub. It’s easy, fast and allows interested people to download and use your code in no-time. However, for some of these projects I like to build, test and even deploy stuff to test or demo environments so I can show them. To solve this, I used to create a new project in Azure. I build a (couple of) pipeline(s) with GitHub as my repository and suddenly it didn’t make sense to host all the code in GitHub anymore. And then there were GitHub Actions.
My-First-Project
So I took one of my projects to the test. The repository that belongs to my previous post ‘Azure Functions Single Responsibility’. It contains two projects, one Azure Functions project, and an Angular project. Let’s get easy on this one and take the Angular project for a test run. I want it to build and deploy to Azure after a push on the master branch. Here we go…
Create an Azure environment
So usually you want to really think of your hosting environment, especially for Angular projects because there is just a huge load of flavors here. But again, for my first run, I decided to take it easy and create a simple Web App with an App Service Plan. After creation, I navigated to the Web App in the Azure Portal and while the ‘Overview’ tab was selected, clicked ‘Get Publish Profile’ from to top menu bar. I opened the publish profile (which is an XML File) and copied the content to the clipboard. Now it’s time to go to your GitHub repo.
Configuring GitHub
So I went to my project in GitHub, to the setting page and navigated to the Secrets tab. There I created a new secret called ‘AZURE_WEBAPP_PUBLISH_PROFILE’ and as a value, paste the content of your publish profile. Now you’re good to go ahead and create your first GitHub Action.
My-First-Action in action
So I navigated to the ‘Actions’ tab and clicked the magical ‘New workflow’ button. They have a load of default templates available which take away the most of the ‘i-dont-know-how-this-works’ learning curve and guess what!! They have exactly what I need… I template called ‘Deploy Node.js to Azure Web App’. This is cool, I clicked the ‘Setup this workflow’ which magically creates a YAML file for me.
Configuring the action
All I needed to do, was simply changing some of the pre-factored YAML like so:
WEB_APP_NAME
This is the name of your web app in Azure. So in the chapter ‘Create an Azure environment’ you created a Web App, copy and paste that name into this variable.
AZURE_WEBAPP_PACKAGE_PATH
This is the package path, this is not used for my Angular project, in stead, I created a new environment variable called ‘AZUREWEBAPP_DEPLOY_PATH’, because and set this to the (relative) path where Angular compiles my project to. By default this is ‘/dist/_ProjectName’. Now, first of all, my project is not at the root of my repository. It’s in a folder called Website. Then my Angular project is (also) called website, so the path Angular compiles to would be ‘./Website/dist/Website’ for me. So I created a new environment variable called ‘AZURE_WEBAPP_DEPLOY_PATH’ and set it to ‘./Website/dist/Website’.
Node version
Now when I did this, the default node version was set to 10.x, which is good enough for this project, so no change made there.
So after all this configuration is clicked the magical ‘Start commit’ button and watched the magic happen and unfortunately… it failed… This is mostly because my project was inside a sub-folder so I needed to set the working directory for the ’npm install, build, and test’ step.
Also, I didn’t implement any tests in my project -shame on me there- so I removed the test step. In the end, I finished with a YAML file looking like this. Now as soon I committed this file, I was actually surprised a green dot appeared. To be honest, I think that the action took a huge amount of time to run, the first time it succeeded it was 38 minutes and a bit. So I started to continue working on the project and saw that all the following builds took about a minute and a half (which is fine for me). So actually the first run took ages and all the others were fine.
Conclusion
Yes! There is YAML and in the world of YAML, developers start struggling. This is for me as well. Also, I couldn’t make up the working-directory setting in the build steps myself, I needed GitHub support for that because the proper documentation was hard to fine. The GitHub support, by the way, was very helpful and responsive, it just indicates there’s some room for improvement. But you must say, that the overall experience was good. I got to deploy my service within an hour, using an unknown platform even when the definition file was written in YAML ;)
Last modified on 2020-02-17
