Giter Club home page Giter Club logo

powershellbuild's Introduction

PowerShellBuild

GitHub Actions PS Gallery License
GitHub Actions Status PowerShell Gallery License

This project aims to provide common psake and Invoke-Build tasks for building, testing, and publishing PowerShell modules.

Using these shared tasks reduces the boilerplate scaffolding needed in most PowerShell module projects and help enforce a consistent module structure. This consistency ultimately helps the community in building high-quality PowerShell modules.

If using psake as your task runner, version 4.8.0 or greater is required to make use of shared tasks distributed in separate modules. To install psake 4.8.0 you can run:

Install-Module -Name psake -RequiredVersion 4.8.0 -Repository PSGallery

For Invoke-Build, see the how to dot source tasks using PowerShell aliases example.

Logo

Status - Work in progress

This project is a work in progress and may change significantly before reaching stability based on feedback from the community. Please do not base critical processes on this project until it has been further refined.

Tasks

PowerShellBuild is a PowerShell module that provides helper functions to handle the common build, test, and release steps typically found in PowerShell module projects. These steps are exposed as a set of psake tasks found in psakeFile.ps1 in the root of the module, and as PowerShell aliases which you can dot source if using Invoke-Build. In psake v4.8.0, a feature was added to reference shared psake tasks distributed within PowerShell modules. This allows a set of tasks to be versioned, distributed, and called by other projects.

Primary Tasks

These primary tasks are the main tasks you'll typically call as part of PowerShell module development.

Name Dependencies Description
Init none Initialize psake and task variables
Clean init Clean output directory
Build StageFiles, BuildHelp Clean and build module in output directory
Analyze Build Run PSScriptAnalyzer tests
Pester Build Run Pester tests
Test Analyze, Pester Run combined tests
Publish Test Publish module to defined PowerShell repository

Secondary Tasks

These secondary tasks are called as dependencies from the primary tasks but may also be called directly.

Name Dependencies Description
BuildHelp GenerateMarkdown, GenerateMAML Build all help files
StageFiles Clean Build module in output directory
GenerateMarkdown StageFiles Build markdown-based help
GenerateMAML GenerateMarkdown Build MAML help
GenerateUpdatableHelp BuildHelp Build updatable help cab

Task customization

The psake and Invoke-Build tasks can be customized by overriding the values contained in the $PSBPreference hashtable. defined in the psake file. These settings govern if certain tasks are executed or set default paths used to build and test the module. You can override these in either psake or Invoke-Build to match your environment.

Setting Default value Description
$PSBPreference.General.ProjectRoot $env:BHProjectPath Root directory for the project
$PSBPreference.General.SrcRootDir $env:BHPSModulePath Root directory for the module
$PSBPreference.General.ModuleName $env:BHProjectName The name of the module. This should match the basename of the PSD1 file
$PSBPreference.General.ModuleVersion \<computed> The version of the module
$PSBPreference.General.ModuleManifestPath $env:BHPSModuleManifest Path to the module manifest (PSD1)
$PSBPreference.Build.OutDir $projectRoot/Output Output directory when building the module
$PSBPreference.Build.Dependencies 'StageFiles, 'BuildHelp' Default task dependencies for the Build task
$PSBPreference.Build.ModuleOutDir $outDir/$moduleName/$moduleVersion For internal use only. Do not overwrite. Use '$PSBPreference.Build.OutDir' to set output directory
$PSBPreference.Build.CompileModule $false Controls whether to "compile" module into single PSM1 or not
$PSBPreference.Build.CompileDirectories @('Enum', 'Classes', 'Private', 'Public') List of directories to "compile" into monolithic PSM1. Only valid when $PSBPreference.Build.CompileModule is $true.
$PSBPreference.Build.CopyDirectories @() List of directories to copy "as-is" to built module
$PSBPreference.Build.CompileHeader <empty> String that appears at the top of your compiled PSM1 file
$PSBPreference.Build.CompileFooter <empty> String that appears at the bottom of your compiled PSM1 file
$PSBPreference.Build.CompileScriptHeader <empty> String that appears in your compiled PSM1 file before each added script
$PSBPreference.Build.CompileScriptFooter <empty> String that appears in your compiled PSM1 file after each added script
$PSBPreference.Build.Exclude <empty> Array of files (regular expressions) to exclude when building module
$PSBPreference.Test.Enabled $true Enable/disable Pester tests
$PSBPreference.Test.RootDir $projectRoot/tests Directory containing Pester tests
$PSBPreference.Test.OutputFile $null Output file path Pester will save test results to
$PSBPreference.Test.OutputFormat NUnitXml Test output format to use when saving Pester test results
$PSBPreference.Test.ScriptAnalysis.Enabled $true Enable/disable use of PSScriptAnalyzer to perform script analysis
$PSBPreference.Test.ScriptAnalysis.FailBuildOnSeverityLevel Error PSScriptAnalyzer threshold to fail the build on
$PSBPreference.Test.ScriptAnalysis.SettingsPath ./ScriptAnalyzerSettings.psd1 Path to the PSScriptAnalyzer settings file
$PSBPreference.Test.CodeCoverage.Enabled $false Enable/disable Pester code coverage reporting
$PSBPreference.Test.CodeCoverage.Threshold .75 Fail Pester code coverage test if below this threshold
$PSBPreference.Test.CodeCoverage.Files *.ps1, *.psm1 Files to perform code coverage analysis on
$PSBPreference.Test.CodeCoverage.OutputFile coverage.xml Output file path (relative to Pester test directory) where Pester will save code coverage results to
$PSBPreference.Test.CodeCoverage.OutputFileFormat $null Test output format to use when saving Pester code coverage results
$PSBPreference.Test.ImportModule $false Import module from output directory prior to running Pester tests
$PSBPreference.Help.UpdatableHelpOutDir $OutDir/UpdatableHelp Output directory to store update module help (CAB)
$PSBPreference.Help.DefaultLocale (Get-UICulture).Name Default locale used for help generation
$PSBPreference.Help.ConvertReadMeToAboutHelp $false Convert project readme into the module about file
$PSBPreference.Docs.RootDir $projectRoot/docs Directory PlatyPS markdown documentation will be saved to
$PSBPreference.Publish.PSRepository PSGallery PowerShell repository name to publish
$PSBPreference.Publish.PSRepositoryApiKey $env:PSGALLERY_API_KEY API key to authenticate to PowerShell repository with
$PSBPreference.Publish.PSRepositoryCredential $null Credential to authenticate to PowerShell repository with. Overrides $psRepositoryApiKey if defined

Examples

psake

The example below is a psake file you might use in your PowerShell module. When psake executes this file, it will recognize that tasks are being referenced from a separate module and automatically load them. You can run these tasks just as if they were included directly in your task file.

Notice that the task file contained in MyModule only references the Build task supplied from PowerShellBuild. When executed, the dependent tasks Init, Clear, and StageFiles also contained in PowerShellBuild are executed as well.

psakeBuild.ps1
properties {
    # These settings overwrite values supplied from the PowerShellBuild
    # module and govern how those tasks are executed
    $PSBPreference.Test.ScriptAnalysisEnabled = $false
    $PSBPreference.Test.CodeCoverage.Enabled  = $true
}

task default -depends Build

task Build -FromModule PowerShellBuild -Version '0.1.0'

Example

Invoke-Build

The example below is an Invoke-Build task file that imports the PowerShellBuild module which contains the shared tasks and then dot sources the Invoke-Build task files that are referenced by the PowerShell alias PowerShellBuild.IB.Tasks. Additionally, certain settings that control how the build tasks operate are overwritten after the tasks have been imported.

.build.ps1
Import-Module PowerShellBuild
. PowerShellBuild.IB.Tasks

# Overwrite build settings contained in PowerShellBuild
$PSBPreference.Test.ScriptAnalysisEnabled = $true
$PSBPreference.Test.CodeCoverage.Enabled  = $false

Example

powershellbuild's People

Contributors

chrislgardner avatar devblackops avatar imjla avatar joeypiccola avatar joshooaj avatar justingrote avatar nightroman avatar opsm0nkey avatar pauby avatar webtroter avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

powershellbuild's Issues

Status? eta wen :-)

I had seen this module a while back and was curious where it stands today.

I have seen half a dozen different ways to templatize a CI/CD module, and was excited to see this attempt at building a standard template.

I currently use a mixture of a a few "Powershell Masters" to provide a decent CI/CD pipeline for my modules., but it still needs some additional rework to fully utilize all the tasks...

Plaster

This seems like a nice and simple module layout. Is there any desire to turn it into a Plaster template?

$ProjectRoot Variable Is Empty - Possible Timing Issue

I am trying to specify a non-default path for $PSBPreference.Test.RootDir in the psakeBuild.ps1 file. It doesn't appear that the $projectRoot variable is being populated before the Properties block is instantiated.

I can see that the $BHProjectPath is populated at runtime, and $projectRoot is being derived from this value.

But if I output the value of $projectRoot during runtime, from inside the Properties block, it is empty.

Could you take a look and see if I am correct about the timing issue above?

CleanUp should delete all old build versions

I noticed that if a new version is build, the Cleanup task will not delete old build versions in 'Output\modulename'

This forces me to add an additional cleanup task or to specify the explicit version to my additional push step I have to
use at the moment.

Expected Behavior

Cleanup task, should cleanup everything in the Output folder

Current Behavior

Old module versions remain in the Output folder after the CleanUp task has run

Possible workaround

  • Cleanup workspace after pipeline has run
  • Add a custom CleanUp step to the pipeline

Steps to Reproduce (for bugs)

  1. Change module version in manifest
  2. Add Version to ChangeLog.md
  3. build
  4. ls Output folder

Context

I try to Build and Push a PowerShell module with minimal additions and changes to the vanilla build pipeline
created by Stucco.

Your Environment

Powershell 5.1
Jenkins-agent on ServerCore Container (Build 1809)

Overriding variables

I want to override variable values such as $PSBPreference.General.ModuleVersion when I call the build.ps1 file. Can someone please provide a valid example of how to pass the argument in the hashtable format?

Discussion: Adding Headers & Footers To Module File / Functions

When I 'compile' my public and private functions into a script module I often have text at the top and bottom of the script module itself (Set-StrictMode and sometimes comments). It seems natural to therefore add a footer too.

And to take it one step further sometimes I do the same before and after function (that's not so common but just to take it that step further again).

Looking really to start a discussion around adding this in?

Compile Module Files Adds All .ps1* Files Into Module

When running a build and specifying $compileModule = $true the build will fail as the .ps1xml file has been added into the module script.

Expected Behavior

I expect only *.ps1 files to be included in the module file.

Current Behavior

Any files with extension *.ps1* are added into the module script.

Possible Solution

The issue is in Build-PSBuildModule.ps1 line 75:

$allScripts = Get-ChildItem -Path $Path -Filter *.ps1 -Recurse -ErrorAction SilentlyContinue

Removing the filter parameter and appending the filter onto the end of the path fixes it:

$allScripts = Get-ChildItem -Path (Join-Path -Path $Path -ChildPath '*.ps1') -Recurse -ErrorAction SilentlyContinue

Note that this only affects Windows PowerShell. PowerShell Core works with the -filter parameter correctly. Issue is discussed here

Steps to Reproduce (for bugs)

  1. Add $compileModule = $true into your build and make sure you have a .ps1xml file in your source folder / subfolders.
  2. Run Invoke-Build

Your Environment

  • Module version used: 0.02
  • Operating System and PowerShell version: Windows 10 and in both Windows PowerShell 5.1.17134.407 and PowerShell Core 6.1.1

builds fail when attempting to compile monolithic .psm1 file via $PSBPreference.Build.CompileModule = $true

When setting $PSBPreference.Build.CompileModule = $true in the properties block of a psakeFile.ps1 generated from the Plaster Stucco template v0.1.1 an error is generated.

Expected Behavior

PowerShellBuild should be correctly passed $true via $PSBPreference.Build.CompileModule and proceed to compile a monolithic .psm1 file in the build output directory.

Current Behavior

The following error is generated.

Task: CLEAN
Task: STAGEFILES
Task: GENERATEMARKDOWN
Error: 9/9/2019 11:03:07 PM:
At C:\gits\psmeetup\oldmod\issuemodule\Output\issuemodule\0.1.0\issuemodule.psm1:2 char:14 + ... public  = @(Get-ChildItem -Path (Join-Path -Path $PSScriptRoot -Child ... +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Cannot find path 'C:\gits\psmeetup\oldmod\issuemodule\Output\issuemodule\0.1.0\public\' because it does not exist.

Possible Solution

In testing it appears deleteing the contents of the Plater \ Stucco generated .psm1 file allows the build to complete and a monolithic .psm1 is generated in the build output directory.

Steps to Reproduce (for bugs)

Ensure development modules are current.

Get-Module plaster, stucco -ListAvailable | select name, version
Name    Version
----    -------
Plaster 1.1.3
Stucco  0.1.1
  1. Get stucco template.
    $template = Get-PlasterTemplate -IncludeInstalledModules | Where-Object TemplatePath -Match 'Stucco'
  2. Invoke plaster with stucco template.
    Invoke-Plaster -TemplatePath $template.TemplatePath
  3. Run through plaster prompts.
  4. Modify generated psakeFile.ps1 properties block set the value for $PSBPreference.Build.CompileModule from $false to $true.
properties {
    # Disable "compiling" module into monolithinc PSM1.
    # This modifies the default behavior from the "Build" task
    # in the PowerShellBuild shared psake task module
    $PSBPreference.Build.CompileModule = $true
}
  1. Run build.
    ./build.ps1 -Bootstrap

Context

Unable to generate a monolithic .psm1 file due to build erroring out.

Your Environment

  • Module version used: 0.3.0
  • Operating System and PowerShell version: Windows 10, 5.1.17134.137

Implement a better Build.Exclude

The Build.Exclude configuration is simply an array of strings passed to the Get-ChildItem -Exclude parameter. This is very inflexible and ... a little rubbish. If you try and exclude anything but file(s) it doesn't work.

Expected Behavior

We should implement a Build.ExcludePattern and / or Build.ExcludeWildcard that allows the exclusion to match on a regular expression or wildcards.

The names above are just examples.

Current Behavior

The Build.Exclude configuration is simply an array of strings passed to the Get-ChildItem -Exclude parameter. This is very inflexible and ... a little rubbish. If you try and exclude anything but file(s) it doesn't work.

Possible Solution

I'm happy to submit a PR for this but looking to get agreement on the specifics above.

Your Environment

  • Module version used: 0.4.0
  • Operating System and PowerShell version: Windows 10, PowerShell Core 7.0.0

IB Tasks Appear Broken?

Latest 0.3.0 Beta version. The Build task in PowerShell.IB.Tasks is empty task Build. As a consequence nothing happens when running invoke-build -File .\.build.ps1 -task build

Expected Behavior

In previous version 0.2.0 the Build task was task Build StageFiles, BuildHelp which built the module. I expect the same from the new version.

Current Behavior

You get this:

image

Possible Solution

Change the PowerShell.IB.Tasks file to either use the same build tasks as previous version or use the tasks specified in $PSBPreference.Build.Dependencies which by default is 'StageFiles', 'BuildHelp' (this doesn't appear to be used anywhere but I could be missing it).

  • Module version used: 0.3.0-beta
  • Operating System and PowerShell version: Windows 10, Windows PowerShell 5.1.17134.407

Existing Module Version Check Very Strict

When Task.ps1 is determining whether the $FromModule is suitable, it does a check of the $taskModule version against $version which was passed into the file as a parameter.

This version is strict enough that patch release differences in the version number cause the $taskModule to be rejected and the task errors out.

Expected Behavior

My expectation would be that a patch (z) should probably not cause a module to be rejected. This is a personal assumption, but given that I don't actually know yet where the $version parameter is coming from, I can't say with certainty that this should be the expectation for all users.

Current Behavior

The task I am executing, build, is expecting version 0.1.0 of the PowerShellBuild module. Currently I have version 0.1.1 installed. That z release difference in version number is causing the build task to fail.

Possible Solution

Change to a version check that ensures only that Major and Minor version match. I think you could make an argument that it should be Major is equal and Minor is Greater Than or Equal, but since I don't know where the $version parameter is actually coming from, it's hard for me to say.

Steps to Reproduce (for bugs)

  1. Install psake 4.8
  2. Install PowerShellBuild 0.1.1
  3. Create a module using the Stucco Module
  4. Execute build.ps1 -task build

Context

Currently I am unable to build a module with the latest version of the PowerShellBuild module unless I modify my copy of the Psake to allow the z release copy of PowerShellBuild.

Your Environment

Psake 4.8.0
PowerShellBuild 0.1.1
0.1.0
Windows 10
PowerShell 6.1.0

CompileModule Flag results in bad PSM1 file

Using option to CompileModule results in original PSM1 file having *.ps1 files appended.

Expected Behavior

new PSM1 file should have code from all *.ps1 files, and nothing else.

Current Behavior

original PSM1 file is copied (which includes code to dot-source *.ps1 files ) AND the contents of *.ps1 files is appended to the original PSM1 file

Possible Solution

When using CompileModule flag the original PSM1 file should NOT be copied to OUTPUT directory

Steps to Reproduce (for bugs)

  1. Use Stucco and Plaster to create a new module
  2. Change "CompileModule" flag in psakeFile.ps1 to $true
  3. Build module
  4. Resulting PSM1 file in output directory has content from original PSM1 file + the code from *.ps1 files.

Context

Resulting PSM1 file is incorrect.

Your Environment

  • Module version used: 0.3.0
  • Operating System and PowerShell version: Windows 10 (1803) with Windows PowerShell 5.1

Azure DevOps builds not failing despite tests failing

Expected Behavior

When a build is run via Azure DevOps I'd expect the build to fail if tests or PSSA fails. For example I have this build which failed while I was fixing various things in how it was versioning etc https://halbaradkenafin.visualstudio.com/Github/_build/results?buildId=775 and it failed correctly due to tests failing.

Current Behavior

I get builds like this one which pass despite some tests failing: https://halbaradkenafin.visualstudio.com/Github/_build/results?buildId=784

There was no real changes to the code between those two builds, I've even tried setting the ErrorActionPreference and ContinueOnError in the azure-pipelines.yml to ensure it does stop but it looks like the code isn't even getting to any of the throw statements that should cause it to stop.

Builds not failing despite changelog and manifest version tests failing

Expected Behavior

Build fails, if any Pester tests fails

Current Behavior

   [-] Changelog and manifest versions are the same 391ms (298ms|92ms)
    Expected 1.0.0.2, but got 1.0.0.0.
    at $changelogVersion -as [Version] | Should -Be ( $manifestData.Version -as [Version] ), C:\Users\jenkins\Agent\workspace\erShell-Modules_CCM-Build_master\tests\Manifest.tests.ps1:62
    at <ScriptBlock>, C:\Users\jenkins\Agent\workspace\erShell-Modules_CCM-Build_master\tests\Manifest.tests.ps1:62

Describing Git tagging
  [!] Is tagged with a valid version 80ms (0ms|80ms)
  [!] Matches manifest version 65ms (0ms|65ms)

Running tests from 'Meta.tests.ps1'
Describing Text files formatting
 Context File encoding
   [+] No text file uses Unicode/UTF-16 encoding 238ms (112ms|126ms)
 Context Indentations
   [+] No text file use tabs for indentations 250ms (129ms|121ms)
Tests completed in 36.97s
Tests Passed: 54, Failed: 1, Skipped: 2 NotRun: 0
...
Finished: SUCCESS

Possible Solution

Steps to Reproduce (for bugs)

  1. Change Manifest version
  2. Skip adding new version to changelog
  3. build

Context

I build my module in jenkins, saw the error, but my build never failed

Your Environment

Jenkins Agent Container (Windows Docker EE)
Powershell 5.1

Additional Pester tests needed

Additional integration Pester tests are needed to verify the various psake/InvokeBuild tasks function as expected.

Expected Behavior

psake/InvokeBuild tasks are tested to ensure quality.

Current Behavior

There is only some basic tests to verify help documentation for the public functions.

Possible Solution

  • Create one or more basic PS modules, execute various build tasks and user Pester to verify the process works as expected.

Steps to Reproduce (for bugs)

NA

Context

We need to increase the test coverage to ensure any changes to the build functions or psake/InvokeBuild tasks do not break publicly exposed functionality.

Your Environment

  • Module version used: 0.3.0
  • Operating System and PowerShell version: NA

Provide property for internal repository publishing

Expected Behavior

  1. Provide an alternate value for a PublishGallery or Repository.
  2. During the Publish step, the module is packaged and published to the chosen repository

Current Behavior

No value for specifying an alternate repository (i.e. an Internal repository.)

Possible Solution

Add a property name that allows a repository name to be provided. Either through BuildHelpers or in PowershellBuild

Steps to Reproduce (for bugs)

N/A

Context

I am looking to integrate this module in my current CI/CD pipeline, and I currently publish to an internal repository at work.

Your Environment

  • Module version used: PowershellBuild 0.1.1
  • Operating System and PowerShell version: Windows 10 Pro, Powershell 5.1.17134.228

Discussion: Settings as Hashtable Variable?

This would be more of a usability discussion, but some variables like $outDir are pretty generic and may conflict with user build scripts who aren't aware of them or are porting them out.

Should these settings maybe be in something like $PSBPreference as a hashtable, so you could set them like:

$PSBPreference.OutDir = "MyCustomDir"
$PSBPreference

Plus as a hashtable they could also be defined in a .psd1 file and imported if someone had a preference for that vs. defining in build script directly.

This would also make them more discoverable since they could be populated from the beginning with defaults and easily referenced. The tradeoff is obviously more typing and maybe less intuitive to new users, but the BuildHelpers variables aren't that much less intuitive either and noone seems to have issue with those.

A class is also an option, but the only benefit gained there would be maybe adding Validate for parameters that have limited options (booleans, validatesets, and whatnot), and classes are hard to expose, probably unnecessary

Thoughts? I'd be willing to PR the refactor if people agree this is the better way to go.

Pester tests attempted despite value of $PSBPreference.Test.Enabled

Despite the value of $PSBPreference.Test.Enabled, Pester tests are executed.

Expected Behavior

If $PSBPreference.Test.Enabled is set to $false then Pester tests should not be run.

Current Behavior

Pester tests are run regardless of the setting.

Possible Solution

I would have said that inside the Pester task there should be a check for the $PSBPreference.Test.Enabled value being $true. However there is a $pesterPreReqs scriptblock that is executed in the psakeFile.ps1 as a precondition but this is not being carried over to InvokeBuild (perhaps using an -If) which is where I believe the issue is.

Your Environment

  • Module version used: 0.3.0-beta
  • Operating System and PowerShell version: Windows 10, 6.1.1

$PSBPreference.Build.CompileModule = $true seems problematic

Expected Behavior

I am using the original module structure built by Stucco(Plaster template).
Next to that, I am utilizing PowershellBuild.
Once I set the variable $PSBPreference.Build.CompileModule = $true I expect my module files(functions) to be combined in the monolith structure.

Current Behavior

At the moment Powershell is throwing the exception, It seems like that .psm1 file has been created with its original - non-monolith structure, and it is trying to import functions from the public and private folder.

Steps to Reproduce (for bugs)

C:\Users\njovic\Desktop> .\build.ps1 -Task build
Task: INIT

Build System Details:
Build Module: PowerShellBuild:0.4.0
PowerShell Version: 5.1.18362.752

Environment variables:
BHProjectName mymodule
BHModulePath C:\Users\njovic\Desktop\mymodule
BHPSModulePath C:\Users\njovic\Desktop\mymodule
BHBuildOutput C:\Users\njovic\Desktop\Output\mymodule\0.1.0
BHPSModuleManifest C:\Users\njovic\Desktop\mymodule\mymodule.psd1
BHBuildSystem Unknown
BHBuildNumber 0
BHProjectPath C:\Users\njovic\Desktop
Task: CLEAN

Task: STAGEFILES

Task: GENERATEMARKDOWN

Error: 4/17/2020 9:13:11 AM:
At C:\Users\njovic\Desktop\Output\mymodule\0.1.0\mymodule.psm1:2 char:14 + ... public = @(Get-ChildItem -Path (Join-Path -Path $PSScriptRoot -Child ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Cannot find path 'C:\Users\njovic\Desktop\Output\mymodule\0.1.0\Public' because it does not exist.

How to solve?

In the function Build-PSBuildModule there is a conditional - if ($Compile.IsPresent) , it should contain Clear-Content $rootModule -force , which will wipe the file content - stripping down the classical import process of the module and then append the content of all functions combined.

Your Environment

Stucco version: 0.2.0
PowershellBuild: 0.4.0

  • Operating System and PowerShell version:
    Windows 10 Pro
    Powershell: 5.1

Examples of Strongly Opinionated (Custom) Tasks In ReadMe

Assumption

I believe this module has the ability for users to write custom tasks to the psakebuild.ps1 file, and PowershellBuild will execute what it covers, while PSake executes the custom tasks.

This may be as simple as writing the custom tasks, and adding dependencies from the executing tasks (Build, Publish, Test, etc...)

Request

Would it be worth showing in the ReadMe examples, to show that PowershellBuild helps standardize, but doesn't restrict you from customizing it?

I could help write some examples, if this would be helpful.

Context

I am currently using Git, and wanted to add a "Git Tag" task when I publish a new version of a module. But was struggling at first on how to integrate this while using PowershellBuild. (I am still wrestling on whether tagging should be done at the tip of the commit that adds the feature, or when the artifact is created to be published.)

Dependency on variable in parent scope (Build-PSBuildUpdatableHelp)

Expected Behavior

The following command should successfully complete its call to New-ExternalHelpCab:

Build-PSBuildUpdatableHelp -DocsPath 'C:\Temp\docs' -OutputPath 'C:\Temp\dist\UpdatableHelp'

Current Behavior

Currently an error is thrown if the $ModuleName variable is not correctly defined in the parent scope:

 New-ExternalHelpCab: untitled:Untitled-2:49:29
Line |
  49 |          New-ExternalHelpCab @cabParams > $null
     |                              ~~~~~~~~~~
     | Cannot validate argument on parameter 'LandingPagePath'. Path 'C:\Temp\docs/en-US/.md' is not a file.

Possible Solution

This can be addressed by adding a Module parameter that defaults to the value of the $ModuleName variable

Steps to Reproduce (for bugs)

  1. Launch pwsh
  2. Run this command:
Build-PSBuildUpdatableHelp -DocsPath 'C:\Temp\docs' -OutputPath 'C:\Temp\dist\UpdatableHelp'

Context

This will make it easier to use Build-PSBuildUpdatableHelp in custom psake tasks

Your Environment

  • Module version used: 0.6.1
  • Operating System and PowerShell version:
$PSVersionTable


Name                           Value
----                           -----
PSVersion                      7.2.1
PSEdition                      Core
GitCommitId                    7.2.1
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Add pester code coverage output parameters

Expected Behavior

We should have 2 additional Preference parameters for the pester code coverage report output.
CodeCoverageOutputFile
CodeCoverageOutputFileFormat

Current Behavior

Currently the only Code coverage options are to enable it, files to be scanned and the failure threshold. There are no options for output customization.

Possible Solution

Add these to the PSBPreference object
$PSBPreference.Test.CodeCoverage.OutputFile
$PSBPreference.Test.CodeCoverage.OutputFileFormat

Then enabled those options in the Test-PSBuildPester.ps1 function

Steps to Reproduce (for bugs)

Context

I am starting to learn to build modules in Azure Devops and I would like to be able to display the code coverage in the Azure pipeline report. So far the only way I have found to do that is to have pester output the code coverage report to a JaCoCo xml file.

Your Environment

Windows 10 2004
Powershell 5.1
BuildHelpers = '2.0.15'
psake = '4.9.0'
PSScriptAnalyzer = '1.19.1'
PowerShellBuild = '0.4.0'

Powershellget error when pushing module to private repo

I need to publish the module to a private nexus repo and get an error:

Expected Behavior

save-module
publish-module

Current Behavior

Publish-Module

The specified RequiredModules entry 'BuildHelpers' in the module
manifest 'C:\Users\jenkins\AppData\Local\Temp\1443179751\PowerShellBuild\PowerShellBuild.psd1' is invalid. Try again
after updating this entry with valid values.
At C:\Program Files\WindowsPowerShell\Modules\PowerShellGet\2.2.5\PSModule.psm1:10817 char:27

Workaround

Remove the required modules from the psd1 file

RequiredModules = @( @{ModuleName = 'BuildHelpers'; ModuleVersion = '2.0.16'} @{ModuleName = 'Pester'; ModuleVersion = '5.3.1'} @{ModuleName = 'platyPS'; ModuleVersion = '0.14.2'} @{ModuleName = 'psake'; ModuleVersion = '4.9.0'} )

Steps to Reproduce (for bugs)

save-module
publish-module

Your Environment

Jenkins-agent running PowerShell 5.1 in Windows Docker Server Core container

ModuleOutput documentation inconsistency

Expected Behavior

When setting $PSBPreference.Build.OutDir I expect the Output Directory specified to be used but it is not.

Current Behavior

Instead of the value of $PSBPreference.Build.OutDir being used as the Output Directory, "$projectRoot/Output" is used.

Possible Solution

The problem is two fold:

  1. The docs state that the module output directory can be changed using $PSBPreference.Build.OutDir;
  2. The code says that the actual variable to be used should be $BuildEnvironment.Build.ModuleOutDir ($BuildEnvironment in this case is actually $PSBPreference)

There needs to be an agreement on which of the above is correct - the docs or the code. Once that's known we can change the other one.

Discussion: Version with loosened dependencies?

Since this is aiming to be a "library" of tasks and a framework to use for opinionated templates, perhaps some of the dependency ordering should be loosened?

For instance, maybe I don't want Publish to depend on Test, or maybe I don't want Test to be dependent on Pester because I want to use my own testing framework.

I was thinking of a variable(s?) to make these dependencies conditional. The dependencies would be on by default, but you could set the variable that would effectively remove all the dependencies and then you can pick-and-choose the tasks/jobs and assign dependencies as required in the downstream template.

This would be an "at-your-own-risk" item, but also should probably focus on individual tasks also being autonomous and not being "truly" dependent on each other (e.g. won't fail if a dependency isn't met)

For tasks that require interoperation, could define high level tasks like "Build", "Test", "Publish" but those are just empty tasks with dependencies, so that those could be overridden in the script.

$env:BHBuildOutput is not being set

Expected Behavior

The $env:BHBuildOutput variable to have the same value as $PSBPreference.Build.ModuleOutDir

Current Behavior

In the Init() task a list of build variables is shown and BHBuildOutput points ot a $projectRoot\BuildOutput folder (so say powershellbuild\BuildOutput) which doesn't reflect what the $PSBPreference.Build.ModuleOutDir variable is set to.

Possible Solution

When calling Set-BuildEnvironment in the Initialize-PSBuild function, explicitly set the BuildOutput parameter.

CompileModule = $true fails on Classes

When executing a build using $PSBPreference.Build.CompileModule = $true on a base Stucco template, I receive an error on the Task GENERATEMARKDOWN. However, if I use $PSBPreference.Build.CompileModule = $false the build will succeed.

Expected Behavior

The build of a monolithic PSM1 should not produce errors regarding Classes.

Current Behavior

I receive the following error:

Error: 2022-12-14 9:19:54 PM:
At C:\Temp\ModuleNew\Output\ModuleNew\0.1.0\ModuleNew.psm1:31 char:14 + … classes = @(Get-ChildItem -Path (Join-Path -Path $PSScriptRoot -Child … + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Cannot find path 'C:\Temp\ModuleNew\Output\ModuleNew\0.1.0\Classes' because it does not exist.

Steps to Reproduce (for bugs)

  1. Create a new module with Stucco
  2. Set psakeFile parameter $PSBPreference.Build.CompileModule = $true
  3. Execute .\build.ps1 from a pwsh terminal

Context

This issue prevents me from being able to build a module.

Your Environment

  • Module version used: 0.6.1
  • Operating System and PowerShell version: Windows 10 22H2 , PowerShell 7.2.7

Task StageFile throws an error "no param 'ModuleManifestPath' "

Calling the task "StageFile" throws "ERROR: A parameter cannot be found that matches parameter name 'ModuleManifestPath'."

Expected Behavior

I expect the build to be successful.

Current Behavior

The build fails because the task "StageFile" calls Build-PSBuildModule with a param ModuleManifestPath that it doesn't support.

Possible Solution

Adding a ModuleManifestPath to
or
Removing the Line ModuleManifestPath from the hashtable

Steps to Reproduce (for bugs)

I converted a existing project to use PSBuild, by copy paste. I'm pretty sure it is easy to reproduce with a simple blank module.

Your Environment

  • Module version used:
  • Operating System and PowerShell version: Windows 10 1803, PS 5.1.17134.228

INIT task throws an exception in Windows PowerShell

Thanks for collecting so many PowerShell module build features in one place - I really appreciate this module and the well-thought collection of tasks/variables!

I spent a few minutes looking and didn't find any mention of the intended PowerShell version compatibility, so apologies if this has already been covered. I have a PowerShell 5.1 project that cannot be migrated to PowerShell 7, and the INIT task throws an exception when called from a Windows Powershell session.

I know it can add a lot of effort to maintain backward compatibility so I 100% understand if a conscious choice is made to forego support for Windows PowerShell / PowerShell 5.1. Since this looked to be the only barrier to using PowerShellBuild with my module I thought I'd ask.

Expected Behavior

PowerShellBuild tasks are compatible with PowerShell 5.1 as well as versions based on .NET 5+

Current Behavior

The following exception is thrown during the INIT task

Error: 9/7/2021 11:41:13 AM: 
At ~\Documents\WindowsPowerShell\Modules\PowerShellBuild\0.6.1\psakeFile.ps1:19 char:5 +     Initialize-PSBuild -UseBuildHelpers -BuildEnvironment $PSBPrefere ... +     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ [<<==>>] Exception: Method invocation failed because [System.IO.Path] does not contain a method named 'IsPathFullyQualified'.

Possible Solution

Out of an abundance of laziness, I switched from the IsPathFullyQualified() method to IsPathRooted() in Initialize-PSBuild.ps1 which is available in both PowerShell 5.1 and PowerShell 7. I know there's a difference between the two, so a better solution would probably involve creating a private function to reimplement the IsPathFullyQualified() functionality in a way that is compatible between 5.1 and 7+.

Steps to Reproduce (for bugs)

  1. Create a new module with Stucco
  2. Execute .\build.ps1 from a Windows PowerShell terminal

Context

I'm refactoring the build process for a PowerShell 5.1 module which is a wrapper for an SDK based on .NET Framework. I already use psake and PowerShellBuild allows me to drop a lot of boilerplate. Once I modified the Initialize-PSBuild function it worked flawlessly.

Your Environment

  • Module version used: 0.6.1
  • Operating System and PowerShell version: Windows 10 with PowerShell 5.1
  • Running .\build.ps1 from the Stucco template

additional Build task dependencies listed in $PSBPreference.Build.Dependencies do not run.

I have the task BumpVersion that I want the Build task to depend on. That said, I found $PSBPreference.Build.Dependencies and have supplied the following array @('StageFiles', 'BuildHelp', 'BumpVersion'). However, BumpVersion never runs. StageFiles and BuildHelp do run.

Expected Behavior

When running the Build task, additional dependencies listed in $PSBPreference.Build.Dependencies should also run.

Current Behavior

When running the Build task, additional dependencies listed in $PSBPreference.Build.Dependencies do not run. Strangely enough, when supplying $PSBPreference.Build.Dependencies with only BumpVersion the default build task dependencies StageFiles and BuildHelp still run making me think $PSBPreference.Build.Dependencies is not even being correctly passed.

Possible Solution

I've verified $PSBPreference.Build.Dependencies is being supplied to the Build task here:

task Build -depends $PSBPreference.Build.Dependencies -description 'Builds module and generate help documentation'

Steps to Reproduce (for bugs)

  1. simply set $PSBPreference.Build.Dependencies in the properties block of a psakeFile.ps1 with the value of @('MyExtraBuildTask')
  2. create a task in the psakeFile.ps1 e.g...
task MyExtraBuildTask {
    "doing extra things"
}
  1. run build.ps1

Context

I have a few extra tasks that I want to run as part of the build. Specifically, a task that bumps the module version if it has not already been incremented and also a task that uploads test results to appveyor when the BuildSystem is appveyor.

Your Environment

  • Module version used:
    PowerShellBuild = 0.3.0
    Psake = 4.8.0
  • Operating System and PowerShell version:
    MacOS 10.14.6
    PowerShell = 6.2.0

Project module not explicitly imported during testing

Pester tests that use InModuleScope fail to run because the psake Pester task does not import the project module. In addition to this issue, the module should be imported from the build output directory. This issue is difficult to reproduce as 1) it is dependant on Pester tests that use InModuleScope and 2) some other suit of tests (usually help.tests.ps1) having not already imported the module.

Expected Behavior

Test-PSBuildPester that is called by the psake Pester task should import the project module from the output directory.

Current Behavior

Pester tests that use InModuleScope fail to run resulting in the Pester test erroring with RuntimeException: No module named 'xyz' is currently loaded..

Possible Solution

Test-PSBuildPester that is called by the psake Pester task should import the project module from the output directory. Create a build property in the test hash named ModuleOutputManifest that is equal to the path of the built .psd1 file. This .psd1 file will be loaded within Test-PSBuildPester for use with all Pester tests.

Steps to Reproduce (for bugs)

  1. build a module with plaster via the current Stucco template 0.2.0
  2. create a pester test that uses InModuleScope
  3. run build.ps1 -bootstrap
  4. run build.ps1 -task pester

Context

I am unable to use PowerShellBuild's psake Pester Task on Pester tests that use InModuleScope.

Your Environment

  • Module version used: 0.4.0
  • Operating System and PowerShell version: macOS 10.14.6 / PowerShell 7.0.0

Publish task uses API key OR Credential but does not support both

The Publish task requires the API Key or Credential to be set but not both.

Expected Behavior

If I have provided credentials to the build and an API key I expect them to be both used.

Current Behavior

If an API Key is provided then the credentials are not used. Because the PowerShellGet cmdlets appear to be broken with regards to authentication (https://github.com/PowerShell/PowerShellGet/issues/433) you need to supply credentials with each cmdlet.

Allowing the use of both the API Key and Credentials would circumvent this.

Possible Solution

In the Publish task amend the code to use both API Key and Credential if supplied. If the PowerShellGet issues are resolved this will still not hurt.

Context

I can't publish the module to a private authenticated feed.

Your Environment

  • Module version used: 0.3.1
  • Operating System and PowerShell version: Windows 10

should configuration.Run.PassThru be set to true?

$configuration.Run.PassThru = $false

If this is set to $false, then no results are return

$testResult = Invoke-Pester -Configuration $configuration -Verbose:$VerbosePreference

And it will always be successful. For example:

https://github.com/pearcec/Invoke-Terraform/runs/2313617121?check_suite_focus=true#step:3:202

Build.Exclude ignored when Build.CompileModule is $true

When $PSBPreference.Build.CompileModule is $true the $PSBPreference.Build.Exclude is ignored and all .ps1 files found are used in the PSM1 file.

Expected Behavior

The files to be excluded in the $PSBPreference.Build.Exclude is honoured and the files are excluded from being compiled into the PSM1 file.

Current Behavior

When $PSBPreference.Build.CompileModule is $true the $PSBPreference.Build.Exclude is ignored and all .ps1 files found are used in the PSM1 file.

Possible Solution

The files are excluded.

Steps to Reproduce (for bugs)

Note you need to setup a proper build for this. These steps are those things that must be set / done:

  1. Set $PSBPreference.Build.Exclude to a file to be excluded;
  2. Set $PSBPreference.Build.CompileModule to $true
  3. Run the build;

Context

I am trying to exclude a folder of files from being compiled into the PSM1 file.

Your Environment

  • Module version used: 0.4.0
  • Operating System and PowerShell version: Windows Server 2016 version 1607

Unable to Follow Example Psakefile.ps1

I am running PSake 4.8.0 and imported the PowerShellBuild.Common. I am getting errors internally in PSake when running the example psakefile.ps1. I am getting empty stack and unable to find module assertion errors. I'm on the Shared-Module-Tasks branch on psake.

I got the same results under PSCore.

I'm willing to troubleshoot further if you require more information.

Environment

>$PSVersionTable
Name                           Value                                                                                                                                                                                
----                           -----                                                                                                                                                                                
PSVersion                      5.1.17134.165                                                                                                                                                                        
PSEdition                      Desktop                                                                                                                                                                              
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}                                                                                                                                                              
BuildVersion                   10.0.17134.165                                                                                                                                                                       
CLRVersion                     4.0.30319.42000                                                                                                                                                                      
WSManStackVersion              3.0                                                                                                                                                                                  
PSRemotingProtocolVersion      2.3                                                                                                                                                                                  
SerializationVersion           1.1.0.1     

Module Versions

> Get-Module psake,powershellbuild.common

ModuleType Version    Name                                ExportedCommands
---------- -------    ----                                ----------------
Script     0.1.0      PowerShellBuild.Common              {Build-PSBuildMAMLHelp, Build-PSBuildMarkdown, Build-PSBuildModule, Build-PSBuildUpdatableHelp...}
Script     4.8.0      psake                               {Assert, Exec, FormatTaskName, Framework...}

Errors

Assert: Unable to find module [PowerShellBuild.Common].
At C:\Users\ngetchell\Git\psake\src\public\Assert.ps1:69 char:9
+         throw ('Assert: {0}' -f $failureMessage)
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : OperationStopped: (Assert: Unable ...lBuild.Common].:String) [], RuntimeException
+ FullyQualifiedErrorId : Assert: Unable to find module [PowerShellBuild.Common].
 
Exception calling "Peek" with "0" argument(s): "Stack empty."
At C:\Users\ngetchell\Git\psake\src\public\Task.ps1:199 char:5
+     $currentContext = $psake.context.Peek()
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : InvalidOperationException
 
The property 'default' cannot be found on this object. Verify that the property exists and can be set.
At C:\Users\ngetchell\Git\psake\src\public\Task.ps1:258 char:9
+         $currentContext.tasks.$taskKey = $newTask
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : PropertyNotFound
 
You cannot call a method on a null-valued expression.
At C:\Users\ngetchell\Git\psake\src\public\Task.ps1:256 char:9
+         Assert (-not $currentContext.tasks.ContainsKey($taskKey)) ($m ...
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : InvokeMethodOnNull
 
Exception calling "Peek" with "0" argument(s): "Stack empty."
At C:\Users\ngetchell\Git\psake\src\public\Task.ps1:199 char:5
+     $currentContext = $psake.context.Peek()
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : InvalidOperationException
 
Exception calling "Peek" with "0" argument(s): "Stack empty."
At C:\Users\ngetchell\Git\psake\src\public\Properties.ps1:60 char:5
+     $psake.context.Peek().properties.Push($properties)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : InvalidOperationException

psakefile.ps1 contents

Remove-Module [p]owershellbuild.common
Remove-Module [p]sake -force
Import-Module Git:\psake\src\psake.psd1 -DisableNameChecking -Force
Import-Module Git:\PowerShellBuild.Common\PowerShellBuild.Common\PowerShellBuild.Common.psd1 -DisableNameChecking -Force

properties {
    # These settings overwrite values supplied form the PowerShellBuild.Common
    # module and govern how those tasks are executed
    $scriptAnalysisEnabled = $false
    $codeCoverageEnabled = $true
}

task default -depends Build

task Build -FromModule PowerShellBuild.Common -Version '0.1.0'

Running the Test task fails when $PSBPreference.Test.CodeCoverage.Enabled is set to $true

Executing the Test task fails when processing the Code Coverage results with error:

System.Management.Automation.RuntimeException: CodeCoverage.CoverageFormat must be 'JaCoCo' or 'CoverageGutters', but it was , please review your configuration.

Expected Behavior

Expect to get the Code Coverage results in line with:

Code Coverage:

Type: [Instruction]: 0.00%
Type: [Line]: 0.00%
Type: [Method]: 100.00%
Type: [Class]: 100.00%

Current Behavior

Looking at the code for the latest release of the module (version 0.6.1), there seems to be a typo in the Task Pester declaration when setting the CodeCoverageOutputFileFormat value:

CodeCoverageOutputFileFormat = $PSBPreference.Test.CodeCoverage.OutputFormat

Looking at the build.properties.ps1 file, that particular Ordered dictionary key is set to:

 # The code coverage output format to use
OutputFileFormat = 'JaCoCo'

Possible Solution

It's a simple Typo fix - update the psakeFile.ps1 Task Pester entry from:

CodeCoverageOutputFileFormat = $PSBPreference.Test.CodeCoverage.OutputFormat

To

CodeCoverageOutputFileFormat = $PSBPreference.Test.CodeCoverage.OutputFileFormat

Alternative (and temporary) workaround - update the invoking psakeFile.ps1 properties section to call the override of the mis-named property:

$PSBPreference.Test.CodeCoverage.OutputFormat = 'JaCoCo'

This has the desired effect.

Steps to Reproduce (for bugs)

  1. In your invoking module's psakeFile.ps1 properties section, include:
properties {
    $PSBPreference.Test.ScriptAnalysisEnabled = $true
    $PSBPreference.Test.CodeCoverage.Enabled  = $true
}
  1. Run the Test Task
  2. Tests run, failure occurs on the Code Coverage step

Context

I'm still in the early stages of incorporating the scaffolding on offer by this module into our development workflow. This is clearly not a critical bug (there's a simple enough workaround), but it's also low hanging fruit for fixing (I can do a PR)

Your Environment

  • Module version used: 0.6.1
  • Operating System and PowerShell version: 7.2.3

Importing module fails under Core on Linux

Expected Behavior

When importing the module under Core on Linux it should work as it does under Windows.

Current Behavior

The module fails to load the public functions from the 'public' folder.

Possible Solution

The folder is not called 'public' but 'Public'. Windows doesn't care about path case. Linux does.

Steps to Reproduce (for bugs)

  1. Under Core on Linux just import the module as normal.

Your Environment

  • Module version used: 0.3.0
  • Operating System and PowerShell version: Ubuntu |PowerShell 6.1.2

Not possible to disable PSScriptAnalyzer in properties

I chose to override some properties in pssake.ps1:

properties {

# Set this to $true to create a module with a monolithic PSM1
$PSBPreference.Build.CompileModule = $false
$PSBPreference.Help.DefaultLocale = 'en-US'
$PSBPreference.Test.OutputFile = 'out/testResults.xml'
# These settings overwrite values supplied from the PowerShellBuild
# module and govern how those tasks are executed
$PSBPreference.Test.ScriptAnalysisEnabled = $false
$PSBPreference.Test.CodeCoverage.Enabled  = $false
$PSBPreference.Publish.PSRepository = 'pwsh'
}

Expected Behavior

It should be possible to enable or disable CodeCoverage or PSScriptAnalyzer Tasks

Current Behavior

I can enable or disable CodeCoverage or override the name of the PSGallery used without any problem,
but it is not possible to disable the PSScriptanalyzer as describe.

Possible Solution

For now I disable the Analyze Step in build.properties.ps1 on my build agent,
because the Analyze Step fails ?randomly? from time to time.

Steps to Reproduce (for bugs)

  1. add $PSBPreference.Test.ScriptAnalysisEnabled = $false to pssake.ps1
  2. add $PSBPreference.Test.CodeCoverage.Enabled = $true to pssake.ps1
  3. Build

Context

Your Environment

Powershell 5.1
I always use all the required dependency's in the required version

INIT task throws an exception in Windows PowerShell

The INIT task throws an exception when called from a Windows Powershell session. This same issue was previously reported in issue #53 and fixed with merge #60. However, the fix seems to have since been reverted causing the issue to return.

Expected Behavior

PowerShellBuild tasks should also be compatible with PowerShell 5.1

Current Behavior

Receive error:
Exception: Method invocation failed because [System.IO.Path] does not contain a method named 'IsPathFullyQualified'.

Possible Solution

Re-implement the fix from merge #60

Steps to Reproduce (for bugs)

  1. Create a new module with Stucco
  2. Execute .\build.ps1 from a Windows PowerShell terminal

Context

I was attempting to build a PowerShell 5.1 module. Once I modified the Initialize-PSBuild function based on the change in merge #60 it worked flawlessly.

Your Environment

*Module version used: 0.6.1
Operating System and PowerShell version: Windows 10 with PowerShell 5.1
Running .\build.ps1 from the Stucco template

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.