Font Anti-Aliasing in PowerShell GUIs

Introduction

The text on winform projects may seem blocky sometimes, particularly at larger font sizes. It never seems to look as polished as those we see with Microsoft products.

Here’s a standard form using Segio 24pt in white. It’s pretty blocky, especially around letters such as ‘S’ and ‘P’. Click on the image below to see it in normal size to get an idea how this looks.

PowerShellStudioNormal

Text without Anti-Aliasing

In order to make our text smoother and more, anti-aliasing will need to be used.

What’s Anti-Aliasing?

Anti-aliasing is the name given to actions which aim to minimise this type of blockiness. It works by shading the pixels along the borders of an image. In order to achieve this for ourselves, we need to dig into some .NET methods and events.

This post shows how we do just that for our fonts in PowerShell Studio, but can be applied in whatever way you develop your GUI apps.

Create a Project

Create a new forms project, making the form a good size. Now, drag a PictureBox control onto the form, and set the size of it close to the size of the form itself.

Set the properties for the PictureBox as follows :

Dock = ‘Top’
BackColour = 1;3;86

Create Positioning Functions

Because we’re going to be working with graphics, we need to define placement based on a horizontal and vertical basis. Whilst we could use absolute positioning, where we manually specify a fixed location, this style is rendered invalid if we make changes to size of the control or the graphic itself. Its relative positioning is changed.

Instead, if we use calculations for positioning, it gives us the flexibility to change control and graphic sizes after the code has been written without having to modify it later.

Thinking about this, there are several things we need to do :

  • Get the midpoint of the control (our picture box)
  • Get the midpoint of the graphic (our drawn string)
  • Get the position for placement of the graphic on the control

Picture Box Control

In this function, we simply pass in the PictureBox control, and work out its center point by adding the left most point with its width, and then divide by two. This gives us the horizontal (aka x) location. Similarly, we add the control’s top most point with it’s height and divide by two to get its vertical center point. These values are then returned as an object.

Drawn String

We’re working in a similar manner to the above function, but require to do a bit more calculation. We pass in a graphics object, previously instantiated, the string to be drawn, and the font itself. The MeasureString method of the grahpics control is then invoked, using the other two parameters we’ve just mentioned. Once that is completed, we obtain the horizontal and vertical midpoints.

Position from Drawn String

Now that we have our two sets of midpoints, we can calculate where the drawn string should be placed. This is done by subtracting the result of the latter function from the former for both x and y positions, and returning the results.

Create Event Code

Now that we’ve defined out functions, we can setup the event action and code.

The Paint event occurs when a control requires repainting. This can happen as a result of other actions on a form or control, such as scrolling to the bottom of a form at to the top again.
Go to the Paint event of the PictureBox in the properties panel, and double click on it. Insert the following :

Code explanation

What happens in this code is the following:

  • We obtain the Graphics properties from the event data and assigning it to a variable $g.
  • We define some of the properties of the picturebox control.
  • A Font type variable is created using Sergoe UI typeface in size 84 as the supplied parameters
  • A SoldBrush object is created. This is the drawing style we use, just like in the Paint application.
  • The functions mentioned previously are then used
  • With the above completed, we define a floating point coordinate object
  • We also set the type of anti-alias rendering to be carried out. Several options are available. See the links at the bottom of this page to get more information on these
  • We now run the DrawString method to create and position the anti aliased rendering of the font.

View the New Results

Now run the project to see a much smoother version.

PowerShellStudioAntiAliased

Text with Anti-Aliasing

I’d recommend taking a look at the System.Drawing namespaces documentation on MSDN to get more information on the methods, properties, and enumerations used in this code, which will explain in more detail about each.

You can find the Project code and exported code (for those not using PSStudio) at my GitHub repository, and also a video of this in action on my YouTube channel.

cheers,

Tim

Logging Functions

Here’s a collection of logging functions I came across that I’ve found quite useful.

Write-Log takes the string to be written, along with $logfile, $consoleoutput, and an $iserror switch. The time is identified. The message is then added to it, prepended with ERROR : if the iserror switch is passed.


Set-ConsoleOutput
simply configures a script level variable. We use this variable to decide whether information logged to file is also output to the screen at the same time.

Start-Log begins the process of creating a file. If a file already exists, the overwrite parameter will determine what is done with this current file. When this is identified, the script level variable, $logfile is set.

Stop-Log sets the value of the above script variable to null, which will result in an error the if we still attempt to use Write-Log

Get-Log returns the current value of the script level logfile variable

A very simple example of its use would be :

Output wise, we then can get something like this :

[2015-12-31 14:22:53] Begun executing myfile.ps1
[2015-12-31 14:22:53] Configuring provisioning account
[2015-12-31 14:22:53] Provisioning account credentials configured
[2015-12-31 14:22:53] Creating secure string password
[2015-12-31 14:22:53] Credential object created
[2015-12-31 14:22:57] Azure Active Directory parameter is not set
[2015-12-31 14:22:57] RDWEB URL is set to https://rdweb.contoso.local
[2015-12-31 14:22:57] Multitenancy is not enabled
[2015-12-31 14:22:57] Email subject is Provisioning setup
[2015-12-31 14:22:58] Text body configured as HTML
[2015-12-31 14:22:53] Execution of myfile.ps1 is complete

Using .NET Event Handlers in a PowerShell GUI

GUI development tools, such as PowerShellStudio, make it very easy to manage events for controls on our winforms.

Once the control is on the form, and we select it, click on the Events button (the lightning symbol), the Properties panel gives us a list of the events available for us to manage. However, events are not just restricted to controls. There’s a world of other events out there that we can use to interact with our winforms projects.

In this article, we’ll create a forms project that downloads the latest 64 bit antimalware definitions from Microsoft and updates a progress control to show how far the download is to completion, using methods and events from a .NET class.

Updates to the latest antimalware definitions can be obtained through http://go.microsoft.com/fwlink/?LinkID=87341&clcid=0x409 and a look through MSDN shows us that we can use the .NET WebClient class to carry out downloads programmatically.

To start this process, create a new forms project, and drag a progress bar, label, and button onto the form. Then set the properties of the controls as below. Note that properties with text controls will automatically be named for you if you set the text property first.

Label
Text : Progress
Name : labelProgress

Button
Text : Download
Name : buttonDownload

Progress Bar
Name : progressbarDownload

Here’s how my form looks.

Blog - Adding Events - Form Design

Once this is complete, we can begin writing the event code.

In our forms Load event, we create an instance of the System.Net.Webclient class. This is assigned to the script level variable, $webclient. This scope is required in order for the other parts of the solution to be able to process the object and its events.

The next two lines add event handlers for the DownloadProgressChanged and DownloadFileCompleted events. DownloadProgressChanged indicates a change in the state of the transfer with regards to the amount of content downloaded, whilst DownloadFileCompleted is fired on the completion of a download. The scriptblocks for these are $webclient_DownloadProgressChanged and $webclient_DownloadFileCompleted respectively.

The event handler for updating the progress of the download is written next:

To make it easier to read, $progressInfo is used for the rest of the code instead of $_. The variable contains the values given to us by the System.Net.DownloadProgressChangedEventArgs class instance that is passed into the handler.

The DownloadProgressChangedEventArgs class contains ProgressPercentage, BytesReceived, and TotalBytesToReceive properties. We use these for changing the progress meter value property, and also updating the text in the label below to show bytes received and the total size of the download.

The event handler for DownLoadFileCompleted is next:

When DownloadFileCompleted is fired, the label text is changed to indicate the download’s completion.

Lastly, the download button’s Click event is set to begin an asynchronous download of the antimalware definition.

Blog - Adding Events - Code

Our project code

And when we run the project and click on Download! We see this in action, with the progress bar being updated and the progress text below it also, using the code we wrote earlier.

Blog - Adding Events - Downloader Running

The downloader in action

This same methodology can be employed for using .NET events, creating an instance of the object, adding the event handler definition, and then the scriptblock code to be used.

You can find exported project code and the project files at my repository on GitHub, and a short video of the project in action on the powershell.amsterdam YouTube channel.

 

Copying files to and from remote sessions

Those of you running Windows 10 or Server vNext (I’ve yet check WMF 5.0 RTM on other operating systems after it was pulled by Microsoft from DownloadCenter), may have missed the inclusion of new parameters for Copy-Item, which allow to copying of files to a remote session and from a remote session. These are names ToSession and FromSession respectively.

Oddly, Microsoft do not appear to have updated their help to provide information on this. You’ll only notice it if you use Get-Command or alternatively tab through Copy-Item.

What’s nice is that PowerShell 5 is not required to be installed on the system for which we have created a remote session.

Usage is simply a case of providing a valid value of PSSession type to the ToSession or FromSession parameters, in addition to your standard Path and Destination parameters.

Examples are below :

Copy Remote Sessions

Unfortunately at present, FromSession and ToSession are mutually exclusive, preventing the possibility of being able to directly copy from one remote session to another.

Removing Items from Lists Using the Keyboard

In an earlier post, we created a form with two listgridview controls, and used both add and remove buttons, and double click functionality to allow an item to move an item from one control to another in an intuitive manner.

Todays post shows how we can use a remove items from a list by pressing a key. Specifically, we’ll be using the DELETE key for removing items. This will be carried out in Sapien’s PowerShell Studio 2015, but the same methodology applies to however you generate winforms in PowerShell.

For initial setup, carry out the following :

  • create a new form with a header and several items.
  • create a listview control called $lstControl
  • populate the control with a header
  • add some items to the listview control

Sample form and control layout

 

  • select the control
  • select Events in the properties pane
  • double click on KeyDown
  • Insert the following code :

The KeyDown event’s code

 

Go ahead and test it, adding an item to the control on the right hand side, selecting it, and then pressing the DELETE key.

Also, because the code loops through each selected item in the control, we can also use standard multiple selection functionality offered by the various use of the SHIFT and CTRL combinations.

Two items are selected using a click SHIFT combination

The DELETe key is pressed, and the previous selected items are removed from the list

You can find the files, if you are using PowerShell Studio 2015, or exported .ps1 file at my gitlab repository.

Additionally, there’s a (basic) video of this code in action at my channel on You Tube.

Thanks for reading, and feel free to provide feedback.

cheers,

Tim

Using Double Click for Adding and Removing Items from Lists

Double click functionality for movement of items between listboxes is commonly used within Windows, and quite intuitive. This article shows how we can implement this in our own forms based projects. We’ll use this example with ListView, but it is also applicable to ListBoxes (ListView controls inherit from ListBoxes).

For initial setup of this project, follow the steps below, using your preferred GUI editor or code.

  • Create a new forms project
  • Change the form’s control name and text if desired (called AddServers and Double Click Demo in this article)
  • Add two ListView controls, with names of lstFrom, and lstTo
  • Add two Button controls, with names of btnAdd, and btnRemove
  • (optional) Set the Text property of the form

lstFrom

  • Add a column to the form
    • Name : columnComputernameFrom
    • Sorting : Ascending
    • Text : Computername
    • View : Details
    • Add the following items to lstFrom , with Text values of Computer1, Computer2, Computer3, and Computer4

lstTo

  • Add a column to the form
    • Name : columnComputernameFrom
    • Text : Computername
    • View : Details
    • Sorting : Ascending

Buttons
Set the name of the top button to btnAdd, and the Text property to >
Set the name of the bottom button to btnRemove, and the Text property to <

Arrange the controls to look something like the picture below :

Our form design

Our form design

Once this is complete, we’re going to start adding some features.

Add/Remove Buttons

This could be described as the ‘classic’ method of adding and removing items from lists, with arrows pointing in alternative directions to indicate the addition or removal of an item from one listbox to another.

In the Load event, we’ll set the arrow buttons Enabled property to $false, since no items are selected.

Let’s activate or deactive the add and remove buttons depending on whether the appropriate listboxes are populated, and additionally disable the appropriate button when an item is selected. There’s no point of the add button being enabled when we have selected an item from the To listgridview for example.

Now we add the code for the button events, adding to removing from the appropriate listgridview. We use the FindItemWithText method to verify that the item does not already exist there, preventing duplications.

Now go ahead and run it. Select double click on an item on the left hand column, and it will add it to the right one, and versa.

Double Click - Running 1

Double click on one of the items

Double Click - Running 2

…..and it is moved to the other side

 

The mechanisms that double click provides for list also be used on other controls. For example, double clicking on an item in a list which automatically populates a textbox with the value that has been selected in the list.

You can find a copy of the PowerShell Studio .psf form file, and also an exported .ps1 of the same for at my repository on GitHub.

A video of this is also available on the PowerShell.Amsterdam YouTube channel.

Thanks for reading, and please provide feedback if you have comments, questions, or have noticed any errors in this article.

cheers,

Tim

PowerShell and GitLab CI – Part 5

Introduction

During the last article in this series on the use of PowerShell with GitLab, we noticed some displays on the build console, and some results from our build that was a bit unusual.

Today, I’m going to look a bit further into how the build engine works, which will also explain some of these results we are seeing.

How GitLab CI Runner Works

It would be logical to think that the PowerShell code is run in the same location or a subdirectory of the folder where the service file is, similar to Jenkins, but after a bit of investigation, I found out this is not the case.

To look further into what was happening, let’s add a line to the script section of the YAML file, and put a Start-Sleep command in.Make it ten minutes, to give enough time to remote onto the GitLab CI Runner, and do a search for our .ps1 file stored in a subdirectory of the repository.

Use the content below for our build file.

  • Save the changes
  • Add the updated file
  • Commit the changes
  • Push the changes
  • Navigate to the build section
  • Click on the commit

The job is running, and because of the Start-Sleep command, will continue to do so for the next ten minutes.

Part 5 - GitLab Job Running

Discoveries

  • Remote onto your build server (if it is not already the same system you are accessing GitLab from.
  • Go to the C:\Windows\Temp

There will be a folder name of the format Build_xxxxPart 5 - Temp Dir

  • Double click on the folder

Part 5 - Build Script Contents Dir

  • Within this folder is a script.ps1 file.
  • Open the file

Part 5 - The Script Code

The PowerShell code contained within the script: section of the YAML file is adjusted to make it suitable for returning the output we can see on the console window within a Gitlab job.

Looking at the code now, we can see that it has been changed significantly :

  • ErrorActionPreference has been set to ‘Stop‘.
  • Commands are in place to check to see if an error has occured, and if so to exit the script.  This will also result in the job being flagged as having failed.
  • Probably the most interesting of the changes is the frequent use of Echo command which mimics the command that follows it.

This explains several things to us :

  • How the console output is seen on the job screen
  • Some lines output appeared strange because variables were undefined at the stage when the Echo command ran

Because PowerShell returns all output from a function, it explains why were receive an array when the HappyHelloWorld function is called. It consists of the intented output, but also the Echo commands.

The use of a function in our build code now becomes a challenge or possibly could be perceived as something to be avoided, since we cannot guarantee the element in the array that will contain our desired output.  One way i’ve been able to get round this is to make the function return a PScustomobject, and make use of the -is operator outside of the function to obtain the value.

e.g. $functionOutput = $arrayReturned | Where {$PSItem -is [pscustomobject]}

However, I’ve found a better approach is to minimize the actual PowerShell commands that you use in the script, and instead create a Build folder within your repository which contains files with the actual commands that you wish to use for the build. These can be dotsourced to make them available from within the script, without the need for adding custom code to handle this.

There are many other aspects and configuration settings possible within GitLab, which lets you have powerful control over your build steps. Examples of this are defining the order of execution, ignoring errors, and setting the steps to be taken after each one.

It’s also worthwhile noting that these articles do not include the use of testing, which should be part of your chain of operations. If you are not already familiar with the use of Pester, I’d recommend taking a look at the documentation and examples on GitLab. Amongst others, Jakub Jareš has also written an excellent series of articles on its use, which you can find on PowerShellMagazine.com

That’s it for this series of articles on the use of PowerShell and GitLab. Thanks for reading, and feel free to provide feedback.

cheers,

Tim

PowerShell and GitLab CI – Part 4

Part 3 of this series on using PowerShell and GitLab CI gave us an initial insight into how to setup and run PowerShell code as part of a build script. During it, we were introduced to the YAML build file, .gitlab-ci.yml.

This article, and the following one will cover some of the gotchas I’ve encountered whilst getting to grips with this file, and how to get these working as you’d expect. Hopefully these will help save you some time setting these up.It will also touch on some oddities you might experience creating build scripts.

Overview

At this point, I’m going to continue to use the same project with the same job name, even though it will deviate from the original script we created earlier. This is to allow us to go through the situations I’ll mention slightly faster, and I’ll indicate for each example what the subject is about. Let’s begin!

Keep Things in Line

The YAML specification demands a bit extra attention to formatting of your build scripts. Keep your ‘-‘ and labels in line.

Fails

gitlab commit 1

Succeeds

gitlab commit 2

Don’t use the TAB character

Unless you are using an editor which automatically translate the use of the TAB key into spaces, your scripts will fail. Use normal spaces.

Fails

The script below, whilst appearing indentical to the one that succeeds, uses table characters for indentation.

gitlab commit 3

Succeeds

gitlab commit 4

Watch Out For ScriptBlocks

The formatting for the use of a scriptblock can sometimes be a bit confusing. The final brace that closes the scriptblock should not have a ‘-‘ prefixing it. Additionally, if there is only one line of code within the scriptblock, it is not neccessary to use this prefix (but see below)

Fails

gitlab commit 5

Succeeds

gitlab commit 6
And if we actually look a the build output, we will see the details.
You might be quite correctly thinking that something looks a bit unusual with the output. This will be covered shortly……..

gitlab commit 7

And a look at helloworld.txt to make sure it has worked correctly.
gitlab commit 8

You Must Use ‘-‘ For Any Code Within Braces If It Consists of More Than One Line

If you have any code that surrounds itself in braces, such as a scripblock, function, or reiteration action, it will execute successfully without using the ‘-‘ character if there is only one line. However, two or more lines of code will fail.

Fails

Succeeds

It is probably best to start using ‘-‘ even with one single line within braces.

The script works, but the output on the screen is even stranger!
gitlab commit13

But the results are good….
gitlab commit14

Watch for error handling

Watch your syntax if you are wanting to use a Try..Catch block
Also, code within

Fails

gitlab commit18

Succeeds

gitlab commit19

So the script has successfully executed. Again, the output on the screen is a bit strange, but let’s check the helloworld.txt file out.

gitlab commit20

However, the file itself has not been created, despite the fact that we know this should raise a division by zero error, which should mean the catch scriptblock is executed.

Functions Behave Differently Than You Would Expect

This final part is the greatest challenge i’ve come across so far, and deserves a bit extra detail. It will also be covered further in the next article in this series.

Let’s modify the build script more. Here’s the PowerShell we’re going to use :

Here, we’ve modified our build script by adding a function which returns a string, and then output it to the same text file we’ve been using previously. If you want, you can verify the PowerShell code in the ISE, and also that the helloworld.txt file has been successfully created.

This would be put into our build script like this :

And it builds successfully
gitlab commit15

So let’s take a look at helloworld.txt
gitlab commit16

This is strange!!! There is other items there that shouldn’t be. In fact, only the last line of the file should be there.

Let’s do a bit of detective work and see if we can get more information about what’s being returned. A good starting place would be to see if we are getting a multiline string or an array returned.

So let’s take a look at helloworld.txt
gitlab commit17

This is real strange, an array is being returned. But we know that only a string is returned from the function. In the next article, we’ll dig deeper into what’s actually happening during the build process, which will shed some light on some of the strange things we’ve been noticing. Then we’ll also take a look at Lint, and how we can use it carry out checking of our YAML files.

PowerShell and GitLab CI – Part 3

In part 1, and part 2 of this series, we covered the installation and configuration of pre-requistites, setting up our GitLab account and initial settings, and finally getting our Windows Runner installed and operational.

Today’s, I’ll give an overview of how GitLab uses build configuration files, how it is constructed, and setup our project in preparation for getting our first build complete.

GitLab Build Conifiguration

Previously, I’d been using Jenkin’s for my CI system, and immediately noticed how build configuration is different. With GitLab CI, the build file itself, .gitlab-ci.yml, is actually part of the repository. No webhook setup is necessary.

We also now have capabilities, such as not only having a dedicated runner per project, but per branch of our project, which we can control and manage directly from our repo.

Create a Demo PowerShell Script

Let’s setup a really simple script which we want to pass through the CI Engine.

  • Log back into the GitLab environment
  • Open your project

git - part 4 - 1 - login to git

Now launch the PowerShell ISE, and make the following script:

Save the file as HelloWorld.ps1 into the root of your repository (C:\temp\helloworld in my case)

Commit and Push to GitLab

We’ve added content to the repository, so lets go ahead and push the changes to GitLab.

  • Start a Bash session
  • Set your current current directory to the root of your repository
  • Enter the commands below

git - part 4 - 3 - pushing our changes

Now return to GitLab, and select Commits to confirm the commit has occurred.

Results

To the right of the commit, you will see a red ‘x’ mark. You might think that this is an options to delete the commit that has been made, but it’s something else entirely.

git - part 4 - gitlab commit screen

Click on the red cross. Looking further down the screen we see an error message.

Found errors in your .gitlab-ci.yml:
Undefined yaml error
.gitlab-ci.yml not found in this commit

git - part 5 - gitlab commit and build details screen

As mentioned, .gitlab-ci.yml is the build file that stored within the repository itself. The commit has been successfully placed into source control, but because we enabled CI for this project, GitLab has also expected the build file to exist.

A Quick bit About YAML and gitlab-ci.yml

We’re now at the stage where we are wanting to design our build configuration file for the helloworld project.

Build actions for GitLab projects are stored within a file, .gitlab-ci.yml, which is placed in the root of a repository. This file uses YAML format, and describes the build actions and criteria. Those of you familiar with AppVeyor may be aware of this format of file, and the requirements it has to be successfully parsed.

You can read more about YAML on WikiPedia, and other sources.

As a newbie I struggled with this file, and it took me a whole day before I was able to get a successful build to occur (though it wasn’t helped by my build script being quite longer than our example). I’ll cover this file in a bit more detail, and the gotchas I’ve come across in a later blog. But for now, we’ll make a basic build file.

Building our gitlab-ci.yml file

Launch Notepad, and paste the following text into it:

Our configuration file consists of a label at the top, which identifies the name of the build, the script to be executed, and uses a tag of ‘Windows’ to identify the Runner to be used.

You might be wondering why I placed :

in the build script instead of directly into the PowerShell script. The reason for this is simply to demonstrate how we can actually use PowerShell within our build script, and not just call PowerShell scripts.

  • Save the file as .gitlab-ci.yml within the repository, and return to Bash.
  • Add, commmit, and push this file to GitLab.

Results

Let’s take a look at the status of this build from GitLab. What’s particularly interesting here is that the actual command within the the script section of the build file is displayed. More about that later….

successfulbuild

So our build has reported as being successfully, and if we take a look at C:\Windows\Temp on our build server, the file is there. Our first experience with GitLab CI is complete! 🙂

helloworldfile

Coming Soon….

The next article in the series will cover some difficulties i’ve had getting to grips with GitLab CI, and how I was able to go from this :

builds

To :

success

Thanks for reading. Comments, errors and any feedback always welcome.

cheers,

Tim

PowerShell and GitLab CI – Part 2

Setting up a Windows GitLab Runner

Part 1 of this series on PowerShell and GitLab CI saw us setup our GIT client configuration, register and configure GitLab for our sample project, and then perform an initial clone of the project just created.

Todays blog covers the setup of a Gitlab Runner.

What is a GitLab Runner?

Quite simply, a GitLab Runner is an application which processes builds. On a Windows system, a GitLab Runner operates as a dedicated service.  Because it communicates with GitLab CI through an API, there is no requirement to have the Runner on the same server on which you have GitLab CI installed.  Runners can be setup on various operating systems, and additionally process multiple languages.

GitLab CI can use one or more Runners. This makes it not only handy when we are working in a heterogenuous environment, but also where we wish designated severs for our development, testing, acceptance, and production arenas.

Runners can be assigned per project, which gives us further flexibility. I find this very helpful, working in an environment with multiple untrusted forests. All I need to do is register a Runner in the respective forest, and then assign it to a project for that.

Preparation

Before we download and install the Windows Runner software, we need to get an identifier from GitLab. This will be used to associate a runner with a project.

  • Log back into GitLab
  • Click {yourname} / helloworld
  • Click Runners on the left hand pane
  • Copy the registration token in section 3 of How to setup a new project specific runner into the clipboard.

git3 - part 1

git3 - part 2

Installing and Configuring the Runner

Now we’ll actually get the runner operational on our build server.

  • Move gitlab-ci-multi-runner-windowsd-amd64.exe to a suitable directory. Note that this will be the directory from which the service runs. As this is a demo, I am going to place it in the Temp folder of my C: drive.

git3 - part 3

  • Start PowerShell as an administrator
  • Use Set-Location to set the current directory to the location of the file mentioned above
  • Use the command below to launch the configuration utility

You’ll now be prompted for input some information

  • coordinator URL : https://ci.gitlab.com
  • token : <paste the registration token you copied to the clipboard>
  • description : hellowworldrunner
  • tags : windows
  • executor : shell

Coordinator URL refers to the location that the runner looks to for communication with GitLabCI, Token the unique identifier that is used to identify your runner. Tags allow you to control when a job does or doesn’t build on a runner, and the executor refers to the type of script it will process.

  • If you are prompted for your current password, enter this as well.

git3 - part 4

  • Launch services
  • Find the service with the name of gitlab-runner

git3 - part 5

Note is the service is registered to run in the current context of your account.

Unless you have any specific need to keep the gitlab-runner service running in this context, carry out the following:

  • Stop the service
  • Change the Log On as: setting to the account you want it to run under. (In my case, I just set it to Local System Account.)
  • Start the service

git3 - part 6

That’s the Runner setup, and ready to be used, but first took a look at the location where the process runs from.

You should see a file there new called config.toml. This file contains the configuration settings that the Runner uses. It’s plain text, so you can open it in Notepad. It details the number of concurrent runners, the url of the gitlab cim, the token we used earlier for registration, name of the runnier, and other configuration data.

Now return to GitLab, and the Runners section we were just on, and press F5 to refresh the screen.

The helloworld runner should now be registered for this project!

git3 - part 7

In part 3 of this series, we’ll create our first GitLab CI build file, which will run a basic PowerShell script.