DEV Community: Rob

December ProductTalk on Continuous Interviewing

Rob — Thu, 12 Dec 2024 15:31:33 +0000

This article provides a brief summary of a webinar on the topic of continuous interviewing hosted by Teresa Torres from Product Talk on on 4th December 2024.

Continuous interviewing is a part of the continuous discovery framework and is a commitment to weekly touch points with customers to conduct research in purist of a product outcome. Talking to customers is naturally a big part of this. Teresa has also published a book on the topic.

With continuous discovery there is an emphasis on being outcome first, with cross-functional products teams maintaining at least two research activities to discover opportunities. Opportunities are defined as a customer need, pain-point or desire where solutions provide both business and customer value.

During this process people make the mistake of using customer interviews as a way to validate solutions or confirm factual behaviours. This is not good practice for discovery. Showing customers a solution and asking what they think invites speculation. One also needs to avoid theoretical questions or scenarios as it invites customers to provide an idealised answer.

Teresa points out that the sale of gym memberships is largely based on people's false idealised notion of themselves.

Don't conduct interviews to ask questions that data can tell you.

Equally, asking theoretical questions triggers people to activate their system 1 thinking, which is reactionary, efficient and fast but also inaccurate, speculative, bias and prone to error. Instead we want to activate system 2 thinking, which forces our customers to concisely think through their response.

So how do we trigger system 2 thinking? Well avoid ...

Direct questions leading to short answers.
Leading questions creating false choices.
Questions about the future giving unreliable responses.
Questions that trigger speculation.

We want to use our interviews to understand the customers goals with as much context as possible to highlight opportunities for us to pursue.

Teresa advised the best way to trigger system 2 thinking is to ask questions grounded in specific instances of past behaviours, to force them to use their memory. For example, rather than asking ...

What is your experience watching Netflix?

ask ...

Tell me about your last experience watching Netflix?

instead of asking ...

What are your favourite types of Movies?

ask ...

What were the last 3 movies you watched?

You can then build a rich story by expanding questions from there. The interviewee is now replying on memory rather than speculating on a theoretical, which is forcing longer more thoughtful replies.

Follow up with ...

Tell me about the time before that?

Do you recall why you watched it?

Do you remember facing any challenges or inconvenience?

How did you decide to pick that movie?

Do you remember how you heard of it?

These questions lead to collecting a story rather than facts. The work of the interviewer is to help the interviewee excavate a story, gently and interactively, we want to get them back to the thinking and emotion of their past decision making.

Active listening can also present a challenge, as interviewees often flip-flop between specifics and generalisations.

Follow up links referenced
• Opportunity solution trees
• Assumption testing
• Interview snapshots
• The Mom test

F# Http Request

Rob — Wed, 17 Aug 2022 12:14:00 +0000

The purpose of this article is to give you an example of making a HTTP request in F# wrapped in a try-catch with a cancellation token.

The example was built in a console application using .NET 6 and requires the below packages

Newtonsoft.Json/13.0.1

It also makes use of the free to use API placeholder service JSONPlaceholder.

Paste the below code into your Program.fs and execute.

open System
open System.Net
open System.Net.Http
open System.Threading
open System.Threading.Tasks
open Newtonsoft.Json

type Post =
    { userId: int
      id: int
      title: string
      body: string }

let DeserializePost (response: string) : Post =
    JsonConvert.DeserializeObject<Post>(response)

let GetItem
    (client: HttpClient)
    (message: HttpRequestMessage)
    (ct: CancellationToken) : Task<option<Post>> =    

    task {        
        try
            let! response = client.SendAsync(message, ct)
            if response.StatusCode = HttpStatusCode.OK then
                let! payload = response.Content.ReadAsStringAsync()
                return Some (DeserializePost payload)
            else
                return None
        with
        | :? TaskCanceledException as ex -> printfn $"Task Canceled Exception: {ex.Message}"
                                            return None
        | :? TimeoutException as ex -> printfn $"Timeout Exception: {ex.Message}"
                                       return None
        | ex -> printfn $"General Exception: {ex.Message}"
                return None
    }

let main =    
    //GET
    task {
        let client = new HttpClient()
        let tokenSource = new CancellationTokenSource(3000)
        let token = tokenSource.Token      
        let getMessage = new HttpRequestMessage(HttpMethod.Get, "https://jsonplaceholder.typicode.com/posts/1")

        let! item = GetItem client getMessage token
        printfn $"{item}"
    }

main.Wait()

Output

Some({ userId = 1
  id = 1
  title =
   "sunt aut facere repellat provident occaecati excepturi optio reprehenderit"
  body =
   "quia et suscipit
suscipit recusandae consequuntur expedita et cum
reprehenderit molestiae ut ut quas totam
nostrum rerum est autem sunt rem eveniet architecto" })

Further Readings

Making F# HTTP calls using either System.Net.Http, Http.Fs or Flurl -> here
Configuring Serilog into F# -> Here

F# : using List.exists on record types may cause breaking changes

Rob — Thu, 28 Jul 2022 10:49:00 +0000

Below are two examples of how you can determine if an expression returns true for a given list.

Example 1 uses List.exists as per the Microsoft documentation and passes the expression and list as the second parameter

Example 2 uses a pipe to pass List.exist an explicit type of list as per the fsharp.org documentation

type Person = { name: string }
type Fox = { name: string }

let itemExists =

    let people : Person list = [{ name = "Robert" }]

    //This won't compile: Type mismatch
    let example1 : bool = List.exists (fun i -> i.name = "X") people

    //This will compile
    let example2 : bool = people |> List.exists (fun i -> i.name = "X")
    0

The Problem

The problem here is that for example1 the order of the record types matter and in its above state will not compile with a type mismatch.

The lambda is implicitly determining the type of i based on name. But name is shared by both type Person and type Fox. It therefore takes the first matching type in the file or namespace from the BOTTOM. In this case i is of type Fox and is incompatible with the passed person list.

Where this becomes dangerous is when your types are spread out through the application or even in a separate library. If a new record type is added with the same property name and type it will result in your consuming application breaking if it were to take the update.

Manipulating Collections in F# - Basic Examples

Rob — Fri, 22 Jul 2022 09:18:00 +0000

This article is to provide you with some basic examples of collection manipulation in F# run from a console application in .NET 6. The examples are drawn heavily from a series of exercises in Stylish F# 6: Crafting Elegant Functional Code for .NET 6, 2nd Edition, 2021 by Kit Eason.

In order to run the examples you will need to add some initial utility functions and types to the top of your program.fs file.

type Car =
    { Model : string
      Price : decimal }

type PriceBand = | Cheap | Medium | Expensive

module FakeData =

    let private random = System.Random(Seed = 1)

    /// Make an array of 'count' number of random houses.
    let getRandomArrayOfCars (count: int) =
        Array.init count (fun i ->
            { Model = $"Model %i{i+1}"
              Price = random.Next(10_000, 150_000) |> decimal })

    /// Try to get the distance to the nearest garage.
    /// While the 'Car' parameter is not used we add it to change the signature
    /// Allowing us to pipe into it later with a Car object
    let tryGetDistanceToGarage (car: Car) =
        let dist = random.Next(30) |> double
        if dist < 20 then
            Some dist
        else
            None

    // Return a price band based on price.
    let getPriceCategory (price : decimal) =        
        if price < 40_000m then
            Cheap
        elif price < 100_000m then
            Medium
        else
            Expensive            

module Array =
    let inline tryAverageBy f (a : 'T[]) =
        if a.Length = 0 then
            None
        else
            let average = a |> Array.averageBy f |> decimal
            System.Math.Round(average, 2) |> Some

Then you can add the below examples and execute them with dotnet run.

// Transforming Data Items
let getCarListing =
    printfn "\n------ TRANSFORMING DATA ------" 
    FakeData.getRandomArrayOfCars 3
    |> Array.map (fun h ->
        printfn $"Model: {h.Model} - Price: {h.Price}")

// Calculating an Average
let getAverageCarPrice =
    printfn "\n-------- AVERAGE PRICE --------"
    let price = FakeData.getRandomArrayOfCars 10
                |> Array.averageBy (fun c -> c.Price)
    printfn $"Average price: {price}"

// Selecting Based on Condition, Order and iteration
let getExpensiveCars =
    printfn "\n------- EXPENSIVE CARS --------"
    FakeData.getRandomArrayOfCars 10
    |> Array.filter (fun c -> c.Price > 100_000m)
    |> Array.sortByDescending (fun c -> c.Price)
    |> Array.iter (fun c ->
        printfn $"Model: {c.Model} - Price: {c.Price}")

// Finding a Single Element
let getCarWithDistanceToGarage =
    printfn "\n- CAR WITH DISTANCE TO GARAGE -"
    let result = FakeData.getRandomArrayOfCars 1
                 |> Array.tryPick (fun c ->
                    match c |> FakeData.tryGetDistanceToGarage with
                    | Some d -> Some(c, d)
                    | None -> None)
    printfn $"{result}"

let getCarsByPriceCategory =
    printfn "\n--- CAR WITH PRICE CATEGORY ---"
    let result = FakeData.getRandomArrayOfCars 6
                 |> Array.groupBy (fun c -> c.Price |> FakeData.getPriceCategory)
                 |> Array.map (fun group ->
                    let category, cars = group
                    category, cars |> Array.sortBy (fun c -> c.Price))
    printfn $"{result[0]}"

let tryGetAverageCarPriceOver100K =
    printfn "\n--- AVERAGE PRICE OVER 100K ---"
    let result = FakeData.getRandomArrayOfCars 20
                 |> Array.filter (fun h -> h.Price > 100_000m)
                 |> Array.tryAverageBy (fun h -> h.Price)         
    printfn $"{result}"

Output

------ TRANSFORMING DATA ------
Model: Model 1 - Price: 44813
Model: Model 2 - Price: 25504
Model: Model 3 - Price: 75381

-------- AVERAGE PRICE --------
Average price: 73004.4

------- EXPENSIVE CARS --------
Model: Model 1 - Price: 148567
Model: Model 8 - Price: 142968
Model: Model 6 - Price: 108595
Model: Model 7 - Price: 108251
Model: Model 2 - Price: 105497
Model: Model 3 - Price: 101684

- CAR WITH DISTANCE TO GARAGE -
Some(({ Model = "Model 1"
  Price = 63475M }, 15))

--- CAR WITH PRICE CATEGORY ---
(Cheap, Program+Car[])

--- AVERAGE PRICE OVER 100K ---
Some(120609.44)

F# Convert a List of Type A to Type B with options

Rob — Thu, 21 Jul 2022 16:42:43 +0000

The purpose of this article is a small demonstration of how one can convert a list of one type to another type in F#. While 'Convert' is used in the header, this is really using the 'map' function and returning an entirely new list.

The below code was written in a console application in .NET 6

type Person = {
    name: string    
}

type Employee = {
    email: string
}

let ConvertPersonToEmployee
    (person: Person) : Employee =
    {
        email = person.name + "@fsharp.com"
    }

let ConvertPersonListToEmployeeList
    (people: List<Person> option) : List<Employee> option =
    match people with
    | None -> None
    | _ -> people.Value
           |> List.map ConvertPersonToEmployee
           |> Some

[<EntryPoint>]
let main argv =    

    let januaryJoiners : List<Person> option = Some [{ name = "Rob" }; { name = "Bob" }]
    let februaryJoiners : List<Person> option = None

    let januaryEmployees = ConvertPersonListToEmployeeList januaryJoiners
    let februaryEmployees = ConvertPersonListToEmployeeList februaryJoiners

    printfn $"January Employees: {januaryEmployees}"
    printfn $"February Employees: {februaryEmployees}"
    0

Output

January Employees: Some([{ email = "Rob@fsharp.com" }; { email = "Bob@fsharp.com" }])
February Employees:

Configure and implement Serilog into F#

Rob — Fri, 08 Jul 2022 07:44:00 +0000

The purpose of this article is to demonstrate the code required to implement the Serilog Log into an F# console application.

Setup

The below example was built into a Console Application using F# on the .NET 6 Framework. The following packages were installed:

Serilog/2.11.0
Serilog.Sinks.Console/4.0.1
Serilog.Formatting.Compact/1.1.0
Serilog.Enrichers.Environment/2.2.0
Serilog.Enrichers.Process/2.0.2
Serilog.Enrichers.Span/2.3.0
Serilog.Enrichers.Thread/3.1.0

Code

Copy the below code into your Progam.fs file and run the application. This will print 5 logs to your terminal. The LoggerConfiguration makes use of several enrichers to add additional data to the output as well as using RenderedCompactJsonFormatter which instructs the console writer to output the message in json format.

open System
open Serilog
open Serilog.Formatting.Compact

type Data = {
    Id: int
    On: bool
    Created: DateTime
    Message: string
    MessageSome: string option
    MessageNone: string option
}

[<EntryPoint>]
let main argv =

  Log.Logger <-
    LoggerConfiguration()
      .MinimumLevel.Debug()
      .Enrich.FromLogContext()
      .Enrich.WithEnvironmentName()
      .Enrich.WithMachineName()
      .Enrich.WithThreadId()
      .Enrich.WithProcessId()
      .WriteTo.Console(RenderedCompactJsonFormatter())
      .CreateLogger()

  let dummyData : Data = {
        Id = 1
        On = true
        Created = DateTime.UtcNow
        Message = "Content"
        MessageSome = Some "Content"
        MessageNone = None    
  }

  try
      try          
          Log.Logger.Debug("{dummyData}", dummyData)
          Log.Logger.Information("{dummyData}", dummyData)      
          Log.Logger.Warning("{dummyData}", dummyData)
          Log.Logger.Error("{dummyData}", dummyData)
          Log.Logger.Fatal("{dummyData}", dummyData)

          1 / 0
      with
         | ex ->
             Log.Error($"Error: %s{ex.Message}")
             1
  finally
      Log.CloseAndFlush()

Output

{"@t":"2022-07-08T07:49:44.0016610Z","@m":"\"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \\\"Content\\\"\n  MessageSome = Some \\\"Content\\\"\n  MessageNone = None }\"","@i":"60a52653","@l":"Debug","dummyData":"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \"Content\"\n  MessageSome = Some \"Content\"\n  MessageNone = None }","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}
{"@t":"2022-07-08T07:49:44.1605920Z","@m":"\"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \\\"Content\\\"\n  MessageSome = Some \\\"Content\\\"\n  MessageNone = None }\"","@i":"60a52653","dummyData":"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \"Content\"\n  MessageSome = Some \"Content\"\n  MessageNone = None }","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}
{"@t":"2022-07-08T07:49:44.1611770Z","@m":"\"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \\\"Content\\\"\n  MessageSome = Some \\\"Content\\\"\n  MessageNone = None }\"","@i":"60a52653","@l":"Warning","dummyData":"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \"Content\"\n  MessageSome = Some \"Content\"\n  MessageNone = None }","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}
{"@t":"2022-07-08T07:49:44.1615460Z","@m":"\"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \\\"Content\\\"\n  MessageSome = Some \\\"Content\\\"\n  MessageNone = None }\"","@i":"60a52653","@l":"Error","dummyData":"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \"Content\"\n  MessageSome = Some \"Content\"\n  MessageNone = None }","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}
{"@t":"2022-07-08T07:49:44.1750560Z","@m":"\"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \\\"Content\\\"\n  MessageSome = Some \\\"Content\\\"\n  MessageNone = None }\"","@i":"60a52653","@l":"Fatal","dummyData":"{ Id = 1\n  On = true\n  Created = 07/08/2022 07:49:44\n  Message = \"Content\"\n  MessageSome = Some \"Content\"\n  MessageNone = None }","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}
{"@t":"2022-07-08T07:49:44.1825110Z","@m":"Error: Attempted to divide by zero.","@i":"79a82f6d","@l":"Error","EnvironmentName":"Production","MachineName":"X-MAC","ThreadId":1,"ProcessId":69944}

Software documentation is still relevant in certain environments

Rob — Sun, 24 Apr 2022 11:55:04 +0000

I am somewhat late to the party but I have recently finished reading 'Inspired: How to Create Tech Products Customers Love' published in 2018 by Marty Cagan from the Silicon Valley Product Group. It's a fantastic read.

The book was very enlightening and I would highly recommend it to any fellow software engineer in understanding their role in an aspiring product led environment. The language is casual and the content is delivered in short concise chapters, with welcome interjections of high profile product use cases. On this point however, it may have been worth balancing out these successful use cases with some product efforts which for one reason or another went sideways, provided there was a teaching moment in there. We often learn more from the failures than the successes.

But with all that being said, I did have one bone to pick, the utility of documentation.

Like many software engineers, the author suggests that code should ideally speak for itself which implies that documenting is not a worthwhile endeavour, and then the topic moves on. This is something I hear very often in industry from software engineers, mainly because the code is being developed faster than someone's ability to update the relevant document but also because software engineers simply do not like doing it.

This gives a false impression that it's an outdated tool that should be left in the toolbox. But in my experience it depends very much on the environment you are working in, how you create it and what you expect from it.
If you are working in an environment of strong communication, a stable product and a relatively clean codebase developing at a fast pace, then documentation is probably not worth the added expense. This is the ideal. However, if you work in a organisation with weak communication and suffering from extreme technical debt and a sluggish development speed, then documentation is an invaluable and probably essential tool to use. This is especially true if the organisation has plans to turn itself around where documentation can achieve the following:

- Saving Investigation Time: The author correctly points out that in an environment of extreme technical debt, engineers are often inundated with requests to investigate how a piece of functionality works. A consequence of this continuous tidal wave of requests is that the engineer often does not have time to sensibly refactor or improve that code. So a document here can act as a shield to free up some of that time. Equally, other engineers on the team can find simple answers without time being spent in setting up local environments or requesting environment access.

- Remove single points of failure: Like writing documentation, few engineers enjoy rolling up their sleeves to deep dive into understanding legacy code, and in an environment of extreme technical debt, this task can be quite horrendous. A resulting document here means that if that engineer later walks out the door, which is not uncommon in these environments, the product team does not need to start from zero.

- Bridging tool: Documentation can be a useful tool to bridge that gap from technical debt to a cleaner and stable product. For example, your team could be tasked with refactoring a product feature that is driven by 20 unique scripts that largely do the same thing but contain small bespoke functionality for one or more customers. The first step is knowing what makes those 20 variations unique and a single detailed document can map out and communicate that faster and more accurately than any number of engineers.

Whichever way you lean in respect of your opinion of documentation, writing good documentation is a valuable skill. Do not assume that someone who can write clear software can do the same in plain English for a wider audience to consume. This is an important consideration when judging the utility of your documentation efforts.
I'll end it there 👍

Other reading materials mentioned in the book include:

- User Story Mapping (2015 ) Patton, J. et al
- The Power of Customer Misbehavior (2014) Fisher, M. et al
- Sprint (2016) Knapp, J. et al

Top Tips for interviewing software developers

Rob — Fri, 25 Mar 2022 13:29:24 +0000

The purpose of this article is to share with you some advice obtained from a professional interviewer with several decades of experience in the field. The reason for obtaining such advice was for our software engineering team to better equip themselves with judging the interpersonal skills, team fit, and general attitude of prospective candidates during an interview process.

This content is to be understood as general advice from a single individual and discussed in the context of private sector software engineering. Any applications should align with your own industry requirements, values and hiring policies.

Structure & Introductions 🖖

The interview process should follow some kind of repeatable and structured design. It will allow for more consistent comparisons of candidates. The candidate will also understand that you are a professional and serious outfit. While there is a huge margin of flexibility to the below points, don't be overly laid back when interviewing.

Length: An advised interview length is 40 minutes with at least 2 interviewers present. Maintaining a strict time-box will help to counteract wafflers and allow the interviewer to reflect on the quality of information given post-interview. Your questions should be robust enough to fit within the timeframe and compel you to get the right information.
Rounds: Two rounds of interviews should be plenty to find out what you need to know. This can be supplemented by a technical assignment. The second interview should have one interviewer from the first round and new interviewer. This will allow the team to better evaluate the candidate's behaviour over time. The disadvantage of many rounds of interviews, other than the expense, is that the candidate becomes more comfortable in the latter phases and is likely to start giving more predictable or routine answers to questions. You have a greater chance of honest information and character insights in the earlier interviews.
Introductions: Every interviewer should give an introduction of who they are and why they are there. It is then advised to give the candidate somewhat of an introduction to the structure or the topics expected to be covered in the interview. This will help keep both the candidate and interviewer on track to obtain the necessary information in the allotted time. Consider explaining to the candidate that you may abruptly change topics. This is not to try throw them off but to ensure we as interviewers get the information we need. This is another tool against rambling.
Topics: It is common in software engineering to split interviews between technical and interpersonal skills. The issue with this is that you may lose an excellent candidate prematurely or keep an undesirable candidate in the process longer than needed depending on the type of interview you lead with. This is why interviews should always be a mix of interpersonal to technical questions.

Planning & Analytical Skills 💡

The ability to plan and contribute analytical skills is of utmost importance to most positions, especially software engineering. Below are a couple of techniques for determining such skills:

Planning Questions: Ask the candidate to go through a planning stage of a project, how they stuck to it and pick questions from this journey.

How did they prepare themselves beforehand?
Did they foresee any problems for themselves?
How did they overcome the shortage of a resource?
What contingencies did they consider in the event of blockers?
How do they communicate their plan to others?
Did they ever miss a deadline or fail to deliver work?
How do they plan for pressure?
What did they learn from any of the above?

This is a good category of questions for a number of reasons. Firstly you can judge what the candidate learned by the detail of their initial answer and what they took from the experience. It's of critical importance that the candidate demonstrates an ability to enrich themselves. This is true for all areas of interest and can't be emphasised enough.

By also asking questions around failures you may detect an undesirable level of ego or pride. Similarly, by asking questions around pressure or burnout you can determine some emotional intelligence.

Analytical Questions: Aside from general code related questions feel free to ask the candidate to step through a technical hurdle they faced. Equally, you can share with the candidate a problem you as the interviewer are currently having. This will test both their analytical skills, as well as their interpersonal skills in communicating their thoughts to you.

With regards to asking a candidate to discuss an example of any kind, it is very common that they will have a well versed and planned example to give you. However, if you want a less rehearsed answer or want to examine the topic further, simply ask for another example to your question.

Interpersonal & Team Skills 🤜🏼🤛🏼

The strongest technically minded engineer can still have the power to derail a project due to terrible communication skills, arrogance, stubbornness, poor leadership or team skills. It is essential that the candidate you bring into your team can work and play well with others, and you must find this out. From the experience of the author, it is the most expensive thing to get wrong.

Team Experience & Leadership: To break the ice on this topic you can simply ask the candidate what kind of professional teamwork they have done in the past and then base your questions around the response. Remember, if you're not happy with an example, ask for another. You're looking for some of the following indicators:

Can they articulate the value they contributed to the team as whole beyond the software?
Can the candidate express their weaknesses relative to the team and how did they mitigate them?
How did they resolve either a creative or personal conflict with another team member
What has working with others taught the candidate about themselves?
Did the candidate assume a leadership role and how was it applied?

Regarding leadership, you may want to drill into the topic of mentorship. It is common in software engineering that teams are made up of engineers with very different experience. It is expected that senior engineers guide junior engineers along and improve them. You will want to know how the candidate achieves this and how they resolve any issues before needing to bring the problem to a team lead or manager.

Interests: Asking questions about outside interests and hobbies is often seen as a bit antiquated, but it is still a valuable tool in determining the interpersonal skills of a candidate. For example, do they engage in any group or community activities? this could be anything from football to board gaming.

Organisations Values & Commitment 🦸‍♂️

It is important to work into the interview questions which reflect your organisations values and work ethic. If you as an interviewer are having trouble articulating or evaluating such questions, use your own personal values. After all, the organisation hired you, and trusted you with this task based on those same values.

Feel free to ask questions regarding the candidate's commitment either to the profession or the project they worked on. You don't want to glorify working ridiculous hours, which is something you hear quite a lot. Instead, you should be looking for personal projects, interest in a particular tech, involvement in the tech community or a demonstration of continuous learning.

Creating Different Default Value Sets for an F# Record Type

Rob — Sun, 27 Feb 2022 10:23:26 +0000

The purpose of this post is to provide you with a simple working example of creating different default value sets assigned to a particular record type in F#. It then demonstrates how to update selected fields when binding that default to a new variable using the with keyword.

The benefit of this approach is that the record type remains immutable. Record types do not support the DefaultValueAttribute so it would mean not needing to go out of your way to create a class with mutable explicit fields.

Below is an example of a Meal record type with two different value bindings, one named defaultBreakfastMeal and the other defaultDinnerMeal. There is nothing syntactically different between a regular binding of a record type and one we choose to use as a default.

Record Type & Default Sets

type Meal = { 
      Food: string
      Drink: string }

let defaultBreakfastMeal: Meal = {
      Food = "Pastry"
      Drink = "Coffee" }

let defaultDinnerMeal: Meal = {
      Food = "Shepherd's Pie"
      Drink = "Water" }

We can later set a new binding but update the returning default values with selected overrides. In this case, the Food value.

let HangoverMeal = {
    defaultBreakfastMeal
    with
        Food = "Irish Breakfast"
}

Output

HangoverMeal.Food = "Irish Breakfast"
HangoverMeal.Drink = "Coffee"

Creating a TRX File from an API for Azure DevOps CI/CD Pipeline Integration

Rob — Thu, 24 Feb 2022 16:11:04 +0000

The purpose of this article is to provide you with an example of a TRX file structure and how our team took a TRX formatted string response from a web service and injected it into our CI/CD pipeline on Azure DevOps.

This web service is called Palladium and is an open source solution for executing asynchronous, long-running tests in Orleans and produces TRX results via a HTTP web API endpoint.

A TRX File, Rawr! 🦖

A TRX file (or T-REX file as I like to pronounce it) is a test result file created typically by Visual Studio when outputting the results of unit tests. It has a .trx file extension and is formatted the same as xml. It can be viewed and edited in most text editors or IDE's such Visual Studio or Jetbrains Rider.

The Belly of the Beast 😱

Below is an example of the TRX output from Palladium /AsynchronousTests. We made some slight alterations from the default file structure to better serve our needs. For example we removed the deployment node from TestSettings and made it self closing. We also did away with the contents of the Output node.

<?xml version="1.0" encoding="UTF-8"?>
<TestRun xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010" id="a5e9e312-66fe-4f2d-b0c9-ce0fbc57cd9b" name="10ed7f37-b86d-4b36-a378-3c3fa724757e">
   <Times creation="2022-02-24T15:14:59.6966860Z" queueing="2022-02-24T15:14:59.6981900Z" start="2022-02-24T15:14:59.6981900Z" finish="2022-02-24T15:15:00.0311280Z" />
   <TestSettings id="fe569017-6430-466c-b8b8-2360549b5576" name="39bc153c-86b0-404a-b93f-67113b5cca75" />
   <Results>
      <UnitTestResult executionId="09b849b9-2e9d-42ec-808e-a530ac272082" testId="2a3b891d-a24b-4e16-b730-a73607835817" testName="Test1" computerName="352509f7-e206-465e-966c-b7574939feb5" duration="0:00:00.129834" startTime="2022-02-24T15:14:59.7007960Z" endTime="2022-02-24T15:14:59.8306300Z" testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="Passed" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" relativeResultsDirectory="09b849b9-2e9d-42ec-808e-a530ac272082" />
      <UnitTestResult executionId="a27998f9-7b79-4b6f-86f9-6b569f46685b" testId="1ece5274-6d1e-4dff-b314-dcee7b751358" testName="Test2" computerName="352509f7-e206-465e-966c-b7574939feb5" duration="0:00:00.227086" startTime="2022-02-24T15:14:59.7030020Z" endTime="2022-02-24T15:14:59.9300880Z" testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="Passed" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" relativeResultsDirectory="a27998f9-7b79-4b6f-86f9-6b569f46685b" />
      <UnitTestResult executionId="99fb1cb4-8ad8-48d8-97f2-97805f3d0746" testId="546e9edb-7b96-4ada-9f45-9f947860839e" testName="Test3" computerName="352509f7-e206-465e-966c-b7574939feb5" duration="0:00:00.327032" startTime="2022-02-24T15:14:59.7032380Z" endTime="2022-02-24T15:15:00.0302700Z" testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="Passed" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" relativeResultsDirectory="99fb1cb4-8ad8-48d8-97f2-97805f3d0746" />
   </Results>
   <TestDefinitions>
      <UnitTest id="2a3b891d-a24b-4e16-b730-a73607835817" name="Test1" storage="AsynchronousTests.dll">
         <Execution id="09b849b9-2e9d-42ec-808e-a530ac272082" />
         <TestMethod codeBase="AsynchronousTests.dll" className="Grains.AsynchronousTests" name="Test1" adapterTypeName="orleans" />
      </UnitTest>
      <UnitTest id="1ece5274-6d1e-4dff-b314-dcee7b751358" name="Test2" storage="AsynchronousTests.dll">
         <Execution id="a27998f9-7b79-4b6f-86f9-6b569f46685b" />
         <TestMethod codeBase="AsynchronousTests.dll" className="Grains.AsynchronousTests" name="Test2" adapterTypeName="orleans" />
      </UnitTest>
      <UnitTest id="546e9edb-7b96-4ada-9f45-9f947860839e" name="Test3" storage="AsynchronousTests.dll">
         <Execution id="99fb1cb4-8ad8-48d8-97f2-97805f3d0746" />
         <TestMethod codeBase="AsynchronousTests.dll" className="Grains.AsynchronousTests" name="Test3" adapterTypeName="orleans" />
      </UnitTest>
   </TestDefinitions>
   <TestEntries>
      <TestEntry testId="2a3b891d-a24b-4e16-b730-a73607835817" executionId="09b849b9-2e9d-42ec-808e-a530ac272082" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" />
      <TestEntry testId="1ece5274-6d1e-4dff-b314-dcee7b751358" executionId="a27998f9-7b79-4b6f-86f9-6b569f46685b" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" />
      <TestEntry testId="546e9edb-7b96-4ada-9f45-9f947860839e" executionId="99fb1cb4-8ad8-48d8-97f2-97805f3d0746" testListId="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" />
   </TestEntries>
   <TestLists>
      <TestList id="2c0cd20b-ad9a-4ade-b491-479e8d9d4a0d" name="All Loaded Results" />
   </TestLists>
   <ResultSummary outcome="Complete">
      <Counters total="3" executed="3" passed="3" failed="0" error="0" timeout="0" aborted="0" inconclusive="0" passedButRunAborted="0" notRunnable="0" notExecuted="0" disconnected="0" warning="0" completed="0" inProgress="0" pending="0" />
      <Output StdOut="" />
   </ResultSummary>
</TestRun>

VSTS Integration 🤜🤛

Below is an extract of two steps from our CI/CD pipeline which occur after we deploy our application to our test environment. We configured our Palladium unit tests to run on that same environment.

We first used the Bash@3 task to call the internally hosted instance of the Palladium solution and save the resulting string as a .trx file in the DefaultWorkingDirectory of the VSTS server.

We then configured a PublishTestResult@2 task to VSTest and searched explicitly for the palladium-output.trx file in the working directory. This step publishes the contents of the TRX file to the UI on the Azure pipeline build.

- task: Bash@3
  displayName: Calling Palladium API Tests
  inputs:
    targetType: 'inline'
    script: |
      curl -s -m 5 $(PALLADIUM_API) -o palladium-output.trx

- task: PublishTestResults@2
  displayName: Printing Test Result File
  inputs:
    testResultsFormat: 'VSTest'
    testResultsFiles: 'palladium-output.trx'
    searchFolder: '$(System.DefaultWorkingDirectory)'
    testRunTitle: 'Test Palladium TRX'
    publishRunAttachments: true
    failTaskOnFailedTests: true

The $(PALLADIUM_API) environment variable holds our URL to the test result endpoint of our Palladium instance.

Conclusion

The reason for the above implementation is because we as a team wanted to abstract out our unit tests into an independent API solution to call our various environments. If you decide to implement a similar design you can integrate it into your CI/CD with the above solution.

Co-Author: Piotr Justyna

XmL Serialization for F# Record Types

Rob — Tue, 22 Feb 2022 18:46:56 +0000

While Microsoft do provide documentation for XmlSerializer the examples are currently in C# only. Equally, many long-standing and valid community solutions can only be found when using keywords which indicate you already know the answer! Quite annoying.

The purpose of this article is to provide you with a clear working example of serializing an F# record type using the XmlSerializer class and CLIMutable attribute.

XmlSerializer 🥣

The caveat of using the XmlSerializer with F# is that the class requires the referenced type to have a parameterless constructor in order to work. Such constructors are implicitly created in the background for C# classes without any explicit constructors defined. This is not the case for an F# record type.

The below example implements a simple type with some elements, attributes and an array of sub-types.

Record Type

[<CLIMutable>]
[<XmlRoot("Student")>] 
type Student =
  { [<XmlAttribute("id")>]
    Id : int
    [<XmlElement("Name")>]
    Name : string }

[<CLIMutable>]
[<XmlRoot("Master")>] 
type Master = 
  { [<XmlAttribute("id")>]
    Id : int
    [<XmlElement("Name")>]
    Name : string
    Students : Student [] }

The below implementation of the serialization logic is standard, with a new StringWriter, the payload and some namespace configuration being passed to the Serialize function of XmlSerilizer.

Serializer

let payload : Master =
    {
        Id = 1984
        Name = "Johnny Lawrence"
        Students = [|
            { Id = 1; Name = "Miguel Diaz" }
            { Id = 2; Name = "Hawk" }
        |]
    }            

let serializerNamespaces = XmlSerializerNamespaces()
serializerNamespaces.Add("", "")

let writer = new StringWriter()

let serializer = XmlSerializer(typeof<Master>)
serializer.Serialize(writer, payload, serializerNamespaces)

printf $"{writer.ToString()}"

Output

<?xml version="1.0" encoding="utf-16"?>
<Master id="1984">
  <Name>Johnny Lawrence</Name>
  <Students>
    <Student id="1">
      <Name>Miguel Diaz</Name>
    </Student>
    <Student id="2">
      <Name>Hawk</Name>
    </Student>
  </Students>
</Master>

Mutable 🧟‍

The reason the above serialization works is because we added the [<CLIMutable>] attribute to each of the types to be serialized. The attribute instructs the compiler to add internal auto-generated mutable fields. From a programming perspective, the type is still immutable as these internal fields can only be accessed by automated processes or if you decided to expose the type to C# code.

By using this attribute we can make use of normal .NET serializers and avoid harder to work with solutions like the DataContractSerializer.

Working Example 🧪

The following solution provides an example of the XmlSerializer turning a record type into an xml formatted string for an API response. This solution is an open-source implementation of asynchronous, long-running tests in Orleans which produce TRX results via a HTTP web API endpoint.

Co-Author: Piotr Justyna

Getting Started with Github Action Workflows

Rob — Thu, 17 Feb 2022 20:39:39 +0000

This article gives a brief introduction to the concepts and syntax of github actions. While the official documentation of github actions is comprehensive, the aim of this article is to help avoid those early learning mistakes.

link to original article

Context 👨🏼‍🏫

Github actions is a platform to automate developer workflows. It was built to reduce the organisational burden attached to large open-source community driven repositories. This burden would manifest in the form of hundreds, if not thousands, of contributors, branches, pull requests, merges as well as testing, labelling, creating release documentation and many other tasks or events.

The purpose of an action is to listen to these events and trigger a workflow in response. For example, if a contributor raises an issue, you may want to sort it, label it, and assign it automatically. A workflow is a .yml or .yaml file with a set of instructions you define.

While CI/CD is often used to convey its utility, it is just one of many possible workflows you can create to serve your needs. The examples in this article are simple workflows created merely to introduce some of the basic concepts.

Executing Shell Commands
Accessing Environment Variables
Calling Composite Actions
Setting & Passing Variables
Making Web Service Calls

1. Executing Shell Commands 🐚

The first example below is a very basic workflow executing different commands in their native shells. The point of this example is to illustrate the role of the run-on and shell instructions. A workflow refers to all the instructions within the file, which is comprised of one or more jobs, which in turn is comprised of one or more steps.

Each job listed within a workflow is executed concurrently on a different github server, but you can choose to host them yourself. The significance of this means you need to specify which operating system you want your job to run on by using the run-on keyword. This can include various versions of windows, macOS, ubuntu or even being self-hosted.

If for example all your steps within a job run powershell commands or scripts, you could specify run-on: windows-latest and call it job done as powershell would be understood by the runners of that operating system. But let's say you needed to run a one off Zshell script in the same job, here the shell keyword can allow you to override the shell of the specified OS by specifying the correct shell language.

Below is an example of 'Hello World' being printed to the console in powershell, bash, zshell and even python , which are all being run on a windows github server. Github also accepts powershell, pwsh (powershell core) and cmd when overriding for Windows commands. See the code example for more useful information in the comments and follow all links to source file.

Workflow

name: 1 - Run Hello Worlds scripts              # <- Workflow name.

on:                                             # <- The trigger definition block.
  push:                                         # <- An event to trigger the action, of type push.
    branches: [                                 # <- Target Branches. Accepts an array.
      main,
      another-branch
    ]

jobs:                                           # <- The execution of work block.
  Job-Identifier:                               # <- Job ID. Contains related action steps.
    name: Executing Hello World Script          # <- Job Name.
    runs-on: windows-latest                     # <- Tells the server which OS to run on. Can also be windows, macOS, or even self-hosted.      

    steps:                                      # <- Step definitions.
      - uses: actions/checkout@v2               # <- Use keyword selects an action. Actions/ path in github is where common actions are predefined.

      - name: Printing Powershell               # <- Optional step name, but advised.                       
        run: ./Powershell/HelloWorld.ps1        # <- Run keyword executes a command. In this case a powershell script.

      - name: Printing Bash
        shell: bash                             # <- Overrides the default shell language of your specified server. 
        run: ./Bash/HelloWorld.sh

      - name: Printing ZShell
        shell: sh
        run: ./Zshell/HelloWorld.zsh

      - name: Printing Python
        shell: python
        run: exec(open('./Python/HelloWorld.py').read())

Console Output

Run ./Powershell/HelloWorld.ps1
Hello World from Powershell!

Run ./Bash/HelloWorld.sh
Hello World from Bash!

Run ./Zshell/HelloWorld.zsh
hello world from Zshell!

Run exec(open('./Python/HelloWorld.py').read())
Hello World from Python!

2. Accessing Environment Variables 🌱

The following example illustrates how you can read environment variables. There are two kinds of variables, those provided by github which use protected names and can be found in the documentation, and custom variables you can set yourself throughout your workflow.

Another significant feature of the workflow, job and step relationship is how custom variables are scoped. Declared variables within the workflow using the keyword env follow an access hierarchy and can only be accessed within the element they were defined. Those variables declared at the highest workflow level can be accessed by all jobs and steps. Variables declared within a job can only be used by steps within that job and if declared inside a step they can only be used by that step.

2.1 Custom & Protected Environment Variables

In the below workflow example you can see that 3 custom variables are declared at different levels: BEST_PINT, BEST_WHISKEY and BEST_COCKTAIL. In the Print Variables to Script step a script is executed to print these variables to the console along with a sample of various set github environment variables.

Workflow

name: 2 - Access Github Environment Variables

on:
  push:
    branches: [
        main,
        another-branch
    ]
  pull_request:                                   # <- Pull request trigger. Used in Example 2.2.
    branches: [
        main                                      # <- If any pull request is made to branch 'main'.      
    ]

env:
  BEST_PINT: Guinness                             # <- Custom environment variable declared at workflow level.

jobs:
  #Example 2.1
  Access-Environment-Variables:
    name: Print Github Environment Variables
    runs-on: windows-latest
    env:
      BEST_WHISKEY: Midleton                      # <- Scoped to this job and subsequent steps.         

    steps:
      - uses: actions/checkout@v2

      - name: Print Variables to Script
        run: ./Powershell/GithubEnvVariables.ps1
        env:
          BEST_COCKTAIL: Whiskey Sour              # <- Scoped to this step only.

      - name: Inspect Environment Variables
        run: env                                   # <- Prints to output the available variables to this step.

Console Output

The owner and repository name.
GITHUB_REPOSITORY: 'Mulpeter91/Github-Actionman'

The commit SHA that triggered the workflow.
GITHUB_SHA: '321d557ec2d724d2c6aaf056b14859ea8468051e'

The job id you assigned to the current job.
GITHUB_JOB: 'Job-Identifier-Sample'

A unique number for each workflow run within a repository. This number does not change if you re-run the workflow run.
GITHUB_RUN_ID: '1836698654'

An unique number for each time the same workflow is run again. Starts at 1 and increments by 1.
GITHUB_RUN_NUMBER: '18'

The name of the runner executing the job.
RUNNER_NAME: 'GitHub Actions 4'

I love a pint of Guinness with a glass of Midleton and end the night on a Whiskey Sour.

A useful command to inspect available environment variables within a step is run: env. Notice that the below output does not contain BEST_COCKTAIL because it was defined and scoped to the previous step.

...

APPDATA=C:\Users\runneradmin\AppData\Roaming
AZURE_EXTENSION_DIR=C:\Program Files\Common Files\AzureCliExtensionDirectory
BEST_PINT=Guinness
BEST_WHISKEY=Midleton
CABAL_DIR=C:\cabal
ChocolateyInstall=C:\ProgramData\chocolatey

...

You must remember to use the correct syntax for referencing variables in your target shell. For example, Windows runners would required the format $env:NAME while the Linux runners using bash shell would use $NAME.

2.2 Specific Event Variables

Most github environment variables will always populate, such as GITHUB_ACTOR but some will only be populated during a specific event trigger. In the above workflow example you can see a trigger has been added for pull_request. This has been added to show you some of the variables that will only populate during that event, such as GITHUB_BASE_REF and GITHUB_HEAD_REF.

Workflow

#Example 2.2
Pull-Request-Variables:
  name: Obtain variables useful to a pull request
  runs-on: windows-latest
  env:
    var: nothing
  steps:
    - uses: actions/checkout@v2

    - name: Print Variables for Pull Request     # <- Add a pipe key on the run command to make a multiple.
      run: |
        Write-Host "Actor: $Env:GITHUB_ACTOR"
        Write-Host "Target Branch: $Env:GITHUB_BASE_REF"
        Write-Host "Source Branch: $Env:GITHUB_HEAD_REF"

Console Output

Actor: Mulpeter91
Target Branch: main
Source Branch: pull-request-ex

2.3 Accessing Event Metadata

Another variable worth noting and is heavily effected by the action event type is GITHUB_EVENT_PATH. This variable contains the directory within your runner to a temporarily stored event.json file. This file contains substantial metadata regarding the specific event triggered within the workflow and can be fed into a json object for easy access to specific data nodes.

Every event type has it's own structured version of the file. So what exists in a pull_request:event.json will not exactly match the nodes in a push:event.json.

Workflow

#Example 2.3   
- name: Print Json from Action Event File
  run: ./PowershellEventFile.ps1

File

"Event metadata file path: $Env:GITHUB_EVENT_PATH`n"
"File Contents:"
$EVENT_FILE = Get-Content -Path $Env:GITHUB_EVENT_PATH
Write-Host $EVENT_FILE

$EVENT_JSON = $EVENT_FILE | ConvertFrom-Json
"`nSample selectors"
Write-Host "OBJECT.head_commit.author.username:" $EVENT_JSON.head_commit.author.username
Write-Host "OBJECT.head_commit.url:" $EVENT_JSON.head_commit.url

Console Output

Event metadata file path: D:\a\_temp\_github_workflow\event.json
File Contents: (see above console link)

Sample selectors
OBJECT.head_commit.author.username: Mulpeter91
OBJECT.head_commit.url: https://github.com/Mulpeter91/Github-Actionman/commit/443da01e18050bd8912d3fac24a86f0c340a2ea8

3. Calling Composite Actions ⚙️

Composite actions are a specific type of workflow file which are designed to abstract out and reuse a set of instructions for one or more requesting workflows. They are typically stored in their own repositories, such as Github's own shared actions or Google's integration actions, but they can also be stored and executed in the same repository.

A step utilises the uses keyword when executing a composite action. In the below example you will notice two steps each using a composite action. The first is using github's shared actions/checkout@v2 and the other is using our local composite action.

Composite actions depend on targeted releases to know which version of the code to execute. In the case of checkout@v2 this is referencing release v2 in the checkout repository. You need to checkout your code in order to build it, test it or in our case execute composite actions.

Workflow

name: 3 - Running a local Composite Action

on:
  push:
    branches: [
        main,
        another-branch
    ]

jobs:
  Run-Composite-Action:
    name: Print message from another action
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v2                 # <- Required to checkout your code in order to access composite actions from with the repo

      - name: Use hello world composite action
        uses: ./.github/actions/hello-world       # <- Use keyword for calling other actions

The composite action file requires a name and description field with an optional author field. The run also needs to add using: 'composite' before executing its steps.

Composite Action

name: Print Hello World
description: Prints a Hello World message.
author: Robert Mulpeter @Mulpeter91

runs:
  using: "composite"                # <- Required declaration of a composite action.
  steps:
    - run: Write-Host "Hello World from Composite Action!"
      shell: pwsh

Console Output

Run ./.github/actions/hello-world
Run Write-Host "Hello World from Composite Action!"
Hello World from Composite Action!

Another important point regarding composite actions is that they must be defined inside a file called either action.yml or action.yaml. It is recommended that if you have multiple composite actions in the same repo that you house them in their own directories within the .github directory. While these directories can contain other files such as docker files, they must contain one action file. See working repo for an example.

4. Setting and Passing Variables 🤾

The below step examples are all run on the same workflow file and combine parts of the previous code with the added fun of setting variables from outside the yml file and passing variables around the workflow.

4.1 Passing Parameters to Composite Action

In the below example we are using a composite action much like example 3 but with input parameters. The step passing these named parameters to the action with the with keyword and <variable> name, in this case 'message'.

Job 1 / Example 1

jobs:
  Create-Variables:
    name: Creating and passing variables
    runs-on: windows-latest

    steps:
      #Example 4.1
      - uses: actions/checkout@v2

      - name: Use print message composite action
        uses: ./.github/actions/print-message
        with:                                 # <- With keyword to signify parameters
          message: "Cobra Kai never dies"     # <- Named parameter in the called action.

The composite action lists its parameters with the inputs keyword. Parameters can be required: true or false, include a description and a default value if no value is passed. In our case, a message value is sent but a version value is not.

Composite Action

name: Print Parameters
description: Prints a message passed from the workflow.
author: Robert Mulpeter @Mulpeter91

inputs:       # <- keyword for defining action parameters.     
  message:
    required: true
    description: "The message to be printed"
  version:
    required: false
    description: "The version."
    default: "🤟🏻"

runs:
  using: "composite"
  steps:
    - run: Write-Host ${{ inputs.message }} ${{ inputs.version }}
      shell: pwsh

Console Output

Run ./.github/actions/print-message
Run Write-Host Cobra Kai never dies 🤟🏻
Cobra Kai never dies 🤟🏻

4.2 Set Variables from Environment File

The following example combines a parameterised composite action with reading the contents of an .env file into the environment variables for access by the workflow.

Job 1 / Example 2

#Example 4.2
- name: Set variables from environment file
  uses: ./.github/actions/read-env-file
  with:
    filePath: ./.github/variables/variables.env

Using >> $Env:GITHUB_ENV instructs github to read the variable into the environment variable dictionary.

Composite Action

name: Read Env Variables from file
description: Reads environment variables from a passed .env file.
author: Robert Mulpeter @Mulpeter91

inputs:
  filePath:
    required: true
    description: "File path to variable file."
    default: ./.github/variables*

runs:
  using: "composite"
  steps:
    - run: |
        Get-Content ${{ inputs.filePath }} >> $Env:GITHUB_ENV   # <- Adding directly $Env:GITHUB_ENV saves at the workflow level
      shell: pwsh

It is advised to keep all variable related files within the .github directory.

Input File

DOJO_1=Miyagi-Do Karate

Console Output

Run Get-Content ./Powershell/Variables.ps1 >> $Env:GITHUB_ENV
  Get-Content ./Powershell/Variables.ps1 >> $Env:GITHUB_ENV
  env:
    DOJO_1: Miyagi-Do Karate

4.3 Set Variables from Powershell File

The following example achieves the same outcome of example 4.2 but adds environment variables by executing a powershell script directly in the workflow step.

Job 1 / Example 3

#Example 4.3
- name: Set variables from powershell file
  run: Get-Content ./Powershell/Variables.ps1 >> $Env:GITHUB_ENV

Input File

DOJO_2=Eagle Fang Karate
DOJO_3=Cobra-Kai Karate

Console Output

Run Get-Content ./Powershell/Variables.ps1 >> $Env:GITHUB_ENV

4.4 Set Variables from Local Step Variable

The below example takes a local environment variable declared in the step and reads it directly into the github environment dictionary. Note from the below console output, that the variable $LOCAL_VARIABLE has been read into the dictionary under variable $WORKFLOW_VARIABLE which is accessible in the subsequent Inspect Environment Variables step.

Job 1 / Example 4

#Example 4.4
- name: Set local step variable to environment variable
  run: |
    echo "WORKFLOW_VARIABLE=$(echo ${Env:LOCAL_VARIABLE})" >> $Env:GITHUB_ENV
  env:
    LOCAL_VARIABLE: Karate Kid

- name: Inspect Environment Variables
  run: env

Console Output

echo "WORKFLOW_VARIABLE=$(echo ${Env:LOCAL_VARIABLE})" >> $Env:GITHUB_ENV
env:
  DOJO_1: Miyagi-Do Karate
  DOJO_2: Eagle Fang Karate
  DOJO_3: Cobra-Kai Karate
  LOCAL_VARIABLE: Karate Kid

Run env
env:
  DOJO_1: Miyagi-Do Karate
  DOJO_2: Eagle Fang Karate
  DOJO_3: Cobra-Kai Karate
  WORKFLOW_VARIABLE: Karate Kid

4.5 Pass Variable to Dependant Job

We previously noted that jobs are run concurrently by default and that variables are scoped to the element they are defined in. The following example illustrates how you can enforce a dependency between jobs to have them run consecutively to each other by using the needs array and pass a variable from the initial job to the dependent job using the outputs keyword rather than sending everything to the high level environment dictionary.

The below step is extracted from the first job create-variables and uses the outputs keyword with an object reference to step step_output. This step in turn uses the ::set-ouput name=NAME::Value command to set the outputted variable.

Job 1 / Example 5

jobs:
  create-variables:
    name: Creating and passing variables
    runs-on: windows-latest
    outputs:
      output1: ${{ steps.step_output.outputs.TONIGHTS_DINNER }}

    #Example 4.5
    - id: step_output
      name: Create variable output from step
      run: |
        echo "::set-output name=TONIGHTS_DINNER::Burrito"

The next step which is in the subsequent Obtain-Variables job then uses the needs keyword to wait for the referenced job to complete. The step then references the outputted variable and assigns it to the internal Dinner variable.

Job 2 / Example 5

Obtain-Variables:
  needs: [Create-Variables]       # <- Jobs run concurrently by default. Over this with the 'needs' keyword to set dependents.
  name: Reading previous variables
  runs-on: windows-latest

  steps:
    #Example 4.5
    - name: Print output variable
      run: |
        Write-Host "Tonights dinner will be " $Env:Dinner
      env:
        Dinner: ${{ needs.create-variables.outputs.dinner }}

Console Output

Run Write-Host "Tonights dinner will be" $Env:Dinner
Tonights dinner will be Burrito

5. Web Requests

The below workflow demonstrates a series of simple web calls to the Github Api pulls endpoint, which returns information on pull requests. You can feed the response into a json object to access relevant data. The below Invoke-WebRequest calls will work because this repo is public. If private you will need to create an OAuth Personal Access Token to the header with -Headers @{"Authorization"="Bearer <token>"}. If the repository belongs to an organisation to which you are a member you will need authorize that created token to enable access via configure SSO.

Workflow

name: 5 - Process Web Requests

on:
  pull_request:
    branches: [
        main
    ]

jobs:
  Obtain-Pull-Request-Data:
    name: Call Github API
    runs-on: windows-latest
    env:
      PR_STATE: closed      # <- query parameters to github are case sensitive

    steps:
      - uses: actions/checkout@v2

      - name: Call the Github /pulls endpoint
        run: ./Powershell/GithubWebRequests.ps1

Input File

"This will return a list of all open pull requests:"
$URI = "https://api.github.com/repos/$Env:GITHUB_REPOSITORY/pulls"
Write-Host $URI

"`nThis will return all pull requests of a specified state:"
$URI = "https://api.github.com/repos/$Env:GITHUB_REPOSITORY/pulls?state=$Env:PR_STATE"
Write-Host $URI

"`nThis will return a specific pull request:"
$PR_NUMBER = $Env:GITHUB_REF_NAME -replace "/.*" # <- You can also get the PR number from the pull request event file.
$URI = "https://api.github.com/repos/$Env:GITHUB_REPOSITORY/pulls/$PR_NUMBER"
Write-Host $URI
$RESPONSE = Invoke-WebRequest -Uri $URI -Method Get -TimeoutSec 480
Write-Host $RESPONSE

"`nAccessing variables from the object: "
$JSON_OBJECT = $RESPONSE | ConvertFrom-Json
Write-Host "HTML URL:" $JSON_OBJECT.html_url
Write-Host "TITLE:" $JSON_OBJECT.title
Write-Host "BODY:" $JSON_OBJECT.body
Write-Host "USER:" $JSON_OBJECT.user.login
Write-Host "REQUESTED REVIEWERS:" $JSON_OBJECT.requested_reviewers
Write-Host "MERGE_COMMIT_SHA:" $JSON_OBJECT.merge_commit_sha

Console Output

This will return a list of all open pull requests:
https://api.github.com/repos/Mulpeter91/Github-Actionman/pulls

This will return all pull requests of a specified state:
https://api.github.com/repos/Mulpeter91/Github-Actionman/pulls?state=closed

This will return a specific pull request:
https://api.github.com/repos/Mulpeter91/Github-Actionman/pulls/24

Accessing variables from the object: 
HTML URL: https://github.com/Mulpeter91/Github-Actionman/pull/24
TITLE: Test Title
BODY: Test Body
USER: Mulpeter91
REQUESTED REVIEWERS: 
MERGE_COMMIT_SHA: bd98939094bdb3d775966900ec43a126cf5fac80

Conclusion

The purpose of this article and these examples was to give you an introduction to basic concepts and syntax in order to continue learning github actions with a clearer vision of the platform. But this is just the tip of the iceberg. Github actions are capable of far more precise workflows with the use of more complex syntax.