ramblingcookiemonster/buildhelpers

Helper functions for PowerShell CI/CD scenarios

BuildHelpers

This is a quick and dirty PowerShell module with a variety of helper functions for PowerShell CI/CD scenarios.

Many of our build scripts explicitly reference build-system-specific features. We might rely on $ENV:APPVEYOR_REPO_BRANCH to know which branch we're in, for example.

This certainly works, but we can enable more portable build scripts by bundling up helper functions, normalizing build variables, and avoiding build-system-specific features.

Pull requests and other contributions welcome!

Instructions

# One time setup
    # Download the repository
    # Unblock the zip
    # Extract the BuildHelpers folder to a module path (e.g. $env:USERPROFILE\Documents\WindowsPowerShell\Modules\)

    #Simple alternative, if you have PowerShell 5, or the PowerShellGet module:
        Install-Module BuildHelpers

# Import the module.
    Import-Module BuildHelpers

# Get commands in the module
    Get-Command -Module BuildHelpers

# Get help
    Get-Help Get-BuildVariable -Full
    Get-Help about_BuildHelpers

Examples

Get Normalized Build Variables

Get-BuildVariable

# We assume you're in the project root. If not, specify a path:
Get-BuildVariable -Path C:\MyProjectRoot

Get Project Name

We occasionally need to reference the project or module name:

Get-ProjectName

This checks the following expected file system organizations, in order:

(1) File structure:

• ProjectX (Repo root)
  • ProjectX (Project here)

Output: ProjectX

(2) File structure:

• ProjectX (Repo root)
  • DifferentName (Project here. tsk tsk)
    • DifferentName.psd1

Output: DifferentName

(3) File structure:

• ProjectX (Repo root)
  • ProjectX.psd1 (Please don't use this organization...)

Output: ProjectX

(5) File structure:

• ProjectWhatever (Repo root)
  • src (or source)
    • ProjectX.psd1

Output: ProjectX

(6) File structure:

• ProjectX
  • NoHelpfulIndicatorsOfProjectName.md

Output: ProjectX

Create Normalized Environment Variables

This runs a few commands from BuildHelpers module, and populates ENV:BH... variables

# Read the current environment, populate env vars
Set-BuildEnvironment

# Read back the env vars
Get-Item ENV:BH*

Here's an example, having run Set-BuildEnvironment in an AppVeyor project:

Update your FunctionsToExport

During the module authoring process, updating FunctionsToExport can be tedious, so many folks leave this set to '*', missing out on module auto-loading and other benefits.

To get the best of both worlds, use FunctionsToExport='*', and use Set-ModuleFunction in your build before deployment:

# Set your build environment (we use this to get psd1 path)
Set-BuildEnvironment

# Check current FunctionsToExport:
Select-String -Path .\PSSlack\PSSlack.psd1 -Pattern FunctionsToExport

    # PSSlack\PSSlack.psd1:61:FunctionsToExport = '*'

# Update the psd1 with Set-ModuleFunction:
Set-ModuleFunction

# Check FunctionsToExport again:
Select-String -Path .\PSSlack\PSSlack.psd1 -Pattern FunctionsToExport

    # PSSlack\PSSlack.psd1:61:FunctionsToExport = @('Find-SlackMessage','Get-PSSlackConfig','Get-SlackChannel','Get-SlackHistory','Get-SlackUser','New-SlackField','New-SlackMessage','New-SlackMessageAttachment','Send-SlackApi','Send-SlackFile','Send-SlackMessage','Set-PSSlackConfig')

Update your ModuleVersion

Typical examples take an existing PSD1 file and bump the module version from that. Not so helpful if you don't commit that version to Git: The next time you bump the version, you're bumping the original version.

# Get the latest version for a project
$Version = Get-NextNugetPackageVersion -Name $env:BHProjectName

# Update the module metadata with the new version - thanks to Joel Bennett for this function!
Update-Metadata -Path $env:BHPSModuleManifest -PropertyName ModuleVersion -Value $Version

Notes

Thanks to Joel Bennett for the ConvertTo-Metadata function that we use in Set-ModuleFunction!

buildhelpers's Issues

Update-MetaData adds empty line on each call.

Hi,

I use PoweShellBuild and Invoke-Build. When I invoke the task StageFiles, it calls Update-MetaData and I end up with one empty line added each time I call this task.

I did found Issue #27 , I will look at your commits around this time if it can help me solve the problem.

Thank you.

BHCommitMessage has extra space when used in AppVeyor

In AppVeyor the BHCommitMessage is generated by combining the variables:
"$env:APPVEYOR_REPO_COMMIT_MESSAGE $env:APPVEYOR_REPO_COMMIT_MESSAGE_EXTENDED"

But if the $env:APPVEYOR_REPO_COMMIT_MESSAGE_EXTENDED is empty (which it often is) then the commit message contains an extra space.

This isn't a major issue, but I was attempting to use a regex match ($env:BHCommitMessage -match ' Deploy!$') to detect a deploy commit, but couldn't figure out why this wouldn't work.

Might be worth trimming this value: https://github.com/RamblingCookieMonster/BuildHelpers/blob/master/BuildHelpers/Public/Get-BuildVariables.ps1#L153

"$env:APPVEYOR_REPO_COMMIT_MESSAGE $env:APPVEYOR_REPO_COMMIT_MESSAGE_EXTENDED".TrimEnd()

Alternately you could check to see if $env:APPVEYOR_REPO_COMMIT_MESSAGE_EXTENDED is empty before appending it and a space. I've worked around by TrimEnd() the value before using it.

Happy to submit a PR with a solution if you want?

Add 'Source' and 'src' as Project Folder Options

BuildHelpers should find projects placed inside a Source or src folder when looking for Project name.

Expected Behavior

When running Get-ProjectName with either of the project layouts below, the function should find and return the project name MyProject.

. MyProject
├── docs
├── Source
|   ├── MyProject.psd1
|   └── MyProject.psm1
├── build.ps1
├── psake.ps1

. MyProject
├── docs
├── src
|   ├── MyProject.psd1
|   └── MyProject.psm1
├── build.ps1
├── psake.ps1

Current Behavior

In both cases, Get-ProjectName writes a warning to the console and does not return a value.

WARNING: Could not find a project from C:\dev\MyProject

Possible Solution

Add logic to Get-ProjectName to handle projects which use the source-folder pattern.

Context

This is how I tend to organize my projects, without this update buildhelpers is only partially functional for me.

Your Environment

• Module version used: 0.0.28
• Operating System and PowerShell version: Windows 10, PowerShell 5.1

Tools for updating the repository

I have code for adding a tag to the git repository and to publish a github version (including attaching the zip of the packaged module).
Is this interesting for this module?

Release notes / Changelog commands?

Some discussion: RamblingCookieMonster/PSDeploy#37

Given that we already abstract out some PowerShell specific stuff, and have commands to work with module metadata (not markdown though...), this might be a good fit for commands like Get/Set-ReleaseNotes and Get/Set-Changelog (where release notes covers 'stuff consumers care about', and changelog is more descriptive / dev oriented)

Set-ModuleFinctions Error Handling Enhancment

Set-ModuleFunctions does not return the error from the $Powershell.Invoke on line 59.

Get-BuildEnvironment should expose commit hash

Currently, Get-BuildEnvironment exposes the current commit message as an environment variable, but not the commit hash. I feel like there may be value for certain pipelines in exposing the commit hash or shortened hash as another environment variable. For example, I am working on a pipeline that automatically takes any build that passes its tests, puts the shortened commit hash as the prerelease string, and then pushes it to my ProGet instance as a prerelease version.

Theoretically, this should be doable via git (git log -n 1 --format='%H') or exposed variables in most build systems (e.g. $env:APPVEYOR_REPO_COMMIT).

Set-ModuleFunctions change encoding to UTF8 without BOM

Set-ModuleFunctions in BuildHelpers change the manifest file encoding to UTF8 without BOM.

This is a problem, following the UseBOMForUnicodeEncodedFile PSScriptAnalyzer rule.

I verified that the cause is the version 0.8 of PoshCode Configuration Module.

I also verified that in the latest version of the Configuration module (version 1.0.2 ) this issue is solved (see commit).

Updating Configuration to latest version, this issue should be removed.

Set-ModuleFunctions: New line added to the end of ModuleManifest

Each time we run a build and process the module manifest with Set-ModuleFunctions a new line will be added to the end of the file, resulting in unnecessary commits.

Example commit:

jakkulabs/PowervRA@c99f58d

Build:

https://ci.appveyor.com/project/JakkuLabs/powervra/build/2.0.0.87

This happens locally and within appveyor (Both WMF 5)

I think this might be being caused by the Update-Metadata function? More research needed on my part, but if you have any more information that would be cool.

Step-ModuleVersion fails when there is no PrivateData node

Add BHIsPullRequest

Not sure if there is a reliable way to determine if a commit is a pull request from within all CI environments, but would like to see the option explored

Use case, I don't want to deploy on Pull requests, but I don't want disable the Pull webhook in GitHub

I have all my deploy logic in a psdeply script and would like to control deploy on pull request. Reason is appveyor does not resolve secrets on PR (for public repo anyways) and thus deploy can't work. (deploy to psgallery) <- I sometimes deploy stable (-dev##) versions to psgallery

Semi-unrelated: Is there a way to tell appveyor to not build a branch if there is a pull request open (I want to avoid the double build on PR update)

Add function: Get-ModuleFunctions, Update-ModuleFunctions

Exporting all functions allows a quick development cycle, but impacts performance and auto-loading in the resulting modules.

Ideally, one could export all functions from a module during the build process (Get-ModuleFunctions), and update the PSD1 before publishing it (Update-ModuleFunctions)

Unable to use functions behind proxy

Functions that require internet access (by using Invoke-RestMethod or Invoke-WebRequest) do not allow the user to provide additional parameters, such as -Proxy, etc.

This can be solved in many different ways:

1. Add the parameters to all (relevant) functions in the module so the parameter can be passed along
2. Grab the $PSDefaultParameterValues from the global scope

Get-BuildVariables fails if git is aliased to hub.exe

hub is a tool put out by github that adds capabilities to git. The recommended way to use hub is to alias git to hub.exe, so that it can transparently handle the things it knows how to handle, and just pass on any commands that it doesn't.

When executing Get-BuildVariables cmdlet the line that attempts to find the path to git.exe uses the Get-Command cmdlet. This will not work in cases where git is aliased as no Path property is returned.

A different approach that either finds git.exe directly by looking at paths in the PATH variable, or one that accepts an alias, may be needed to support this scenario on workstations.

While this error should rarely or never be encountered on the build servers this module is intended to be used on, it is also used on developer workstations where this error can reasonable be expected crop up once in a while.

Set-BuildEnvironment errors if git is not installed.

Related to #37
When using Set-BuildEnvironment to create the variables in a Linux container that does not have git installed the build script fails because git is not installed. I'm currently getting around it by installing git in a before_script, but that should not be necessary, since I don't use git in these tasks. An option to omit the git check should enable us to not have to install git in order to use this function.

Setting Build Variables
ERROR: The term 'git' 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 /root/.local/share/powershell/Modules/BuildHelpers/1.0.1/Public/Get-BuildVariables.ps1:78 char:21
+         $GitPath = (Get-Command $GitPath)[0].Path
+                     ~~~~~~~~~~~~~~~~~~~~
Build FAILED. 0 tasks, 1 errors, 0 warnings 00:00:12.6075315
Get-Command : The term 'git' 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 /root/.local/share/powershell/Modules/BuildHelpers/1.0.1/Public/Get-BuildVariables.ps1:78 char:21
+         $GitPath = (Get-Command $GitPath)[0].Path
+                     ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (git:String) [Get-Command], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException,Microsoft.PowerShell.Commands.GetCommandCommand

Set-BuildEnvironment: Some concerns about environment variables

I have some concerns about environment variables. They will do in many cases,
indeed. Besides, unlike PowerShell variables, they are available for invoked
applications. The choice of environment variables is understandable.

Limitations

At the same time for pure PowerShell scenarios environment variables are not
natural. While "not natural" is an academic argument, they are potentially
troublesome in some practical cases, typically with more than one project
involved.

Nested builds

There may be projects consisting of several nested projects. For example,
see FarNet family at Build-Scripts-in-Projects.
Calling Set-BuildEnvironment for a child build is going to alter the
previously set environment of the current build.

Parallel builds

Several projects may be built in parallel runspaces (e.g. by Invoke-Builds.ps1 of Invoke-Build).
Parallel runspaces still share the same process environment. So use of
Set-BuildEnvironment in its current form is probably not possible.

Suggestion

Can we have an extra command similar to Set-BuildEnvironment which sets
PowerShell variables with some standardized names rather than environment
variables? Or, to avoid similar commands, let Set-BuildEnvironment do
this optionally? Or even by default and set environment optionally, when
this is really needed and with mentioned limitations of scenarios.

Set-BuildEnvironment should be split into a get/set

Current code gets data on environment (ideally should be done via Get-BuildEnvironment), and writes to environment variables or other persistent deterministic source (Set-BuildEnvironment).

Hangs on long commit message

I did a squash merge of a branch with ~100 commits in it, leading to a very long commit message. Set-Build environment hangs at that point. When I did a git commit --amend to shorten it, Set-BuildEnvironment started working fine again.

Not sure if its a poshGit downstream issue or what, just FYI.

Build failure when RequiredModules is utilized in the Module Manifest

Howdy! I have to call uncle on troubleshooting why this is happening.

I have (or want to have) my module have a 'RequiredModules' property in the Module Manifest.

RequiredModules   = @(
    @{ 'ModuleName' = 'PowerLumber'; 'RequiredVersion' = '3.0.2'}
)

Whenever I un-comment the lines in my Manifest, my build on AppVeyor fails with an error that I cannot determine the reason/source, nor can I reproduce it locally. I have to caveat that... I can reproduce the error when the '.psm1' does not exist, but I do not get an error during the build that the '.psm1' could not be built. It's specific to the RequiredModules section, just can't put my finger on it yet.

Failed Build
Pass Build
Manifest File - Lines 54-56

I guess this also brings up the question, is anyone else doing this? Should I be setting up "dependent" or "required" Modules differently?

Any help/feedback is appreciated!

Add function: Get files changed in git commit

Get-GitChangedFile, or something along those lines

Parameters:

• Commit - defaults to most recent (e.g. git rev-parse HEAD)
• Filter - some sort of filter functionality to include/exclude files returned
• Others?

Ultimately, logic might boil down to something like this:

git diff-tree --no-commit-id --name-only -r $Commit

Example use case: if your repository involves multiple individual-file deployments, this is one way to identify whether to deploy them (ideally you validate against deployed item, this is just an option).

Error with Set-ModuleFunctions when there are ScriptToProcess in the module

Interesting issue with ScriptsToProcess...
The way the Module is invoked and loaded to extract some information does not work when there are ScriptsToProcess define in the PSD1 (yeah, need them because of scope issues).
https://github.com/RamblingCookieMonster/BuildHelpers/blob/master/BuildHelpers/Public/Set-ModuleFunctions.ps1#L54

As you know, ScriptsToProcess are loaded in the session before importing the module, so when you execute this:

Import-Module -Name $Name -PassThru:$Passthru -Force:$Force

It returns the Module info for the ScriptsToProcess then the Module.
That means $Parent = $Module.ModuleBase is actually an array of Strings, which ends up voiding $ModulePSD1Path and failing on Update-MetaData -Path $ModulePSD1Path -PropertyName FunctionsToExport -Value $FunctionsToExport.

Not too sure what's the best way to fix it yet, so thought I'd just raise an issue for now :)

Update-MetaData: How to increment to the next major version automatically

This is more of a RFI, but how do you guys increment your module version in your buiilds to the next major/minor release version?
Update-Metadata -Path $ENV:BHPSModuleManifest

Example:
0.1.11 to 0.2.0
or
0.1.11 to 1.0.0

Wildcards in Get-BuildVariables Path

If I'm reading this right you have to hard code the path or the build file has to stay in the project root. What if we add $Path = (Resolve-Path $Path).Path at the top of Get-BuildVariables to support wildcards? As an example this would allow Set-BuildVariables -Path $PSScriptRoot\.. when your build file is in ..\Build.

Find-NugetPackage must add a trailing back slash if one doesn't exist

This url works :

Find-NugetPackage -Name test -PackageSourceUrl 'https://www.powershellgallery.com/api/v2/' -IsLatest 
Name        : Test
Author      : Naga
Version     : 1.0.0
Uri         : https://www.powershellgallery.com/api/v2/package/Test/1.0.0
Description : Testing
Properties  : properties

But not this :

Find-NugetPackage -Name test -PackageSourceUrl 'https://www.powershellgallery.com/api/v2' -IsLatest 
At C:\Program Files\WindowsPowerShell\Modules\BuildHelpers\0.0.44\Public\Find-NugetPackage.ps1:88 char:5
+     Invoke-RestMethod $URI |
+     ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand

BuildHelpers v 0.0.44

$PSVersionTable
Name                           Value
----                           -----
PSVersion                      5.1.14409.1005
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0, 5.0, 5.1.14409.1005}
BuildVersion                   10.0.14409.1005
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Set-BuildEnvironment Errors

I am changing to the root directory of the module i want to test and running
Set-BuildEnvironment.
I have tried with -Force as well.

Are these error expected,
Maybe I am doing something wrong.

Exception calling "Start" with "0" argument(s): "The system cannot find the file specified"
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:96 char:5

• $null = $p.Start()
  

• ~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
  • FullyQualifiedErrorId : Win32Exception

Exception calling "WaitForExit" with "0" argument(s): "No process is associated with this object."
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:97 char:5

• $p.WaitForExit()
  

• ~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
  • FullyQualifiedErrorId : InvalidOperationException

You cannot call a method on a null-valued expression.
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:105 char:12

•     if($stdout = $p.StandardOutput.ReadToEnd())
  

•        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : InvokeMethodOnNull

You cannot call a method on a null-valued expression.
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:115 char:12

•     if($stderr = $p.StandardError.ReadToEnd())
  

•        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : InvokeMethodOnNull

Exception calling "Start" with "0" argument(s): "The system cannot find the file specified"
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:96 char:5

• $null = $p.Start()
  

• ~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
  • FullyQualifiedErrorId : Win32Exception

Exception calling "WaitForExit" with "0" argument(s): "No process is associated with this object."
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:97 char:5

• $p.WaitForExit()
  

• ~~~~~~~~~~~~~~~~
  

  • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
  • FullyQualifiedErrorId : InvalidOperationException

You cannot call a method on a null-valued expression.
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:105 char:12

•     if($stdout = $p.StandardOutput.ReadToEnd())
  

•        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : InvokeMethodOnNull

You cannot call a method on a null-valued expression.
At C:\Program Files\Windows PowerShell\Modules\Modules\BuildHelpers\Public\Invoke-Git.ps1:115 char:12

•     if($stderr = $p.StandardError.ReadToEnd())
  

•        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  

  • CategoryInfo : InvalidOperation: (:) [], RuntimeException
  • FullyQualifiedErrorId : InvokeMethodOnNull

BHBuildSystem is Unknow in VSTS

$env:BHBuildSystem is Unknown in VSTS when in called in the Release pipeline

Variable Name for the Module Path

Hiya,
I've hit an issue with BuildHelpers when doing a Set-BuildEnvironment -VariableNamePrefix '', where the $Env:PSModulePath is overriden and I wonder if its current name actually makes sense.
I know that this is the reason why the Prefix exist in the first place, but before I work around it (which is trivial but not pretty), I wonder if that should not be renamed (PS is sort of reserved prefix, I believe).

$ENV:BHPSModulePath     via Split-Path on BHPSModuleManifest`

Should this not be ModulePath instead, I can't see the benefit of the PS prefix here?
I see the benefit of adding $ModulePath to $PSModulePath, but not replacing $Env:PSModulePath with $Env:BHPSModulePath (if that makes sense).

Gael

Find-NugetPackage returns null version from Nexus NUGET Source

Hi,

We are using Nexus to host our internal PS repos.
https://www.sonatype.com/nexus-repository-sonatype

Appears that the version we are running (3.10.0-04) does not include the field NormalizedVersion.
I will see if they can update their end.
I will submit a pull request that falls back to Version if NormalizedVersion is not enabled.

Tested and working on our end.
Before

PS C:\dev\dotnet\BuildHelpers> c:\dev\dotnet\BuildHelpers\Test.ps1
Name        : ITSTools
Author      : Dimiter Todorov
Version     :
Uri         : https://nexus3.internal/repository/nuget-hosted/ITSTools/0.1.0
Description : Common functions for OPS ITS Tools
Properties  : properties

After

PS C:\dev\dotnet\BuildHelpers> c:\dev\dotnet\BuildHelpers\Test.ps1
Name        : ITSTools
Author      : Dimiter Todorov
Version     : 0.1.0
Uri         : https://nexus3.internal/repository/nuget-hosted/ITSTools/0.1.0
Description : Common functions for OPS ITS Tools
Properties  : properties

Add TeamCity as build system

We use Teamcity as build system and I thought I take a look at how to add it to BuildHelpers.

One of the issues I found is that Teamcity is very scarce with it's $ENV variables. You can pass any Teamcity variable to the build if you want, but that requires specific build configurations. I wasn't sure if you want to go that way? personally I like it if a module just works without tweaking settings and configuring things in a certain way.

One thing I found it that Teamcity dumps all the variables in an XML file that you can load and parse.

At the moment I made a private function that loads the XML and adds the variables I need to a $ENV variable.

The other thing I am struggling with is that Teamcity doesn't do commit messages. Teamcity can bundle several commits into 1 build or only build every 15 minutes or whatever you specify. So this can become quite tricky to get the commit message from Teamcity.

Any suggestion on the commit message part?

Step-ModuleVersion fails when ExternalModuleDependencies is set

A parameter cannot be found that matches parameter name 'ExternalModuleDependencies'

This is the error I get. I am using the InvokeBuild module.

I think the question is why does Step-ModuleVersion removes the private Data?

BuildHelpers/BuildHelpers/Public/Step-ModuleVersion.ps1

Line 90 in a8793c8

$manifest.Remove("PrivateData")

By commenting that line (and L88), I can finally step the module's version

Get-ProjectName Default to Parent Folder

Get-ProjectName should return the name of the project root folder if no other methods successfully discern the project name.

Expected Behavior

When using Get-ProjectName, it should default to the parent folder's name if none of the other methods are successful - this way the response is non-null in cases where the user's project structure was not predicted.

Current Behavior

The command returns a warning but nothing to the output stream.

Possible Solution

Update the else in the function to include returning the project root folder's name.

Context

This helps for people first writing a module or using some folder structure not predicted by the maintainers; it's a sane default assumption.

Your Environment

• Module version used: 0.0.28
• Operating System and PowerShell version: Windows 10, PowerShell 5.1

Update Vendored Dependencies

Testing out some development work on my mac, I noticed that BuildHelpers vendors in Configuration - however, the vendored version is 0.8 and the latest is 1.2 - I only found this out because 0.8 does not include cross-platform functionality.

Add function: Get next module/script version

Potential names: Get-NextPSGalleryModuleVersion, Get-NextPSGalleryScriptVersion

Because who doesn't love long names!

Input: Module name, PSRepository

Use Find-Module to find the next version. Stick to user's scheme (x.x.x vs. x.x.x.x, even if the latter doesn't comply with semver).

Example use case: Many examples for bumping module version just bump the psd1. That works for a single deployment. Next deployment, unless you committed that change, the psd1 remains the same and your deployment fails. Ideally, you get the PSGallery version, bump that, and set the psd1. Caveat: the source file will get out of date.

Set-BuildEnvironment -Path always sets $PWD.Path for projectroot.

I believe Set-BuildEnvironment is not properly setting $Env:ProjectPath when a custom -Path is supplied. Instead of using the $Path param Get-BuildVariables is passed to it, it is always using $PWD.Path.

I have a patch for this if this was not the intended behavior.

Get-BuildVariable fails on VSTS Hosted Agent

Platform/Agent
Azure DevOps/Hosted VS2017

Executing
(Get-BuildVariable).BuildSystem

Results in

2019-01-29T13:56:40.5200748Z ##[section]Starting: Run tests
2019-01-29T13:56:40.5551552Z ==============================================================================
2019-01-29T13:56:40.5551629Z Task         : PowerShell
2019-01-29T13:56:40.5551683Z Description  : Run a PowerShell script on Windows, macOS, or Linux.
2019-01-29T13:56:40.5551742Z Version      : 2.140.2
2019-01-29T13:56:40.5551778Z Author       : Microsoft Corporation
2019-01-29T13:56:40.5551836Z Help         : [More Information](https://go.microsoft.com/fwlink/?LinkID=613736)
2019-01-29T13:56:40.5551873Z ==============================================================================
2019-01-29T13:56:41.9698156Z Generating script.
2019-01-29T13:56:42.0692862Z ##[command]"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'D:\a\_temp\3caeb402-476f-4939-831d-8ef6f412e707.ps1'"
2019-01-29T13:56:43.7073590Z Invoke-Git : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Message'. Specified 
2019-01-29T13:56:43.7073984Z method is not supported.
2019-01-29T13:56:43.7074326Z At C:\Program Files\WindowsPowerShell\Modules\BuildHelpers\2.0.7\Public\Get-BuildVariable.ps1:180 char:17
2019-01-29T13:56:43.7074643Z + ...             Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $(  ...
2019-01-29T13:56:43.7074919Z +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-01-29T13:56:43.7075323Z     + CategoryInfo          : InvalidArgument: (:) [Invoke-Git], ParameterBindingException
2019-01-29T13:56:43.7075752Z     + FullyQualifiedErrorId : CannotConvertArgument,Invoke-Git
2019-01-29T13:56:43.7075935Z  
2019-01-29T13:56:43.8439576Z ##[error]PowerShell exited with code '1'.
2019-01-29T13:56:43.8854289Z ##[section]Finishing: Run tests

Get-NextNugetPackageVersion return 0.0.1 when a package do not exist

Get-NextNugetPackageVersion return 0.0.1 when a package do not exist :

Get-NextNugetPackageVersion NotExist
Major  Minor  Build  Revision
-----  -----  -----  --------
0      0      1      -1

In this case may be return the actual version of local manifest :

$Actual =(Test-ModuleManifest -path .\MyModule.psd1).Version
$Version=Get-NextNugetPackageVersion NotExist -Actual $Actual
$Version
Major  Minor  Build  Revision
-----  -----  -----  --------
1      2      0      0

Update-Metadata -PropertyName ModuleVersion -Value $Version ...

Find Module Manifest in Source or Src Folder

BuildHelpers should find module manifests placed inside a Source or src folder.

Expected Behavior

When running Get-PSModuleManifest with either of the project layouts below, the function should find and return the manifest MyProject.psm1.

. MyProject
├── docs
├── Source
|   ├── MyProject.psd1
|   └── MyProject.psm1
├── build.ps1
├── psake.ps1

. MyProject
├── docs
├── src
|   ├── MyProject.psd1
|   └── MyProject.psm1
├── build.ps1
├── psake.ps1

Current Behavior

In both cases, Get-PSModuleManifest writes a warning to the console and does not return a value.

Possible Solution

Add logic to Get-PSModuleManifest to handle projects which use the source-folder pattern.

Context

This is how I tend to organize my projects, without this update buildhelpers is only partially functional for me.

Your Environment

• Module version used: 0.0.28
• Operating System and PowerShell version: Windows 10, PowerShell 5.1

GitHub Action support

This is more of an FYI.

I'm experimenting with various PowerShell use cases in GitHub Actions and some of them use BuildHelpers to determine some folder paths. I receive the following error when running Set-BuildEnvironment -Force when run within an Action.

Cannot index into a null array.
At /github/home/.local/share/powershell/Modules/BuildHelpers/2.0.0/Public/Get-BuildVariables.ps1:78 char:9
+         $GitPath = (Get-Command $GitPath -ErrorAction SilentlyContinu ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : NullArray

I'm going to dig into this more and hopefully submit a fix.

Inconsistent code style

The functions in this repo have many different styles of code.

This is not a big problem, but a contributor using an editor that "fixes" the style (eg: VSCode), will flag a lot more changes than required.

Is it in the interest of this module to harmonize the style to avoid this? And if so, with what rules? Shall this be enforced with tests?

Add VSTS as a Build System

I use Visual Studio Team Services quite a lot and would like to see VSTS included as a build system.
If you like I can submit a pull request.

The only remaining questions I have are:

1. you make use of package management, currently VSTS hosted agents only have PowerShell v4 running and we're not able to install additional software
2. Your tests include PowerShell v5 functionality like New-Guid

Would you like me to make it v4 compatible?
The only file that does get modified is Get-BuildVariables, but no tests target the function if I'm correct.

I've forked your repository and have a working version for VSTS, but it only takes Git repositories into account, not TFS and the module import is a but quick and dirty.
forked BuildHelpers

Thanks,
Stijn

Easy Integration with PSSlack for Build Tools

I started writing a helper module for easy integration of PSSlack initially with Invoke-Build and plans to add psake as well. The first version was to be able to be able to add just one line of code to Invoke-Build's Enter-Build, Enter-BuildTask, Exit-BuildTask, and Exit-Build to get notifications of the build process in Slack. Additionally, I had plans to add the same type of functions that you have in the BuildHelpers module.

After looking at your BuildHelpers module I am thinking that it might make more sense to just submit a pull request to add that functionality to BuildHelpers instead of creating a different module. Would you be open to that?

Here is a link to the module that I started if you want to take a look: buildHelper. It is a bit rough because it just wrapped up the prototype phase and now I am starting to clean it up and add all of the missing stuff.

Feature Request: Add Set-ModuleTypes

Much like you have the Set-ModuleFunctions and Set-ModuleFormats functions, it would also be nice to have a Set-ModuleTypes function for updating the TypesToProcess array in the module manifest.

Add function: Compare content to PSGallery

Potential names: Compare-PSGalleryModuleContent and Compare-PSGalleryScriptContent

Input: PSRepository, ModulePath, ModuleName (Derived from ModulePath potentially?) Version (default to latest, if we even offer this)

Pull down latest version of a module (or script) from PSGallery, compare contents with a specified local module.

Example use case: In scenarios where multiple scripts or modules are deployed from a single repository, these functions could be used to validate that files have been changed between the current data, and the PSGallery data.

Set-ModuleFunction errors when relative path is used

I've noticed that the Set-ModuleFunction throws an exception (can't find module) when a relative path to the PSD1 is used (instead of just the name).
This is because a new [PowerShell] is used and no checks are done on Path/Name Parameter.

This could be checked with something like this after the Param block:

if($Name -match ([regex]::escape([io.path]::DirectorySeparatorChar)) -and ![io.path]::Isrooted($Name)) {
    $Name = (Get-Item $Name).FullName
}

Or something like that (I haven't tested).

Update GitLab variables

Detect new variables (old ones need to remain as well) for GitLab 9.0

Cmdlets with plural form

The following public functions are in plural form; whereas Powershell recommends nouns to be in singular:

• Get-BuildVariables
• Get-ModuleAliases
• Get-ModuleFunctions
• Set-ModuleAliases
• Set-ModuleFormats
• Set-ModuleFunctions

Module dependecy

The module Configuration in version v0.8 is currently loaded from ./Private/*.
This is causing some trouble for me: v0.8 does not support PowerShell Core on non-Windows OS.

I was unable to reproduce the problem described in the code:

BuildHelpers/BuildHelpers/BuildHelpers.psm1

Lines 19 to 22 in 31e36e2

	# Load dependencies. TODO: Move to module dependency once the bug that
	# causes this is fixed: https://ci.appveyor.com/project/RamblingCookieMonster/buildhelpers/build/1.0.22
	# Thanks to Joel Bennett for this!
	Import-Module $PSScriptRoot\Private\Modules\Configuration

Has this been fixed? Is it possible to switch to using RequiredModules?

Uh. Get-NextPSGalleryVersion is broken

Latest PowerShellGet does not play nice (or, I do something silly that doesn't work with the new version).

https://github.com/RamblingCookieMonster/BuildHelpers/blob/master/BuildHelpers/Public/Get-NextPSGalleryVersion.ps1

This has been deprecated for a while, but I never actually updated my build scripts. Pushed a new PSDeploy today annnnnnd 1.0. It returns 1.0 for everything.

I'm thinking... Remove the old function, add an alias to Get-NextNugetPackageVersion, if parameters line up. Any objections? EDIT: Nope. Incompatible parameters. Unless we assume everyone just used the defaults and only specified -Name, which... I don't think we can do? Not sure if folks are using this internally...

Invoke-git not working when given a network Path

Resolve-Path is prepending is prepending the powershell provider to the name for the path property, that's usually what you get when in the PsPath property.

System.Diagnostices.ProcessStartInfo Objests do not support the prepended powershell provider for working directory, consider switching the following line on Invoke-git.ps1 line 83

$Path = (Resolve-Path $Path).Path
to
$Path = (Resolve-Path $Path).ProviderPath

Make build environment variables persistent in VSTS

When using multiple tasks in Visual Studio Team Foundation you need to persist the variables using specific VSTS tasks.

$env:variablename only lives in the current task.
using VSTS tasks makes the variable persistent cross tasks.

I propose to add VSTS specific logic to the Set-BuildEnvironment function to make those persistent?
What do you think?