Chinkes At Home

Author: john

  • Mech WIP

    I left my dark ages with the advent of Exo-Force and the ‘giant’ mecha that was the basis for that theme. So I built the sets, particularly getting 4-5 of the Grand Titan. From that I made a few different versions of my own, large, red, mech.

    lego robot

    This is one that survived a few moves and lots of playing and roughhousing. I basically kept the legs from the Titan. The arms a little more modified and then mirrored as I wanted two hands vs. hand+weapon.

    Lego robot

    This is the work in process that I have titled this post about. It looks rather complete, especially as I reused the arms and legs again. The torso is together but feel like I could do better. Particularly the seat for the minifig is strongly tied to the legs but that’s not so strongly tied to the torso.

    I also like to refine all the pieces in use the least necessary, so there is a lot of optimization to be done. I think the leg segment, which is at 33deg from the torso, could be connected better with clips and strengthened internally.

    I’m pleased with the ‘head’ of the mech, I’m calling this a Medium Armored Aardvark. The winking eye really ties it together for me.

  • Mastering Task Group Versions in Azure DevOps

    In Azure DevOps (ADO) classic pipelines, you can encapsulate steps into collections called Task Groups. These groups can then be easily reused in Builds or Releases to get common or standard steps shared across several pipelines.

    The issue is, if you just use the GUI to import a version of an existing Task Group, it just makes a new one with slightly different name, typically appending ‘copy’ to the same name. You can revise a Task Group while editing it but there are aspects that that the GUI does not expose to editing.

    As one example, there is a typical PowerShell technique to print variables: “$($_.Exception.Message)”. Inside the parentheses would be initial calculations or expressions that needed to be computed before printing the string. If you have this in a PowerShell step and save or revise, ADO will assume you want that as a variable to input to the task group. There is no way to remove ‘extra’ variables in the Task Group in the GUI.

    So, I looked at the ADO REST API documentation and saving a version isn’t standard. A search of the internet found one article on how to do this- https://medium.com/@tejasparmar99/azure-devops-task-group-version-upgrade-using-rest-apis-8524478364db. Updating a task group with a new version is a multi-step process when you use the GUI. The author figured out how these steps are replicated in PowerShell:

    1. Create a draft version of the task group by setting the version isTest value to true.
    2. Set the ‘parentDefinitionID’ property in the JSON definition of the task group to the ID of the previously created task group.
    3. Use the REST APIs to update the task group with the new version.

    This method allows you to update task groups to new versions while keeping the different versions intact.

    I took what they wrote and wrapped it in a little more logic. My function reads a list of the company standard Task Group definitions from a JSON file. It connects to the ADO Server using a Personal Access Token and retrieves the existing task groups. It compares the task group definitions from the JSON file with the existing task groups in Azure DevOps Server. If a task group definition is new, it takes the standard JSON definition file and creates new Task Group. If the Task Group exists, it uses the steps from above to create an updated version of the Task Group with multiple REST API calls.

    The article showed me the way when the official documentation failed me but also left implied details while updating versions:

    1. Creates a draft task group by adding missing properties to the new task group object, such as instanceNameFormat, definitionType, iconUrl, runsOn, and version.
    2. Posts the draft task group to ADO using a POST request.
    3. Publishes the draft task group as a preview using a PUT request.
    4. Publishes the preview as a new version of the task group using a PATCH request.

    This may have come from my standard JSON files not including all fields. There are enough to add it new but more parameters are needed when making a draft Task Group. Then there are parameters that change state as you change from draft to preview to published.

  • TFS/ADO REST API

    In my module, I have a number of functions that I wanted to share out to other internal teams. The module stuff is a little more helpful as it’s still relevant. I feel like all the cool kids use GITHUB and GIT Actions but someone else might be stuck using TFS repositories with Azure DevOps 2019 or greater.

    These are the functions I have to share. They are various helpers to read, create, or update tickets and builds using the REST API that comes with Azure DevOps.

    Here’s the list as I have while writing this-

    • Get-ChangesetCountSinceBuild.ps1
    • Get-MenuSelection.ps1
    • Get-TFSAttachments.ps1
    • Get-TFSbuildList.ps1
    • Get-TFSbuildStatus.ps1
    • Get-TFSqueryDetails.ps1
    • Get-TFSrelatedTickets.ps1
    • Get-TFSticketDetails.ps1
    • New-TFSbuildQueue.ps1
    • New-TFSticket.ps1
    • New-TFSvariableGroup.ps1
    • Update-TFSticket.ps1

    There is an odd-ball in the list: Get-MenuSelection is a function to add a menu option with arrow keys to the terminal. I got it from koupi.io but that site was taken down. Glad I grabbed it while I could!

    The rest of the functions follow a pretty standard pattern- some parameters to create the connection to ADO (URL, Personal Access Token, and the API version) and perhaps something specific to that function. The connection stuff is assembled and for all the Get- a call is made to ADO for some information. If in a New- function, the details are added to a $body variable and then the connection pushes the new whatever to ADO. If the connection has worked then the requested or new object is returned.

    You can hit me up with questions in GITHUB.