Add integration tests. For the most integration testing part, Remotely can be tested on the local machine, since it uses PS Remoting which we can be manipulated as per the requirement.

Serious bug, this was never used but we should be able to pass a hashtable Key-Value pairs to the -ArgumentList to PSRemotely and have access to the variables with name (key) inside the underlying PSSessions to the remote nodes.

Invoke-PSRemotely should do the following:

• look for .PSRemotely.ps1 files in the current location (recursively) if nothing specified.
• only accept .PSRemotely.ps1 files as input to the -ScriptFile parameter.

If you create a Example.PSRemotely.ps1 file with below content.

param($Credential)

# Configuration Data
$ConfigData = @{
	AllNodes = @(
		@{
			NodeName='*';
			DomainFQDN='dexter.lab';
            Credential = $Credential
		},
		@{
			NodeName="$env:ComputerName";
			ServiceName = 'bits';
			Type='Compute';

		},
		@{
			NodeName='localhost';
			ServiceName = 'winrm';
			Type='Storage';
		}
	)
}

# Remotely tests
Remotely -ConfigurationData $ConfigData {
	Node $AllNodes.Where({$PSItem.Type -eq 'Compute'}).NodeName {
		Describe 'Bits Service test' {
			
			$Service = Get-Service -Name $node.ServiceName # See the use of $node variable here
			
			It "Should have a service named bits" {
				$Service | Should Not BeNullOrEmpty
			}
			
			it 'Should be running' {
				$Service.Status | Should be 'Running'
			}
		}		
	}
}

This fails with the following error :

Reason -:
Within the Remotely function, we take config data and create the $ConfigData.AllNodes . Since each node is getting a credential object from the configuration data.

Now the logic is to pick up the credential object from the configuration data to start the PSSession, node properties (including Credential object) is being added as an argumentlist to the PSSessionOption.

Fix -:
Remove the Credential attribute from the node data.

Working on this branch name feature_mkdocs created locally.

Passing argument list to populate the Node variable in the PSRemoting session has limitations, as complex configuration data can not be passed. See below that passing nested arrays or hashes fails if we continue this way:

@{
	AllNodes = @(
		@{
			NodeName='*';
			DomainFQDN='dexter.lab';
			Networks = @( # nested array of hashes this can not be passed using application arguments
				@{
					Name = 'ConvergedNetwork1'
					VlanID = 101
				},
				@{
					Name = 'ConvergedNetwork2'
					VlanID = 102
				}
			)
		},
		@{
			NodeName="Node1";
			ServiceName = 'bits';
			Type='Compute';

		},
		@{
			NodeName='Node2';
			ServiceName = 'winrm';
			Type='Storage';
		}
	)
}

Create a class which represents a PSRemotely node.
Now this will help us support different providers e.g. PSRemoting, Azure, AWS etc.
This provider will have a contract to return a SessionHashtable.

Now the class for the PSRemotely node will use this, agnostic of where the Node sits on.

As part of the integration and unit tests, we create PSSession to the localhost to test things.
These are failing. Created a simple POC for this

Code - https://github.com/DexterPOSH/test/blob/master/build.ps1

Appveyor Build details - See the build messages

In my opinion,

When an user use for example get-command -module remotely it should only return Remotely as other functions are only used in the module. What do you think about it ?

In the v1.0.3 release, found out that the Start-RemotelyJobProcessing function started throwing below error. This indicates the flaw in logic where the Remotely job is being processed more than once.

PS C:\Users\Administrator\Desktop> $Error[3]
Add-Member : Cannot add a member with the name "__Streams" because a member with that name 
already exists. To overwrite the member anyway, add the Force parameter to your command.
At C:\Program Files\WindowsPowerShell\Modules\PSRemotely\1.0.3\Private\Helper.ps1:35 char:20
+ ... putStream = Add-Member -InputObject $outputStream -PassThru -MemberTy ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (@{TagFilter=Sys...et=S2D-Node-01}:PSObject) [ 
   Add-Member], InvalidOperationException
    + FullyQualifiedErrorId : MemberAlreadyExists,Microsoft.PowerShell.Commands.AddMemberComma 
   nd

This is causing confusion, we can start this once the tests are in place so that we do not break anything.

Is the Context block 'If all the required modules present on the Remotely node, and PSRemotely path is NOT present' required? Because, if the PSRemotely path is not present, modules also won't be present, as they resides inside that directory.

The following code isn't working on my desktop.

Remotely {
    Node localhost {
        Describe 'Bits Service test' {

            $BitsService = Get-Service -Name Bits

            It "Should have a service named bits" {
                $BitsService | Should Not BeNullOrEmpty
            }

            it 'Should be running' {
                $BitsService.Status | Should be 'Running'
            }
        }       
    }
}

i've got an error asking me to fill some test parameter.

any idea ?

While wrapping the Pester tests in PSRemotely, the test name needs to be at the first position mentioned like below :-

PSRemotely {
    Node AD {
        Describe 'testIPconfig' {
             # Tests here
        }
    }
}

At the moment for specifying tags, one has to use the below :-

PSRemotely {
    Node AD {
        Describe 'testIPconfig' -Tag DummyTag {
             # Tests here
        }
    }
}

If anything else then above is specified then parsing the Describe block for the test name fails. For example below fails :-

PSRemotely {
    Node AD {
        Describe -name 'testIPconfig'  {
             # Tests here
        }
    }
}

Below format also fails :-

PSRemotely {
    Node AD {
        Describe -Tag 'dummytag' 'testIPconfig' {
             # Tests here
        }
    }
}

Add a PITCHME.md for integrating with https://gitpitch.com.
Also, add the badge.

While trying to debug what ops validation test failed on the remote node, one usually has to reference the $PSRemotely.SessionHashtable.

Write a wrapper function, which should auto-complete the remote nodes names for the opened PSSession used by PSRemotely and drops into that remote PSSession.

Is there any timeout for these jobs or it can go to infinite in worst case ?

PSRemotely dumps the .<Test_name>.tests.ps1 file on the remote node and also generates a Nunit style XML result file for the pester tests run.
As per the enhancement #48 , all the files will give preference to using NodeName for the tests and XML file.
But there is a gotcha with using NodeName here since the NodeName can have illegal filename characters in it.
Now, this bug uncovered in the integration tests for using IPv6, where the node name was '::1' and when dumping the files containing the nodename the error of an invalid character was thrown.

Using a .psd1 file to pass the configuration data fails with PSRemotely.

Wishlist item :

• Integrate the remote ops validation framework (PS Remotely) to use JEA endpoints.

As per #52 , a debug function to drop into underlying PSSession used for invoking pester will be created.
Inject a function named Invoke-PSRemotely in this underlying function which sort of takes care of invoking the ops validation on the remote node e.g. if the configuration data was passed then this should dynamically pass the $node as an argument to Pester etc.

Some of the assertions are failing now with Pester v4. See the build here:
https://ci.appveyor.com/project/DexterPOSH/psremotely/build/1.0.52

When attempting to perform tests against computers that may be in a different Active Directory domain (isolated lab environment), then name resolution may not work from PSRemotely host machine. Ideally, I would like to be able to use the source configuration document used to deploy the lab, to be used by PSRemotely to run post deployment/operational tests.

Take the following configuration as an example:

# Configuration data
$ConfigData = @{
	AllNodes = @(
		@{
			NodeName='*';
			DomainFQDN='dexter.lab';
		},
		@{
			NodeName="Compute-11";
			ServiceName = 'vmms';
			Type='Compute';
			IPAddress = '192.168.1.2';
		},
		@{
			NodeName='Storage-12';
			ServiceName = 'bits';
			Type='Storage';
			IPAddress = '192.168.1.3';
		}
	)
}

# PSRemotely tests
PSRemotely -ConfigurationData $ConfigData {
	Node $AllNodes.Where({$PSItem.Type -eq 'Compute'}).NodeName {
		Describe 'Bits Service test' {
			
			$Service = Get-Service -Name $node.ServiceName # See the use of $node variable here
			
			It "Should have a service named bits" {
				$Service | Should Not BeNullOrEmpty
			}
			
			it 'Should be running' {
				$Service.Status | Should be 'Running'
			}
		}		
	}
}

I would like to be able to instruct PSRemotely to connect using the node's IPAddress node parameter, not the node name. In Lability there is a -PreferNodeProperty <string> parameter (not sure that's the best name) that instructs Lability to use the node's IPAddress property and not the node's name for connectivity.

Is this something that would be of benefit to add? if so, what needs to be done to implement it?!

At the moment, PSRemotely bootstrap nodes (makes them ready for ops validation) in sequential order.
Add the enhancement of bootstrapping them in parallel.

Hi,
running a simple test on a Server 2008R2 node produces following error:

VERBOSE: Helper.ps1 - Start-RemotelyJobProcessing - LineNo : 169 - PSRemotely job finished for Node ->
test03.xxx.de. Processing it now.
VERBOSE: Helper.ps1 - ProcessRemotelyOutputToJSON - LineNo : 170 - Cannot validate argument on parameter
'testResult'. The argument is null or empty. Provide an argument that is not null or empty, and then try the
command again.
VERBOSE: Invoke-PSRemotely.ps1 - Invoke-PSRemotely - LineNo : 202 - Error occurred in test script
'C:\PSRemotely Tests\Tests\Test.PSRemotely.ps1 -> at ProcessRemotelyOutputToJSON, C:\Program
Files\WindowsPowerShell\Modules\PSRemotely\1.0.3\Private\Helper.ps1: line 68

Running the same test against a Server 2012R2 node results in no errors.
Both have WMF updated to version 5.1.

Move all build related code into a folder named Build under the ProjectRoot.

Extending the bootstrapping process should be easy. What I mean by that is you should be able to place a customstep.ps1 in say the bootstrap folder somewhere under PSRemotely. This customstep.ps1 should implement a Test-* and Set-* function which will be taken by PSRemotely and executed on the PSRemotely nodes during the bootstrapping.

Also surfacing this option in the PSRemotely.json would be a better idea.

TODO - instead of the $env:computername , the node name defined in the environment config data should flow down for the *.Tests.ps1 file dumped on the remote node, Also the NunitXML report should use the node name.

This would be helpful when using report unit for the report creation.

• Scenario1 - Static hardcoded infra tests
  Try enabling a scenario where someone already has ops validation tests written e.g. WebServer.tests.ps1.
  These are hardcoded with the values inside the tests.
  PSRemotely should allow targeting the tests on the remote node using -Computername parameter?

• Scenario2 - Using $Node inside the tests to abstract static data.
  Allow execution of the tests to be targeted to all the nodes specified in configuration data.
  While invoking tests on the nodes $Node will be passed inside the tests.

There are two ways to let PSRemotely know which credentials to use to connect to the remote node.

• Using Credential hash
• Specifying Credential in the Configuration data

There is a downside to the second approach, it only looks for the attribute named credential (constraint on the name to be specific). Also if both credential hash and the credential attribute are present, the latter gets precedence.

Based on @iainbrighton's idea of using PreferNodeProperty, refer the issue for the idea -> #47.

Can we extend the same behavior for the credentials too? Would it make more sense this way? I think so.

Note - This would be a breaking change if anyone is using PSRemotely that way 😆.

On the machine from which Remotely is fired, look at setting up a Nuget repo.
This will help in resolving dependencies on the remotely nodes.

Create a PNG file for the PSRemotely logo. Edit the docs as well.

Add more unit tests. Code coverage threshold 70%.

Node function just copies all the files placed in the artefacts folder at the moment.
It should actually only pick up files mentioned in the 'ArtefactsRequired' field of the Remotely.Json.

line 87 , Node.ps1

# copy/overwrite the artefacts on the remotely nodes
# TODO - Read the artefacts required from the $Remotely before copying them
Write-VerboseLog -Message "Copying artefacts on Node -> $nodeName"
Copy-Item -Path "$PSScriptRoot\..\Lib\Artefacts\*" -Destination "$($Remotely.RemotelyNodePath)\Lib\Artefacts" -Force -Recurse -ToSession $session 

With the current implementation of PSRemotely, the required modules and required artefacts are assumed to be the same.

For Example - if a Manifest.xml is set to be one of the required artefacts then it gets copied to all the nodes.

Now this served our purpose well in a Remote ops validation of an Engineered solution but PSRemotely should have the ability to have Node specific or a group specific way of supplying these configurations.

This would get aligned well, when we start using classes.

These will be added as tests for the Public funtions (only at the moment), tests created using the PesterHelpers module

This one is not completely ready. Want the ability to specify tags to PSRemotely while invoking it.

Invoke-PSRemotely -Script S2Dvalidation.PSRemotely.ps1 -Tag VMMReadiness

Now the above should flow down the tag to the remote nodes and only run ops validation tests marked with the same tag.