Intro
ServiceNow Studio provides an Integrated Development Environment (IDE)-like interface for application developers to work on custom applications in one centralised location, offering a simple way to create, review, and update application files from a tabbed environment.
ServiceNow Studio also enables application developers to integrate with a Git Source Control repository. This allows to save and manage multiple versions of an application from a non-production instance.
Linking an application to Source Control enables all application developers on a non-production instance to:
- Import applications from a Git repository.
- Pull and apply remote changes from a Git repository.
- Commit all local modifications on the instance to a Git repository.
- Create tags to link to a given version of an application permanently.
- Create branches to maintain multiple versions of an application simultaneously.
This article, we will analyse a specific behaviour observed while linking a ServiceNow scoped application with a GitLab account that seems not documented in ServiceNow’s current documentation.
Linking ServiceNow with a GitLab Repository
Linking an application in ServiceNow to source control allows application developers to manage changes from a Git repository. This is an operation that can be executed by system administrator and requires a certain amount of preparation. As a first thing, it is necessary to set a git account and create a dedicated Git repository for the application. In GitLab it will be enough to create a brand new project.
Creating a new project is easy.
From the GitLab home page click the 'New Project' button.
In the 'Create new project' page, GitLab is going to show four options.
Click on 'Create blank Project' to finally open the creation form.
Complete the task providing a name for your project and then clicking on the 'Create Project' button.
Your project is now ready to be used and will show the default branch.
If you inspect the branch you are going to discover something unusual.
The branch is not named 'master' but 'main'.
Master vs Main.
Historically speaking, the default branch used by Git DVCS tool's was set to master. Every Git repository had a master branch unless a developer took explicit steps to remove it. This type of action was rarely executed because the master branch plays an integral role in the software development world.
For most projects, the master branch represents the source of truth, all the code that works.
On the other hand, this original term has been replaced in favour of the more inclusive and friendly 'main' a few years ago. Both GitLab and GitHub took action to include the new naming convention, as shown in the previous screenshot.
Linking your app with the GitLab project. A small side effect.
Now that your GitLab project is ready, you can link your ServiceNow app and transfer everything you have done to the repository. In my case, I created in advance a simple custom application named 'dummy' and included my GitLab account credentials in a developer instance.
Following the usual process, I opened my applications in ServiceNow studio and then navigated to 'Source Control > Link to Source Control'.
Studio displayed the 'Link to Source Control' dialogue box asking for the project URL and the proper credentials to connect with the repository. Automatically, the system suggests a name for the actual branch used in the Git repository.
The branch name defaulted in the field doesn't show any reference to the actual app we want to deploy in the repo. Only the instance name is visible. In practice, it is a developer’s choice to decide on a naming convention for your branches that highlight that type of detail.
Another possible option is to reference the actual 'main' branch available in GitLab automatically generated during the creation of the project. You need to replace the existing text in the branch field, as visible in the following snapshot.
If we open the freshly connected application in ServiceNow studio and navigate to '
If we try to switch into this mysterious branch, we get an error message.
The error message shows that the extra branch in the repository is empty and does not include the files that ServiceNow usually requires to execute the branch switch.
If we jump back in GitLab, the new branch is visible.
ServiceNow started following the historical approach of creating a 'master' branch but then didn't update the platform to be aligned with the new standard followed by GitLab or GitHub.
Unfortunately, every time you create a new app, you will end with one unusable empty branch.
The only way to avoid this issue is to delete the extra branch from the repository or merge the empty branch into the one that contains the data.
Cheers
R0b0
Kudos to Mr
