PSDeploy version: 0.1.24
Powershell version: 5.1.14393.206
Example:

Deploy something {
    By FilesystemRemote {
        FromSource 'C:\testSource'
        To 'C:\testDest'
        WithOptions @{
            ComputerName = 'remoteHost'
        }
    }
}

Assuming remoteHost is real and you have credentials, calling Invoke-PSDeploy on this will output:

The term 'Invoke-Robocopy' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
+ CategoryInfo : ObjectNotFound: (Invoke-Robocopy:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
+ PSComputerName : remoteHost

I was able to fix this by simply adding 'Invoke-Robocopy' to $FunctionsToInject in PSDeploy/PSDeployScripts/FilesystemRemote.ps1.

I am working on adding a new deployment type which uses PowerShell direct for deployment to a VM (Server 2016) running on a Hyper-V host (Server 2016).

Hey Warren,

I've had a look at your PSDeploy docs and the actual code for Filesystem deployments and I believe both don't cover my user case. I want to copy a module to a file share as a user that has the required privileges. However my psdeploy script is being run in the context of my Gitlab CI runner which doesn't have access to the share.

The use case is as follows:

[Server with Gitlab CI runner] --Contoso\User--> [File server share\modules dir]

What would be your recommended approach to implement the copy job? Thanks in advance.

-Sebastian

I discovered when I try to use a UNC path for fromSource it error's out

My TestProject.PSDeploy.ps1

Deploy UniqueDeploymentName{ # Deployment name.
By FileSystem { # Deployment type.
FromSource '\ServerName\d$\Sandbox\PSDeploy\Workspace\Artifact\SomeFolder'
To '\ServerName\d$\Sandbox\PSDeploy\Server001\D\App\Somefolder'
Tagged DevFrontend
WithOptions @{
Mirror = $True
}
}
}

The error:

Source : Microsoft.PowerShell.Core\FileSystem::\ServerName\d$\Sandbox\PSDeploy\Workspace\Artifact\SomeFolder'

This works when I use dot sourcing and local path. I found in Get-PSDeployment.PS1 you are using
( Resolve-Path $Source ).Path

This is what is adding the Microsoft.PowerShell.Core\FileSystem:: in front of the UNC path. I added this around it to get around it.

                    If ( $Source -like '\\*')
                        {
                        $LocalSource = $Source
                        }
                    Else
                        {
                        $LocalSource = ( Resolve-Path $Source ).Path
                        }

I am sure this is a better fix for this but wanted to point this out just in case anyone else was running into this issue.

Opening an issue to discuss this resource. Per this PR, goal would be to push application of the DSC configs.

• If folks start contributing to this, might be easier to have a separate organization. Created it, just need to migrate and update various links.
• Not a fan of GitHub Wiki (open to all, or open only to collaborators). Will likely spin up a separate docs repo using readthedocs, mkdocs, or github pages, to allow folks to contribute without being given collaborator privileges
• Logo. Or not. It seems like everything has a logo these days. I'm picky, but not very creative. A bad combo for logo design : )

Invoke-PSDeployment allowed the specification of arbitrary parameters for specific DeploymentTypes. For example, the FileSystemRemote deployment type would take a credential, among other parameters (example here).

We also had the concept of Options in the yml configurations. We opted to keep these separate, given that deployment parameters could be defined using PowerShell code, whereas Options in the yml had to be hard coded in yml, much less flexible.

With the new Invoke-PSDeploy method and the DSL it uses, we have access to PowerShell code. We need to either consolidate, or keep both available. I can see + and - to both...

I have an idea for a new deployment type that would deploy the given module into the PSGallery or to any other NuGet-based repository. This would basically be a wrapper around Publish-Module.

I'll gladly create this deployment type if people think it makes sense.

Deploy MyModuleToPSGallery {
    By NuGet {
        FromSource '.\MyModule'
        To 'PSGallery'
        Tagged Prod
        WithOptions @{
            ApiKey = '<my_api_key>'
            IconUri = ''
            LicenseUri = ''
            Name = ''
            ProjectUri = ''
            ReleaseNotes = ''
            Version = ''
            Tags = @{}
        }
    }
}

Enhancement for deployment type : Scheduled Task. This could be a WithOptions - Option on the FileSystem and RemoteFileSystem Deployment Types.

By FileSystem MyTask {
        FromSource MyTask.ps1
        To \\ServerY\c$\Tasks  
        WithOptions @{
            ScheduledTask = 'true'
            ComputerName = 'ServerY',
            RunAsUser = 'System',
            TaskName = 'MyTask',
            TaskRun = '"C:\Tasks\Mytask.ps1"',
            Schedule = 'Monthly',
            Modifier = 'second',
            Days = 'SUN',
            Months = '"MAR,JUN,SEP,DEC"',
            StartTime = '13:00',
            EndTime = '17:00',
            Interval = '60' 
        }
 }    

I've tried to implement the release pipeline found here http://ramblingcookiemonster.github.io/PSDeploy-Inception/ and I've got an interesting problem.

When I push to my master branch with !deploy in the commit message, everything works well excepted that the module version is not handled properly on the Powershell Gallery. For example, if the version of the module on the gallery is 0.7.0, the next version deployed by the pipeline will be the 0.7.1 no matter what version is in the module manifest...

Any ideas about that?

Here are 3 tests I made to test it.

Deploy {
    By Filesystem {
        FromSource 'C:\Github\PSDeploy\PSDeploy'
        To 'C:\TestPSDeploy\Test Space\PSDeploy'
        Tagged Space
        WithOptions @{
            Mirror = $true
        }
    }

    By Filesystem {
        FromSource 'C:\Github\PSDeploy\PSDeploy'
        To 'C:\TestPSDeploy\Test Space\PSDeploy\'
        Tagged SpaceBackSlash
        WithOptions @{
            Mirror = $true
        }
    }

    By Filesystem {
        FromSource 'C:\Github\PSDeploy\PSDeploy\'
        To 'C:\TestPSDeploy\BackSpash\PSDeploy\'
        Tagged BackSlash
        WithOptions @{
            Mirror = $true
        }
    }
}

I've encountered this in another module of mine, and currently working on adding the fix over. Will try to add a few Pester tests too to make sure it is handling them properly.

The choco deployment is sweet!

The nice thing about Chocolatey is you can manage your api keys for pushing in Chocolatey configuration itself. So you can push to multiple sources all with different apikeys if you manage the api keys in choco config itself.

I'd prefer a warning that apikey was empty and the sources are expected to be configured using choco apikey and that each source must match a source that is there, but try to run the command without the api key being passed for each source.

This allows you to hit multiple sources without using the same api key.

cc @Koshersalt

The official docs site seems to be out of date. For example, while a document for the PSGalleryScript deployment option was added a year ago, it does not exist in the published docs.

I see we're using RTD for docs hosting, perhaps the link to the project source is broken somehow?

Please find below the documentation I've written for a new deployment type vSphereOVF. Feel free to give any feedback ! (cc to VMware folks @lamw @alanrenouf)

Deployment script can be found here.

OVF or OVA are a standard way to package virtual machines. vSphereOVF will allow you to easely deploy an OVF/OVA into a VMware vSPhere infrastructure.

Prerequisites

Before deploying you'll need to:

• Install VMware PowerCli
• Connect to a vCenter server or an ESXi server with the command Connect-VIServer

Simple Example

Here is an example deployment config:

Deploy 'MyOVF' {
    By vSphereOVF {
        FromSource 'C:\MyOVF.ovf'
        To 'esxi.example.com'
        Tagged 'Prod'
        WithOptions @{
            Name = 'VM01'
            Datastore = 'DATASTORE01'
            OvfConfiguration = @{
                'NetworkMapping.VM Network' = 'Production'
            }
            PowerOn = $true
        }
    }
}

Let's explain the different parameters:

• FromSource specifies the path to the .ovf or .ova file
• To specifies the esxi server used as a target
• Name specifies the name of the virtual machine
• Datastore specifies on wich datastore the VM will be stored. If not provided, the datastore with the largest free space will be selected
• OvfConfiguration specifies advanced configurations that will be used to deploy the virtual machine
• PowerOn specifies if the virtual machine should be powered on after the deployment

Real Example

Here is an example to deploy a VMware vCenter Virtual Appliance (VCSA). More specific informations about the automated deployment of a VCSA can be found here

Deploy 'VCSA' {
    By vSphereOVF {
        FromSource 'D:\VMware\vSphere\vSphere 6.0\vCenter\VCSA\U2\vmware-vcsa.ova'
        To 'esxi.example.com'
        Tagged 'Prod'
        WithOptions @{
            Name = 'VCENTER' # VM Name
            Datastore = 'SALLE1-DATASTORE02' # Datastore Name
            OvfConfiguration = @{
                'NetworkMapping.Network 1'                = 'Supervision' # vSphere Portgroup Network Mapping
                'DeploymentOption.value'                  = 'tiny' # tiny,small,medium,large,management-tiny,management-small,management-medium,management-large,infrastructure
                'IpAssignment.IpProtocol'                 = 'IPv4' # IP Protocol
                'guestinfo.cis.appliance.net.addr.family' = 'ipv4' # IP Address Family
                'guestinfo.cis.appliance.net.mode'        = 'static' # IP Address Mode
                'guestinfo.cis.appliance.net.addr'        = '192.168.1.2' # IP Address 
                'guestinfo.cis.appliance.net.pnid'        = '192.168.1.2' # IP PNID (same as IP Address if there's no DNS)
                'guestinfo.cis.appliance.net.prefix'      = '24' # IP Network Prefix (CIDR notation)
                'guestinfo.cis.appliance.net.gateway'     = '192.168.1.254' # IP Gateway
                'guestinfo.cis.appliance.net.dns.servers' = '192.168.1.1' # Comma separated list of IP addresses of DNS servers.
                'guestinfo.cis.appliance.ntp.servers'     = '0.pool.ntp.org' # Comma seperated list of hostnames or IP addresses of NTP Servers
                'guestinfo.cis.appliance.root.passwd'     = 'VMware1!' # Root Password
                'guestinfo.cis.appliance.ssh.enabled'     = 'True' # Enable SSH
                'guestinfo.cis.vmdir.domain-name'         = 'vsphere.local' # SSO Domain Name
                'guestinfo.cis.vmdir.site-name'           = 'site01' # SSO Site Name
                'guestinfo.cis.vmdir.password'            = 'VMware1!' # SSO Admin Password
            }
            PowerOn = $true
        }
    }
}

A user might expect the following to work, and display Var is 2:

$var = 2

Deploy Example {
    By Task One {
        "Var is $var"
    }
    By noop Two {
        FromSource MyModule
        To C:\PSDeployTo
    }
}

Currently, this will display Var is, given fun with scoping.

An ugly workaround would be to use environment variables, or script scope. This might be an acceptable solution given that tools like psake, the build script, or the CI/CD solution may already populate global or environmental variables:

$script:var = 2

Deploy Example {
    By Task One {
        "Var is $script:var"
    }
    By noop Two {
        FromSource MyModule
        To C:\PSDeployTo
    }
}

These both successfully display Var is 2, but are not very friendly or intuitive to the user.

Potential solution: Add code that extracts script scope variables into the current scope. This would be needed in DeploymentType scripts, and in Task based DeploymentTypes (perhaps we could inject it).

Am I missing anything? The examples above are running from the dev branch.

Hi,
in this file a bracket is missing : Deploy DeployMyModule

Using DependingOn results in a deployment order that is completely different from what I expected.

Consider the following psdeploy.ps1 file:

Deploy A {

    By Task Setup {
        FromSource {
            'Setup'
        }
    }

    By Task One {
        FromSource {
            'One'
        }
        DependingOn Setup
    }

    By Task Three {
        FromSource {
            'Three'
        }
        DependingOn Two
    }

    By Task Five {
        FromSource {
            'Five'
        }
        DependingOn Four
    }

    By Task Four {
        FromSource {
            'Four'
        }
        DependingOn Three
    }

    By Task Two {
        FromSource {
            'Two'
        }
        DependingOn One
    }

    By Task Teardown {
        FromSource {
            'Teardown'
        }
        DependingOn One, Two, Three, Four, Five
    }

}

I would expect the order of execution to be:

• Setup
• One
• Two
• Three
• Four
• Five
• Teardown

But what I get is:

C:\test> Get-PSDeployment -Path .\test.dependencies.psdeploy.ps1 | Select DeploymentName

DeploymentName
--------------
A-Five
A-One
A-Three
A-Two
A-Four
A-Teardown
A-Setup

C:\test> Invoke-PSDeploy -Path .\test.dependencies.psdeploy.ps1 -Force
Five
One
Three
Two
Four
Teardown
Setup

Version used:

C:\test> Get-Module PSDeploy

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     0.2.1      PSDeploy                            {By, DependingOn, Deploy, FromSource...}

Any objections to moving from Apache to MIT license? Always pick MIT nowadays, must have miss-clicked initially.

If I don't hear back in a few days, will make the swap.

Cheers!

Add pester-like Before and After functionality

after testing out the psdeploy cmdlet for deploying to the PSGallery I found it does not read or use the manifest version number when publishing to the gallery. Is there a built-in way to tell the cmdlet to read the manifest version # and use that instead of simply incrementing the minor version in the psgallery? It doesn't appear "Version" is a valid parameter that psdeploy would understand and pass down to the psgallery deployment step.

Hi,
For our project (hosted on github) we tag releases and each release has a unique version tag.

For instance:

• We commit multiple fixes/changes
• We then update & commit an updated module manifest version# (ex: v2.6)
• We create a pre-release that's tagged (ex: v2.6) and we publish a pre-release (we don't want this published by appveyor)
• Once we confirm the release we remove the 'draft' flag and "publish" the final tagged release on GitHub

What I'm trying to do is:

1. Only deploy Tagged Releases on GitHub (no matter what the tag and possibly based on a portion of the tag name)
2. Skip deployment when they're flagged as a pre-release
3. Only deploy when there is a tag AND when it's not a pre-release.

Is there a way to get the release properties (like release / pre-release) and the Tag name from GitHub? I tried seeing if there's a way to access these properties in deploy.psdeploy.ps1?

Thanks in advance for any pointers!

Add Pester tests for Invoke-PSDeploy and related functions.

PSGalleryModule is up and running, would be handy to have a PSGalleryScript to go along with it, for example:

Deploy SomeScript {
    By PSGalleryScript {
        FromSource SomeScript.ps1
        To 'PSGallery' #Optional, default to gallery
        WithOptions @{
            ApiKey = '<my_api_key>'
            Guid = '' # Ideally we avoid a new GUID for every deployment... require here or maybe look up in the gallery, generate if not found?
            # Other params, see New-ScriptFileInfo for examples
        }
    }
}

Tests for the FileSystem deployment type should not be in the Invoke-PSDeploy and the Invoke-PSDeployment test files.

We have a deployment option for PowerShell modules but not one for PowerShell scripts.
It would be useful to be able to publish scripts to a repository, especially internally.

This would allow us to ensure that maintenance scripts and the like are being updated from a trusted source in a sane, repeatable way - and where the scripts are discoverable and reviewable.

Hello Warren,

Any thoughts on if I passed -WhatIf to Invoke-PsDeploy and I've got an FS deployment will also show a preview of what will actually happen? Kinda test run. I believe it's similar to passing /L to Robocopy?

Thank you!

Based on the description in issue #3 (and I think I saw it elsewhere also, but cannot find that right now) I expected only deployments tagged with all specified tags, to be invoked when I call invoke-psdeploy with multiple tags. But my tests show that the opposite is the case. Apparently all deployments that have any of the specified tags are invoked (see attached gif)

Example usage:

Invoke-PSDeploy -Tag AzureStack, Prod

This would only kick off deployments with both the AzureStack, and Prod tags (I'm assuming 'and' is preferable to 'or', open to suggestions).

Missing or incomplete documentation:

• Readme.md
• Comment based help
• about_PSDeploy.help.txt

Similar to #72
Can we make the ApiKey parameter optional? Some repositories do not require a key, and this blocks me from being able to publish a module to our internal repository.

For that, the NuGetAPIKey parameter in the Publish-Module @params (Line 47 of PSGalleryModule.ps1) would need to be removed/modified.

Any thoughts on how you'd like to proceed?

Thanks!

I'm interested in trying to combine the work at lines 149 and 153 of:
https://github.com/RamblingCookieMonster/PSDeploy/blob/dev/PSDeploy/Invoke-PSDeployment.ps1

I believe this could be reduced to a single prompt. Is this agreeable or does this depart from a design vision?

Taking this as an example: https://ci.appveyor.com/project/gaelcolas/chocolatey/build/1.0.6/artifacts

With the following Deploy config:

if(
    $env:ProjectName -and $ENV:ProjectName.Count -eq 1 -and
    $env:BuildSystem -eq 'AppVeyor'
   )
{
    Deploy DeveloperBuild {
        By AppVeyorModule {
            FromSource $(Get-Item ".\BuildOutput\$Env:ProjectName")
            To AppVeyor
            WithOptions @{
                Version = $env:APPVEYOR_BUILD_VERSION
            }
        }
    }
}

The module zip which is built from .\BuildOutput\$Env:ProjectName is perfect, but the NuPkg is done from .\BuildOutput\ including lots of unwanted files.

Having trouble with the robocopy code when From is a PSDrive. At the point where Resolve-Path is called and the path's my code was using are converted, robocopy appends the new path values to the working directory causing the deploy to fail.

Line:
Invoke-Robocopy#L114

Reproduce code:

$LogStaging      = "$StagingDir\Logs"

# Build target deployment paths
$SystemDrives = @()
foreach ($Comp in $ComputerName) {
    New-PSDrive -Name "$($Comp.Replace(".",''))--SystemDrive" -PSProvider FileSystem -Root \\$ComputerName\C$ -Credential $LocalAdministrator
}

# Remote module paths
$LogPathDrives = Get-PSDrive | where {$_.Name -like "*--SystemDrive"} | foreach { # select -ExpandProperty Name | foreach {
    # ( "$_`:\Staging\Logs")
    Join-Path -Path $_.Root -ChildPath "Staging\Logs"
}

#PSDeploy File Code
Deploy LogScriptCollection {
    By  FileSystem LogsResults {
        FromSource $LogPathDrives
        To $LogStaging
        Tagged Prod, Logs
        WithOptions @{
            SourceIsAbsolute = $true
        }
    }
}

Hi,

i'am currently adding support for Node and IISSites to deploy some solutions. Is that of any intrest for you? If so then I will create some pull requests as soon as they are complete.

My Node File
My IIS File

Hi!

So, based on the confusion, mostly induced by poor documentation and not swapping the default branch, branches have been a bit of a pain - PRs submitted to both master and dev, and I don't want to scare people off by telling them to switch branches.

Rather than continue to poorly execute rebase/merge operations, or get stricter, I'm trying to think of any downsides to just switching to a master branch + feature branch model, kill the dev branch and adjust documentation. If you have any concerns over this, hit me up, otherwise, will make the switch tomorrow/Saturday (plenty of time for responses, right? : P)

Cheers!

While trying to use PSDeploy on Linux (Ubuntu 16.04) the deployment fails because it cannot find certain files. The issue seems to stem from a case mismatch.
File: this.PSDeploy.ps1

Deploy SomeDeploymentName {
    By noop {
        FromSource MyModule
        To C:\PSDeployTo
        WithOptions @{
            Mirror = $True
            Environment = $Environment
            StringParameter = "This String"
        }
    }
}

Expected: no errors.

Actual:

PS /home/juan> Invoke-PSDeploy -Path ./this.PSDeploy.ps1                                                
Get-PSDeploymentScript : Could not find path '/usr/local/share/powershell/Modules/PSDeploy/0.2.3/PSDeployScripts/Filesystem.ps1' for deployment Filesystem. Origin: Filesystem.ps1
At /usr/local/share/powershell/Modules/PSDeploy/0.2.3/Public/Invoke-PSDeploy.ps1:202 char:30
+         $DeploymentScripts = Get-PSDeploymentScript
+                              ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-PSDeploymentScript

Get-PSDeploymentScript : Could not find path '/usr/local/share/powershell/Modules/PSDeploy/0.2.3/PSDeployScripts/noop.ps1' for deployment Noop. Origin: noop.ps1
At /usr/local/share/powershell/Modules/PSDeploy/0.2.3/Public/Invoke-PSDeploy.ps1:202 char:30
+         $DeploymentScripts = Get-PSDeploymentScript
+                              ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-PSDeploymentScript

Get-Item : Cannot find drive. A drive with the name 'C' does not exist.
At /home/juan/this.PSDeploy.ps1:3 char:24
+         if($Explorer = Get-Item C:\Windows\explorer.exe)
+                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (C:String) [Get-Item], DriveNotFoundException
+ FullyQualifiedErrorId : DriveNotFound,Microsoft.PowerShell.Commands.GetItemCommand


Processing deployment
Process the deployment 'SomeDeploymentName'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): Y
Get-PSDeploymentScript : Could not find path '/usr/local/share/powershell/Modules/PSDeploy/0.2.3/PSDeployScripts/Filesystem.ps1' for deployment Filesystem. Origin: Filesystem.ps1
At /usr/local/share/powershell/Modules/PSDeploy/0.2.3/Public/Invoke-PSDeployment.ps1:157 char:31
+             $DeploymentDefs = Get-PSDeploymentScript
+                               ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-PSDeploymentScript

Get-PSDeploymentScript : Could not find path '/usr/local/share/powershell/Modules/PSDeploy/0.2.3/PSDeployScripts/noop.ps1' for deployment Noop. Origin: noop.ps1
At /usr/local/share/powershell/Modules/PSDeploy/0.2.3/Public/Invoke-PSDeployment.ps1:157 char:31
+             $DeploymentDefs = Get-PSDeploymentScript
+                               ~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-PSDeploymentScript

Sort : The term 'Sort' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
At /usr/local/share/powershell/Modules/PSDeploy/0.2.3/Public/Invoke-PSDeployment.ps1:158 char:69
+ ...  $TheseDeploymentTypes = @( $Deployment.DeploymentType | Sort -Unique ...
+                                                              ~~~~
+ CategoryInfo          : ObjectNotFound: (Sort:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

PS /home/juan>

I would like to be able to set the ReleaseNotes when publishing. I wanted to offer a suggestion and see what others though and if I was overlooking something. I am new to publishing to the Gallery and about to publish my first, so I wanted to make sure I wasn't overlooking something before going further with the idea. Keith Hill uses something like this in his Publish-Module example template in Plaster.

if ($ReleaseNotesPath) {
    $Params['ReleaseNotes'] = @(Get-Content $ReleaseNotesPath)
}

It might require adding a new Environment variable to BuildHelpers or maybe a new param on the PSGalleryModule.ps1. I have not looked that far ahead since I wanted to make sure I wasn't overlooking anything. I know there are some odd issues related to psd1 or similar.

When testing your code in AppVeyor I received the following warning:

$ENV:BHPSModulePath is deprecated and will be removed July 1st, 2017
ACTION REQUIRED: Please replace $ENV:BHPSModulePath with $ENV:BHModulePath wherever you use it

Currently your deploy.psdeploy.ps1 file uses the deprecated variable and needs updating.

I'd love to see functionality like Pester's -EnableExit parameter. This is one of the ways Pester can tell CI tools if any of the tests failed. In the same way, CI tools should be able to know if the deployment step failed for some reason.

This would require additional error trapping and things like checking the exit code after calling robocopy.exe.

I'm interested in contributing, but also pretty new to participating in other people's projects, so I figured I'd put this out there to see if there's even interest in including such functionality.

@RamblingCookieMonster , I had to use the CopyVMFile deployment sometime last week to copy few files to a VM running on Hyper-V 2012 R2 and it failed.
So, I decided to work a bit more on it to support both .yml and .psdeploy.ps1 deployments.

Also added documentation for the deployment.
Created a PR for the same #65

These test deployments ...

Deploy Test {
    By FileSystem  {
        FromSource  'test.txt'
        To 'C:\Does\Not\Exist\'
    }
}

and

Deploy Test {
    By FileSystem  {
        FromSource  'test.txt'
        To 'C:\Does\Not\Exist\test.txt'
    }
}

... both throw an exception when the destination folder does not exist, due to limitations of the Copy-Item cmdlet.

One way around the issue

Try {

    Copy-Item -Path $Map.Source -Destination $Target -Force

}
Catch [System.IO.IOException] {

    $NewDir = $Target
    if ($NewDir[-1] -ne '\')
    {
        $NewDir = Split-Path -Path $NewDir
    }
    $null = New-Item -ItemType Directory -Path $NewDir
    Copy-Item -Path $Map.Source -Destination $Target -Force

}

(opted for the try/catch approach to not have to do a test-path for each file)

I can go ahead and submit a pull request for this, but wanted to run it by you first in case you have reasons for not handling non-existing folders in the first place

I've been trying to build up examples, scenarios, and feature illustrations in the Wiki, but the comment-based help and about help could use some work

I'm working on adding a SCP deployment type using Posh-SSH.

It might be helpful to abstract out module deployments (or maybe more generic?) to AppVeyor. This way, we could allow deployments of dev / latest builds to AppVeyor, similar the DSC resources and a few other Microsoft repos.

Not tied to the name or any specifics, just spitballing:

Deploy MyModuleToAppveyor {
    By AppveyorModule {
        FromSource MyModule
        Tagged Dev
    }
}

While working on a new PSDeployment type for Scheduled task, came across this limitation with PSDeploy.

If there are parameter sets defined in the PSDeployScript e.g ScheduledTask.ps1, then Invoke-PSDeploy issues the warnings saying the parameters are not valid

[CmdletBinding(DefaultParameterSetName='SimpleTask')]
param(
    [ValidateScript({ $_.PSObject.TypeNames[0] -eq 'PSDeploy.Deployment' })]
    [psobject[]]$Deployment,

    # Specify the Computer name 
    [String]$ComputerName,
)
$ComputerName

Below is the sample PSDeploy.ps1 used :-

Deploy DeploymentToServer2016VM {
    $Credential = New-Object -TypeName PSCredential -ArgumentList 'Administrator',$(ConvertTo-SecureString -String 'p@ssw0rd#123' -AsPlainText -Force) 

    By ScheduledTask DeploySchedTask {
        FromSource 'MyTask.ps1'
        #To 'C:\PSDeployTo'
        Tagged Dev
        WithOptions @{
            ComputerName = 'WDS'
            Credential = $Credential
            RunAsUser = 'System'
            TaskName = 'MyTask'
            TaskAction = '"C:\Tasks\Mytask.ps1"'
            Once = $true
            At = $((Get-Date).AddMinutes(5))
        }
    }
}

The parameters are not even splatted to the deployment script.

PS C:\PSDeployFrom> Invoke-PSDeploy .\ScheduledTask.psdeploy.ps1 -Force
WARNING: WithOption 'RunAsUser' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'Once' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'ComputerName' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'At' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'TaskName' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'Credential' is not a valid parameter for 'ScheduledTask'
WARNING: WithOption 'TaskAction' is not a valid parameter for 'ScheduledTask'

Hi,

it took me a while to figure out how I can use tasks to set Enviroment Variables which can be used during the whole deployment. I first tried the following

Deploy {

    By Task Set-Enviroment {        
     	$Env:Enviroment = "Dev"
        $Env:InstPath = "C:\Web\Precompiled\$Env:Enviroment.Website"        
        Tagged Dev
    }
    By Noop Test {
    	FromSource dist
    	To $Env:InstPath
    	DependingOn Set-Enviroment
    }
}

unfortunately this did not work out "By Noop Test" did not know anything about my enviroment variables. What worked out for me is to put the Enviroment variable within the task into the FromSource part like that:

Deploy {

    By Task Set-Enviroment {        
    	FromSource {
    		$Env:Enviroment = "Dev"
        	$Env:InstPath = "C:\Web\Precompiled\$Env:Enviroment.Website"        	
    	}     	
        Tagged Dev
    }
    By Noop Test {
    	FromSource dist
    	To $Env:InstPath
    	DependingOn Set-Enviroment
    }
}

The documentation does not say anything about that. I would like to complete the documentation but I dont know how it acutally is intended to be working? Is my approach by putting it into the FromSource correct?

Hi there,

This looks like a pretty awesome tool 👍

As well as PSGallery and Artifactory I could see a pretty compelling use case for being able to deploy scripts to an Octopus Deploy package. As of version 3.3 Octopus supports running powershell scripts from within a package.

The use case here would be that you have source controller powershell scripts that you want Octopus to execute during a deployment. Does this sound like something worth implementing?

It would be helpful to allow setting up order of operations.

For example, deployment 1 might create an archive file, which deployment 2 delivers to an appropriate location.

Ignore these, using them in the GitHub page post : )

In some cases, deployments may benefit from running in parallel. It might help to add a 'parallel' switch that invokes deployments in parallel via runspaces.

This may be as simple as inserting runspace handling for this loop in Invoke-PSDeploy

I'm game for any implementation. Depending on PoshRsJob, adding a small handler (e.g. Invoke-Parallel, but maybe stripped down), or even our own handling.

Cheers!

Hypothetical scenario:

Source is Tasks\Blah.ps1
The path in the deployment root is C:\root\Tasks\Blah.ps1

If PSDeploy runs, and the current location is C:\root, PSDeploy will test-path 'Tasks\Blah.ps1', succeed, and set the source to 'Tasks\Blah.ps1', rather than the path it resolves to.