In this article, we’ll explore the continuous integration and continuous delivery or deployment of UiPath based projects.
Well, CI/CD is not a new term now and it’s being adopted widely across all the organizations with a certain level of automation.
The goal here today is to see how we should be able to automate the delivery of our automation projects to deliver faster and with high quality.
There are several tools available to perform/set up CI/CD pipelines such as Jenkins, Azure pipelines etc. which provides similar functionality.
We have already covered: (See links)
- CI-CD Using Jenkins –Implementing CI CD UiPath Using Jenkins Plugin – RPABOTS.WORLD (rpabotsworld.com)
- CI-CD Using Azure Pipelines –Implementing CI CD Pipeline for UiPath – RPABOTS.WORLD (rpabotsworld.com)
 In this tutorial, we will use the following tools: Git, GitHub, GitHub Actions, UiPath Orchestrator to set up complete using
- First, we’ll cover some important terminology of GitHub Action and define our branching & CI-CD strategy
- Second, we’ll set up continuous integration automatically run builds and tests using development workflow.
- And finally, we’ll set up continuous delivery so we can automatically publish to the Production orchestrator using production workflow.
- Some additional steps like slack notification
Alright, that was a lot.
Let’s get started!
Understanding GitHub Actions
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository or deploy merged pull requests to production.
Let’s look at various terminology used in GitHub action for automating your pipelines.
Core concepts Used in GitHub Action
- GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your self-hosted runners in your data centre or cloud infrastructure.
- To automate a set of tasks, you need to create workflows in your GitHub repository. GitHub looks for YAML files inside of the. github/workflows directory.
- Events like commits, the opening or closing of pull requests, or updates to the project’s wiki, trigger the start of a workflow. For example, a workflow is triggered when somebody pushes to the repository or when a pull request is created. Events can also be configured to listen to external events using Webhooks.
- Workflows are composed of jobs.
- Jobs are made up of multiple steps and run in an instance of the virtual environment. Jobs can run independently of each other or sequential if the current job depends on the previous job to be successful.
- A step can be a set of shell commands or an action, which is a pre-built, reusable step implemented
- Actions are the smallest portable building block of a workflow and can be combined as steps to create a job. You can create your Actions or use publicly shared Actions from the Marketplace.
If you have noticed the above description, you will see that it flows the YAML Markup language which is widely used in other CI/CD tools (Such as Azure) …
How to Set up GitHub Actions
GitHub Actions uses YAML syntax to define the workflow.
- Each workflow is stored as a separate YAML file in your code repository, in a directory called. github/workflows.
- You should be able to select a workflow from the ones available or create a new one. For this tutorial, we will create new.
- To create your workflow, create a .yml file in the path .github/workflows/action1.yml. Commit the file, GitHub will automatically understand that it is a workflow.
- For security’s sake, it’s important not to hard code secrets inside the codebase. A good way to avoid this is by using environment variables to refer to the secrets.
- Open your repository on GitHub and go to the Settings tab. On the left navigation bar, click Secrets.
- Here we can define any ORCH_URL, ORCH_TENANT, ORCH_CLIENT_ID, ORCH_USER_KEY, ORCH_ACC_NAME or ENV Specific Values.
Pretty easy right!
Let’s first understand the branching strategy and then we will create our workflow step by step.
GitHub Branching and CI/CD strategy [You can define as per need]
- GitHub repository with two branches ‘master’ and ‘develop’ to track the UiPath project.
- New ‘feature’ branch from develop branch (to perform changes)
- pull request against the develop branch on GitHub
- Two CI/CD pipelines (Separately for development and production using yml file configuration) to publish changes in the UiPath Orchestrator environment.
- Development pipeline will run when pull request successfully merged with develop branch.
- The production pipeline will run when the developed branch will be merged with the master branch.
The diagram below fully details this strategy:
Set up the GitHub repository for UiPath Project
- Go ahead and log into your GitHub account. Click on the + sign in the top right corner, then click on new repository:
- Let’s say – uipath-with-github-action (Name of Repository)
- At this point in the article, we assume that you understand how to manage different branches using git client or UiPath Studio.
- Next; Create a new project/or use the existing UiPath project and perform git init to initialize it locally
- Now we need to set up a remote repository so that it can be tracked remotely. This can be done using UiPath Studio using manage Remotes
- Give a Name – Say, Master
- URL – https://github.com/rpabotsworld/uipath-with-github-action.git
- The above will automatically create a master branch for you. Simply create a new branch called to develop with the following command using git client or UiPath Studio or “git checkout -b develop”
- Now, let’s go back to our project on GitHub-actions- UiPath and click on Settings > Secrets > New repository secret, as shown in the screenshot below:
- Now we’re done with our GitHub and local repo setup.
Set up GitHub Actions
- Create a folder at the root of the project named (.github). Inside (. github) , create a new folder called workflows. Inside the workflows folder, create a file named development.yml
- Similarly, create another workflow with name production.yml
- UiPath Don’t provide any native plugin for GitHub Action so we have used the unofficial library of DevOps PowerShell scripts. which allow us to package, deploy and run automation and tests. (See Link here – UiPath-DevOps-Scripts )
- The PowerShell scripts have a dependency on UiPath-dev – UiPath.CLI (Can be downloaded & set up via nuget/UiPath.CLI )
The overall structure of developement workflow
Understanding the development workflow file
- uses: actions/checkout@v2: For us to run our PowerShell, we need to have it available. This checks out our code on our job environment so we can use it to build, publish &test.
Production Workflow File
Understanding the production workflow file
- uses: actions/checkout@v2: For us to run our PowerShell, we need to have it available. This checks out our code on our job environment so we can use it to build, publish &test.
Summary
In this article, we’ve built a CI/CD process using Github actions.
We started by adding the CI process which runs the tests and tells our code reviewers that the Pull Request is ready for review.
There is so much more that can be done with GitHub actions. We hope this tutorial got you started with building a CI/CD process that is helpful and meaningful for your team.
References –
Hi all,
Have you tried to publish also Libraries?
If yes, could you help me with some info regarding what you changed in the yml ?
Thanks,
Cristi