glennsarti

Facter.add('windows_chassistype') do
  confine :osfamily => :windows
  setcode do
    begin
      require 'win32ole' if Puppet.features.microsoft_windows?
      wmi = WIN32OLE.connect("winmgmts://./root/cimv2")
      enclosure = wmi.ExecQuery("SELECT * FROM Win32_SystemEnclosure").each.first
      
      enclosure.ChassisTypes  #  ==  [10] for a lpatop
 

glennsarti

infospot_file = "C:/Source/testmodule/infospot.properties"

Facter.add('infospot_site') do
  confine :osfamily => :windows
  setcode do
    begin
      return unless File.exist?(infospot_file)

      value = nil
      File.open(infospot_file, "r") do |f|

glennsarti

$EventLogFile = "C:\Source\tmp\PE-23563\FromTicket\DEVAPPVD-718_FAIL_SCALE\DEVAPPVD-718_FAIL_SCALE\EventViewer"
#$EventLogFile = "C:\Source\tmp\PE-23563\FromTicket\DEVAPPVD-723_SUCCESS\DEVAPPVD-723_SUCCESS\EventViewer"
Function Get-Stuff {
  # Get Service Start/Stops
  $SearchHash = @{
    'Path' = $EventLogFile + "\System.evtx"
    'ID' = 7036;
  }
  Get-WinEvent -FilterHashtable $SearchHash | ? { ($_.Properties[0].Value -eq 'Marionette Collective Server') -or ($_.Properties[0].Value -eq 'Puppet Agent') -or ($_.Properties[0].Value -eq 'Puppet PXP Agent') }

glennsarti

Combining PowerShell, Bolt and Puppet Tasks - Part 2

In Part 1 of this blog servies we created and ran a PowerShell script on our local computer, and then turned that into a Bolt Task. We then packaged the module so others could use the task. In Part 2 we going to look at how to test the PowerShell script.

Why test tasks?

So the most obvious question is, why would I want to test my Puppet Tasks? When we first start writing Tasks it is true that testing isn't really at the front our minds. However if you stop and look at the actions we took in Part 1, you can start to see we were actually testing our code, it was just a manual process, for example;

When we wanted to add Task metadata we did the following;

glennsarti

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2018-08-29T11:50:32</Date>
    <Author>RANDOM\USER</Author>
    <URI>\RunPuppetAgent</URI>
  </RegistrationInfo>
  <Triggers>
    <TimeTrigger>
      <Repetition>

glennsarti

$Script:PuppetConsoleURI = 'https://fill.this.in' # e.g. 'https://peconsole.company.local';
$Script:PuppetConsoleUsername = 'username';
$Script:PuppetConsolePassword = 'password'  # Cleartext

Function Get-PuppetLoginToken() {
  $body = @{
    'username' = $Script:PuppetConsoleUsername;
    'password' = $Script:PuppetConsolePassword;
    'redirect' = '/'
  }

glennsarti

Scenarios:

Default - No change to the TokenOperations.FoldableRegions metjhod

No Dupe - Removed the check for duplicate regions (Test case had none)

No Dupe or Sort - Removed the check for duplicate regions and removed the region sorting

FOLDABLEREGIONS ... - These metrics came from calling the FoldableRegions method

glennsarti

# Copy the source files

$WIX = 'C:\Program Files (x86)\WiX Toolset v3.11'

& robocopy "C:\Source\VanagonSource\SourceDir" "C:\Source\Vanagon\SourceDir" /s /e /copy:dat /r:1 /w:1 /MIR
& robocopy "C:\Source\VanagonSource\wix" "C:\Source\Vanagon\wix" /s /e /copy:dat /r:1 /w:1 /MIR
& cmd /c del C:\Source\Vanagon\*.* /q

Push-Location C:\Source\Vanagon

glennsarti

Date - 21 Jun 2019

Thankyou

Firstly, thankyou for testing this out for me!!

What is this?

The install/uninstall/upgrade process for PDK can be very slow on Windows, particularly on VMs and AntiVirus products. So as part of https://tickets.puppetlabs.com/browse/PDK-1360 we looked at how to make the MSI experience much faster. After much work

glennsarti

param($AppXID)
$AppXPackage = Get-AppxPackage $AppXID
$AppXManifest = Get-appxpackagemanifest $AppXPackage
$AppXModelID = $AppXPackage.PackageFamilyName + "!" + $AppXManifest.package.applications.application.id

$csharp = @"
using System;
using System.Runtime.CompilerServices;
using System.Runtime.InteropServices;
namespace RunAppX