Description
the template gitignore doesn't contain entries for testresults or scratch as the source code for stucco does

Describe the solution you'd like
2 additional entries in the template gitignore

Describe any alternatives you've considered
currently we create a module from stucco, then manually replace

Additional context

Description
I don't use (or even have) the Initialize.ps1, and it makes the psm1 fail.

Steps to Reproduce
New module from templace, no classes, no mkdocs, with gitlab CI.

Current Behavior
When trying to load the module it fails because it cannot dot source the initialize.ps1

Expected behavior
No error on module import

Possible Solution
Test-path initialize.ps1 in the psm1 before dot-sourcing it.

Environment

• Module version used: 3.1, freshly updated
• Operating System and PowerShell version: Win10 20H2 and PS 7.1

PS : I tried finding that code on GitHub but I think it hasn't been pushed here. Is that possible? The only reference to that line is on the powershell gallery :(

Thanks a lot for your work!

Description
After creating a new module and executing the build.ps1 script the pester tests are failing with the following error messages:

Running tests from 'C:\!_Projects\myproject\tests\Help.tests.ps1'
Describing Test help for <_.Name>
[-] Describe Test help for <_.Name> failed
  CommandNotFoundException: The term 'script:FilterOutCommonParams' is not recognized as a name of a cmdlet, function, script file, or executable program.
  Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
  at <ScriptBlock>, C:\!_Projects\myproject\tests\Help.tests.ps1:54

Describing Test help for <_.Name>
[-] Describe Test help for <_.Name> failed
  CommandNotFoundException: The term 'script:FilterOutCommonParams' is not recognized as a name of a cmdlet, function, script file, or executable program.
  Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
  at <ScriptBlock>, C:\!_Projects\myproject\tests\Help.tests.ps1:54

Describing Test help for <_.Name>
[-] Describe Test help for <_.Name> failed
  CommandNotFoundException: The term 'script:FilterOutCommonParams' is not recognized as a name of a cmdlet, function, script file, or executable program.
  Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
  at <ScriptBlock>, C:\!_Projects\myproject\tests\Help.tests.ps1:54

Current Behavior
Individual function based Pester tests fail to run.

Expected behavior
Individual function based Pester tests successfully run.

Possible Solution
In ".\tests\Help.tests.ps1" I removed the "script" scope from all references to the "FilterOutCommonParams" function and moved this into its own external module file ".\tests\HelpFunctions.psm1".
Then I removed the "FilterOutCommonParams" function from the "BeforeDiscovery" code block and replaced this with an Import-Module:

BeforeDiscovery {
    # Make sure HelpFunctions.psm1 is loaded - it contains FilterOutCommonParams
    Import-Module -Name (Join-Path -Path $PSScriptRoot -ChildPath 'HelpFunctions.psm1') -Verbose:$false -Force

    $manifest             = Import-PowerShellDataFile -Path $env:BHPSModuleManifest
    $outputDir            = Join-Path -Path $env:BHProjectPath -ChildPath 'Output'
    $outputModDir         = Join-Path -Path $outputDir -ChildPath $env:BHProjectName
    $outputModVerDir      = Join-Path -Path $outputModDir -ChildPath $manifest.ModuleVersion
    $outputModVerManifest = Join-Path -Path $outputModVerDir -ChildPath "$($env:BHProjectName).psd1"
     ...

I tried experimenting with BeforeAll blocks and a few other things but this was the only solution I tried that work in both PowerShell 7 and VSCode.

To allow the Tasks to run from VSCode (Ctrl + P; task; Test) the .vscode\tasks.json file also needs the PowerShell executable path updating to "C:\Program Files\PowerShell\7\pwsh.exe" because PowerShell 5.1 fails at INIT with:

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

Environment

• Module version used:

ModuleType Version    PreRelease Name
---------- -------    ---------- ----
Script     2.0.16                BuildHelpers
Script     0.6.1                 PowerShellBuild
Script     4.9.0                 psake
Script     1.19.1                PSScriptAnalyzer

• Operating System and PowerShell version:

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

Description

When running the New-StuccoModule cmdlet under the latest version 0.5.0, if you select to Include VSCode dev container support during the wizard, you will receive an error because there is no longer a .devcontainer file in the module's templates/ directory:

In Version 0.5.0 of the module, you have removed various files in the module's templates/ directory. See below for a comparison of the installed module's contents comparing Version 0.4.0 and 0.5.0:

• Version 0.4.0:

• Version 0.5.0:

Steps to Reproduce

1. Install and Import Version 0.5.0 of the Stucco Module: Install-Module Stucco > Import-Module Stucco.
2. Run New-StuccoModule -DestinationPath .\MyModule
3. During the wizard ensure you reply Y for the question: Do you want to include VSCode dev container support?
4. Receive error Cannot find path <PSModulesDirectory>\Stucco\0.5.0\template\.devcontainer' because it does not exist.

Current Behavior

Receive error Cannot find path <PSModulesDirectory>\Stucco\0.5.0\template\.devcontainer' because it does not exist.

Expected behavior

Cleanly create new modules.

Possible Solution

Add back missing templates files/folders.

Screenshots

Environment

• Module version used: 0.5.0
• Operating System and PowerShell version:

Additional context

Description
Stucco does not appear to support Pester 5.0 due to breaking changes, primarily the requirement to use hyphens before test assertions (e.g. Should *-*Be - the previous behaviour has been removed), and the new processing/discovery logic which means certain code has to be wrapped in blocks like 'BeforeDiscovery' or 'BeforeAll'.

Steps to Reproduce
Install Pester 5.0, use Plaster with Stucco, attempt to build and test the project.

Install-Module -Name Pester -Force -SkipPublisherCheck
Install-Module Plaster -Scope CurrentUser
Install-Module Stucco -Scope CurrentUser
$template = Get-PlasterTemplate -IncludeInstalledModules | Where-Object TemplatePath -Match 'Stucco'
Invoke-Plaster -TemplatePath $template.TemplatePath
[...]
.\build.ps1 -Task Test

Current Behavior
Build fails, e.g. not using hyphens before test commands:
$script:manifest.Name | Should [-]Be $env:BHProjectName

e.g. foreach loop not working and code not in correct scope leading to null variables:
[-] Test help for Get-HelloWorld.gets description for Get-HelloWorld 9ms (8ms|1ms)
Expected a value, but got $null or empty.
at $help.Description | Should -Not -BeNullOrEmpty, C:\Users\johndoe\source\Repos\HelloWorld\tests\Help.tests.ps1:35
at , C:\Users\johndoe\source\Repos\HelloWorld\tests\Help.tests.ps1:35

Expected behavior
Build/test should succeed.

Possible Solution
Update all test commands, remove foreach loop, and wrap code in appropriate blocks.

When installing dependencies via PSDepend I run into an issue with the signed version of Pester. Running on PowerShell Core 6.1.2

Expected Behavior

The dependencies install without issue.

Current Behavior

PackageManagement\Install-Package : The version '4.4.1' of the module 'Pester' being installed is not catalog signed.

Possible Solution

Choose a different version of Pester which doesn't generate an catalog file error or add a skip publisher option in PSDepends requiremnts file.

Steps to Reproduce (for bugs)

Git:\NickTest> Invoke-PSDepend -Path .\requirements.psd1 -Install

Your Environment

Name Value

PSVersion 6.1.2
PSEdition Core
GitCommitId 6.1.2
OS Microsoft Windows 10.0.17763
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0

Stucco commit id: db21e8b

Description
Classes are not imported.

Steps to Reproduce
New Module from stucco with classes.

Current Behavior
Classes are not imported

Expected behavior
Classes are imported

Possible Solution

use this (in module.psm1) when we say yes to classes :

$classes = @(Get-ChildItem -Path (Join-Path -Path $PSScriptRoot -ChildPath 'Classes/*.ps1') -Recurse -ErrorAction Stop)

foreach ($import in @($classes + $public + $private )) {
    try {
        . $import.FullName
    } catch {
        throw "Unable to dot source [$($import.FullName)]"
    }
}

Environment

• Module version used: latest
• Operating System and PowerShell version:
  Win10-2004
  PS5.1

See the bottom of #38 for details:

Note that during my inspection of these test files I found some other potential areas of improvement also.

For example, on my machine, I have two git executables on my PATH and therefore the statement $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue) would return git.exe git.exe instead of just git.exe causing the $thisCommit = & $git log --decorate --oneline HEAD~1..HEAD expression to fail:

I simply addressed this issue by changing $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue) to $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue)[0] to ensure it always is singular.

Now I'm in the clear!

Solution to be provided in PR for both issues if you want them (if not that's fine also!).

I personally would like to see GitLab-CI supported as a possible CI option. Appveyor still makes sense as the default, just thinking about it as another option.

Description
Add optional support for GitHub Actions to be wired up during module creation.

Describe the solution you'd like
Options should be added to the Plaster manifest to ask if GitHub Actions support is wanted for psake task execution on code commit, and/or PSScriptAnalyzer to be run on pull requests.

There are GitHub Actions for psake task execution and PSScriptAnalyzer here:

• https://github.com/devblackops/psake-github-action
• https://github.com/devblackops/github-action-psscriptanalyzer

If the user selects yes, to either of these, then the main.workflow file should be added to the .github folder where the existing issue/PR templates live.

Describe any alternatives you've considered
Nope

Additional context
GitHub Actions is still in beta and not many people have access yet. There is no harm in adding these files to repos where the owner is not in the beta. When GItHub eventually releases Actions, these should just work automagically (baring breaking changes to Actions between now and release).

Description
When the boilerplate/example output is generated with Azure Pipelines CICD, and then built using the configured Azure Pipelines hosted agent, the build task fails with the following error -
Invoke-Git : fatal: ambiguous argument 'Powershell': unknown revision or path not in the working tree.

Steps to Reproduce

1. Run Plaster with Stucco template, specify Azure Pipelines as the CI of choice
2. Commit resulting scaffold to Azure Repos git repo
3. Create a new Azure Pipelines pipeline using the yaml configuration provided
4. Run the pipeline, pipeline will fail

Current Behavior

2019-10-02T06:37:41.3923308Z ##[section]Starting: Build and Test
2019-10-02T06:37:41.4034056Z ==============================================================================
2019-10-02T06:37:41.4034109Z Task         : PowerShell
2019-10-02T06:37:41.4035286Z Description  : Run a PowerShell script on Linux, macOS, or Windows
2019-10-02T06:37:41.4035324Z Version      : 2.151.2
2019-10-02T06:37:41.4035359Z Author       : Microsoft Corporation
2019-10-02T06:37:41.4035418Z Help         : https://docs.microsoft.com/azure/devops/pipelines/tasks/utility/powershell
2019-10-02T06:37:41.4035454Z ==============================================================================
2019-10-02T06:37:42.7477834Z Generating script.
2019-10-02T06:37:42.8919200Z ========================== Starting Command Output ===========================
2019-10-02T06:37:42.9211389Z ##[command]"C:\Program Files\PowerShell\6\pwsh.exe" -NoLogo -NoProfile -NonInteractive -ExecutionPolicy Unrestricted -Command ". 'd:\a\_temp\13196e40-d3e5-431e-8575-2605ead37909.ps1'"
2019-10-02T06:37:53.9059999Z VERBOSE: Acquiring providers for assembly: C:\program files\powershell\6\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.CoreProviders.dll
2019-10-02T06:37:53.9766460Z VERBOSE: Acquiring providers for assembly: C:\program files\powershell\6\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.MetaProvider.PowerShell.dll
2019-10-02T06:37:53.9772010Z VERBOSE: Acquiring providers for assembly: C:\program files\powershell\6\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.ArchiverProviders.dll
2019-10-02T06:37:53.9776303Z VERBOSE: Acquiring providers for assembly: C:\program files\powershell\6\Modules\PackageManagement\coreclr\netstandard2.0\Microsoft.PackageManagement.NuGetProvider.dll
2019-10-02T06:38:49.2034932Z Invoke-Git : fatal: ambiguous argument 'Powershell': unknown revision or path not in the working tree.
2019-10-02T06:38:49.2037004Z At C:\Users\VssAdministrator\Documents\PowerShell\Modules\BuildHelpers\2.0.8\Public\Get-BuildVariable.ps1:184 char:17
2019-10-02T06:38:49.2037075Z + ...             Invoke-Git @IGParams -Arguments "log --format=%B -n 1 $(  ...
2019-10-02T06:38:49.2038540Z +                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2019-10-02T06:38:49.2038794Z + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
2019-10-02T06:38:49.2040288Z + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-Git
2019-10-02T06:38:49.2040535Z  
2019-10-02T06:38:49.3464963Z ##[error]PowerShell exited with code '1'.
2019-10-02T06:38:49.3939499Z ##[section]Finishing: Build and Test

Expected behavior
No error returned and successful pipeline

Possible Solution
Fixed locally by updating BuildHelpers from 2.0.8 to 2.0.11

Environment

• Module version used:
• Operating System and PowerShell version: Windows Server 2016 with Visual Studio 2017 (Microsoft Hosted image) with Powershell 6.2.2

Additional context

Description

When using powershell 7.4 (7.3.X and earlier fine)
The Tests in Help.tsts.ps1 now fails due to an additional  common parameter in PowerShell 7.4.
The Help.Tsts.ps1 attempts to filter out common params through a hard coded list but that is now missing one,
specifically "ProgressAction"

On development workstations this will occur when the local runtime is bumped to 7.4, however, it will also with the devcontainer due to powershell:latest being called, which now brings 7.4

Steps to Reproduce
Merely update the powershell runtime to PowerShell 7.4.1 or later (i haven't tested 7.4.0), and run the regular build file.
you will get a series of errors showing that the parameter ProgressAction doesn't have help description or type.

Additionally just run the normal tests from the default devcontainer.

Current Behavior
help.tsts.ps1 returns some incorrect pester fails.

Expected behavior
help.tsts.ps1 doesn't validate common params

Possible Solution
2 solutions considered,

• update help.tsts.ps1 static list of common params with the new param
• update help.tsts.ps1 static list of common params with dynamic list of common and optional params
  theoretically, either will work for now, but the dynamic option will be more resilient to future changes to Powershell.
  PR coming with recommended solution of dynamic list.

original code (doesn't work on 7.4.X)

        $commonParams = @(
            'Debug', 'ErrorAction', 'ErrorVariable', 'InformationAction', 'InformationVariable',
            'OutBuffer', 'OutVariable', 'PipelineVariable', 'Verbose', 'WarningAction',
            'WarningVariable', 'Confirm', 'Whatif'
        )

amended dynamic code (works on 7.X)(tested on 7.2 7.3 and 7.4)

        $commonParams = [System.Management.Automation.PSCmdlet]::OptionalCommonParameters + [System.Management.Automation.PSCmdlet]::CommonParameters

Screenshots

Environment

• Module version used: 0.4.0 0.5.0 and master
• Operating System and PowerShell version: ubuntu 20.04 - Ubuntu 22.04 and Windows 11, Powershell Versions 7.2 7.3 7.4

Additional context
we have a series of internal powershell modules that use the testing provided in help.tsts.ps1
the automated tests that run on our various agents cause these tests to fail if the powershell version is 7.4
while we can control the agent PS version, this is getting in the way of some development work where we have less control over the specific powershell versions. additionally the default devcontainer runs with powershell:latest , causing this model to fail as well

the fix proposed won't fix our prior deployed modules we will need to amend them, however it will prevent future modules experiencing the same issue

Description
If you commit the initial module generated by Stucco, the Github Action for CI fails because it can't load Pester.

Fix after changing it to 5.3.3:

Steps to Reproduce

1. Create new module
2. Create repo and commit code unchanged
3. Watch CI job fail on Windows and Mac (e.g. https://github.com/HeyItsGilbert/TunnelGoons/actions/runs/2593549732
4. Update requirements.psd1 to use Pester 5.3.3.
5. Watch is succeed (e.g. https://github.com/HeyItsGilbert/TunnelGoons/actions/runs/2593629739)

Current Behavior
The CI.yaml job fails in Github.

Expected behavior
The CI.yaml job succeeds on Github with the initial version of the module.

Possible Solution
Update requirements.psd1 to use Pester 5.3.3

Description
When running build.ps1 you get errors.

Steps to Reproduce

1. Create a module
2. Run .\build.ps1

Current Behavior

Describing Test help for <_.Name>
[-] Describe Test help for <_.Name> failed
  CommandNotFoundException: The term 'script:FilterOutCommonParams' is not recognized as a name of a cmdlet, function, script file, or executable program.
  Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
  at <ScriptBlock>, E:\Code\libguestfsPS\tests\Help.tests.ps1:54

Expected behavior
Shouldn't produce test errors after creating module from template.

Possible Solution
In Help.tests.ps1 , lines 44, 54, and 56:
Replace script:FilterOutCommonParams with FilterOutCommonParams

Screenshots
N/A

Environment

• Module version used: 0.4.0
• Operating System and PowerShell version:

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

Additional context
N/A

Description
We should support optionally adding dev container support with VSCode.

Describe the solution you'd like
We should add another option to add dev container support during module creation.

Describe any alternatives you've considered
N/A

Additional context
Because it's awesome

When invoking plaster using the stucco template you are prompted to set a description but it never makes it to the PSD1 file.

Expected Behavior

When prompted for a description, it should carry over to the PSD1 file.

Current Behavior

The psd1 file has a commented out Description with no text.

Possible Solution

There are two different names for the attribute used in the manifest. They are as follows.

    <parameter name='Description'
               type='text'
               prompt='Enter a description of the module'/>

    <newModuleManifest destination='${PLASTER_PARAM_ModuleName}\${PLASTER_PARAM_ModuleName}.psd1'
                       moduleVersion='$PLASTER_PARAM_Version'
                       rootModule='${PLASTER_PARAM_ModuleName}.psm1'
                       author='$PLASTER_PARAM_FullName'
                       description='$PLASTER_PARAM_ModuleDesc'
                       encoding='UTF8-NoBOM'/>

I tried setting the variables to the same name but no luck.

Steps to Reproduce (for bugs)

$Template = Get-PlasterTemplate -Path .\Output\Stucco\0.1.0\plasterManifest.xml
Invoke-Plaster -TemplatePath $template.TemplatePath -DestinationPath "c:\users\ngetchell\documents\git\Example3"

Context

Luckily the pester tests catch the error.

Your Environment

• Module version used: 0.1.0
• Operating System: Microsoft Windows 10.0.17763
• PowerShell version: 6.1.0

Description
Hey There 👋, Thank you for this template, It has been pretty useful for my work and I've been using it to start my projects.

This is not a feature request, It's more a Question regarding using coverage tests within this template.

Describe the solution you'd like
I would like to have coverage tests generated by plaster while keep using the standard template provided by stucco.

Describe any alternatives you've considered
I've considered dropping the stucco template to use other build systems, but powershellbuild is what fit the best with my context.

Additional context
here is the header of my psakeFile.ps1

    $PSBPreference.Build.CompileModule = $false
    $PSBPreference.Help.DefaultLocale = 'en-US'
    $PSBPreference.Test.OutputFile = 'out/testResults.xml'
    $PSBPreference.Test.ImportModule = $true
    $PSBPreference.Test.CodeCoverage.Enabled  = $true
    $PSBPreference.Test.CodeCoverage.OutputFormat= "JaCoCo"
    $PSBPreference.Test.CodeCoverage.OutputFile= "out/CoverageResults.xml"

My problem is that my coverage results are like this:

Type: [Instruction]: 0.000%
Type: [Line]: 0.000%
Type: [Method]: 0.000%
Type: [Class]: 100.000%

I don't understand why I'm not getting coverage for methods, I'm not using any class on this project.

Here is my overall structure:

├── build.ps1
├── CHANGELOG.md
├── Dockerfile
├── LICENSE
├── makefile
├── psakeFile.ps1
├── README.md
├── requirements.psd1
├── resources
├── Module-Name
│   ├── Private
│   │   ├── Api-Versions
│   │   │   ├── health.ps1
│   │   │   ├── v1Search.ps1
│   │   │   └── v1Solve.ps1
│   │   └── Web-Pages
│   │       └── home_page.html
│   ├── Public
│   │   ├── Get-Binary.ps1
│   │   ├── Get-Version.ps1
│   │   ├── Start-Server.ps1
│   │   └── Test-Env.ps1
│   ├── Module-Name.psd1
│   └── Module-Name.psm1
└── tests
    ├── Endpoints
    │   ├── Health.tests.ps1
    │   ├── Search.tests.ps1
    │   └── Solve.tests.ps1
    ├── Help.tests.ps1
    ├── Manifest.tests.ps1
    ├── MetaFixers.psm1
    ├── Meta.tests.ps1
    ├── readme.md
    ├── ScriptAnalyzerSettings.psd1
    └── Unit
        └── Public
            └── Test-Env.tests.ps1

Here is my code coverage output:

Covered 55% / 75%. 20 analyzed Commands in 1 File.
Missed commands:

File            Class Function                   Line Command
----            ----- --------                   ---- -------
MetaFixers.psm1       ConvertTo-UTF8               19 $content = Get-Content -Raw -Encoding Unicode -Path $FileInfo.FullName
MetaFixers.psm1       ConvertTo-UTF8               20 [System.IO.File]::WriteAllText($FileInfo.FullName, $content, [System.Text.Encoding…
MetaFixers.psm1       ConvertTo-SpaceIndentation   33 $content = (Get-Content -Raw -Path $FileInfo.FullName) -replace "`t", '    '
MetaFixers.psm1       ConvertTo-SpaceIndentation   33 Get-Content -Raw -Path $FileInfo.FullName
MetaFixers.psm1       ConvertTo-SpaceIndentation   34 [IO.File]::WriteAllText($FileInfo.FullName, $content)
MetaFixers.psm1       Get-UnicodeFilesList         79 $root
MetaFixers.psm1       Get-UnicodeFilesList         79 Get-TextFilesList
MetaFixers.psm1       Get-UnicodeFilesList         79 Where-Object { Test-FileUnicode $_ }
MetaFixers.psm1       Get-UnicodeFilesList         79 Test-FileUnicode $_



Code Coverage:

Type: [Instruction]: 0.000%
Type: [Line]: 0.000%
Type: [Method]: 0.000%
Type: [Class]: 100.000%

Would you mind to guide me on how to add coverage tests as intended without stop using your template? I really Like it and would like to stick with it as long as possible.

Description
When using v0.5.0 I get the following error:

Get-Content : Cannot find path 'C:\Program Files\WindowsPowerShell\Modules\Stucco\0.5.0\template\cicd.gitlab-ci.yml' because it does not exist.

Steps to Reproduce

1. Run the documented commands:
   $template = Get-PlasterTemplate -IncludeInstalledModules | Where-Object TemplatePath -Match 'Stucco'
   Invoke-Plaster -TemplatePath $template.TemplatePath

2. During the selections pick GitLab for the CI/CD implementation.

Current Behavior
Produces an error and stops further processing.

Expected behavior
Implement the GitLab template in the module output directory.

Screenshots

Environment

• Module version used: v0.5.0
• Operating System and PowerShell version: Windows 10 Enterprise 21H2 with PowerShell 5.1

Description

• Update dependencies/requirements in both the module and template itself.
• The Build/Test steps are failing due to a mismatch in PowerShellBuild version in psake task FromModule and the one defined in requirements.psd1

Describe the solution you'd like

PR incoming!

Describe any alternatives you've considered

Updating them in my generated module but where's the fun in that ;)

Additional context

I also wanted to start a discussion in general about dependency management in PowerShell development:

• What's the best practice around this?
• I find it hard to consolidate the following features without complex code/Build processes:
  • Module requirements
  • Development only requirements
  • Auto install/import modules when this module is required
    • I do know there's RequiredModules in the Module Manifest but it only downloads the dependencies when installing it for the first time.
    • It doesn't have any more smarts like npm.
  • Dependency hell/version management/virtualenv
    • I wonder how conflicting dependencies are managed in a shared shell environment. As in, when module x and y require different incompatible version of module z.
    • Also while developing how can one do a form of virtualenv without polluting their shell? (I think PSDepend has something like this as long as all dependency management goes through it)

Elsewhere I've tried this:

• Use PSDepend with requirements.psd1 and requirements.dev.psd1 for their respective dependencies.
• Get-Dependency -Path requirements.psd1 and set the Module Manifest's RequiredModules (requirements.dev is not included)
  • if Version is latest do not set a version for the dependency in Manifest.
  • If Version is compatible with [Version] type then set that.
  • RequiredModules only works with [Version] type. PSDepend and PSGallery works with SemVer.
• Use a build.ps1 file to install dependencies, just like Stucco.
• Therefore when developing the module, one can download/install both requirements and requirements.dev
• When installing the module from a repository as an end user, the injected details into RequiredModules should install the necessary modules.
• I also toyed with the idea of just invoking PSDepend in the module thus all dependency management going through PSDepend at all levels. However it didn't seem right to bypass PowerShell's packagemanagement and also hinders general metadata/discoverability as the Module Manifest isn't fully descriptive of what the Module is doing/needs.

What do you think?

Description
GitHub supports multiple issue templates on repositories. We should add bug and feature templates to Stucco.

Describe the solution you'd like
Multiple issue templates are available for users to accurately describe the issue.

Describe any alternatives you've considered
Nope

Additional context
Make it more awesome.

Description

Great package, I have been using the template for all of my modules! I noticed that during builds/testing my modules would always fail when implementing the Manifest.tests.ps1 tests with outputs like the following:

Even after releasing a couple tagged versions of my module and ensuring the manifest was correct, my tests were still skipping/failing this section, so I decided to dive a little deeper.

One thing to note is this isn't necessarily a bug, but more of a feature/enhancement to increase the flexibility of the tag detection via regex.

Details:

I tag my release commits with tags such as v0.0.1, v1.2.3, etc. (i.e. using a v before the semantic version).

The pattern currently being used is on [Line 73 of Manifest.tests.ps1](

However, I realized that instead of using \s* (AKA a space followed by anything; which is where my v comes into play), \s?. should be used instead.

Why? Because using * matches the previous token between zero and unlimited times, as many times as possible, giving back as needed (greedy), whereas using ?. says "optionally match anything once and move on" (for lack of a better way to explain regex).

Therefore, changing the pattern from 'tag:\s*(\d+(?:\.\d+)*)' to 'tag:\s?.(\d+(\.\d+)*)' fixed the test execution for my issue.

Steps to Reproduce

1. Create a tagged git commit with the syntax v0.0.1.

2. Run git log --decorate --oneline HEAD~1..HEAD and examine the output, it should include a tag: v0.0.1 string on the output:

3. Run ./build.ps1 -Task Test or the Manifest.tests.ps1 script block directly and examine the output from the Git tagging section at the bottom. Notice how the $gitTagVersion = matches[1] statement fails?

Current Behavior

Failure to detect git tags in tests when they exist.

Expected behavior

All typical tagging patterns should be detected and passed in the test (i.e. 0.0.1 or v0.0.1, etc.)

Possible Solution

Change the RegEx matching expression to be more flexible in its detection of a tag from the git log.

Change 'tag:\s*(\d+(?:\.\d+)*)' to 'tag:\s?.(\d+(\.\d+)*)' to add flexibility for detection.

A more robust approach would be to:

a) Check for the word tag: in the git log result and fail if none detected (i.e. no tags)
b) Match everything after tag: and before the next comma ,, to extract the tag text.
c) Remove all letters and punctuation except for a period . from the tag text.
c) Validate the extracted tag's version from (c) to the [Version] type and compare with manifest version, etc.

See above.

I have also already fixed it in my fork of this repo: see jimbrig/Stucco - Manifest.tests.ps1.

I can submit a PR as well.

For more RegEx details see the following examples:

• https://regex101.com/r/EwkNsR/1 (fixed pattern)
  vs.
• https://regex101.com/r/7khTAR/1 (old pattern failing)

Screenshots

Environment

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

Additional context

Note that during my inspection of these test files I found some other potential areas of improvement also.

For example, on my machine, I have two git executables on my PATH and therefore the statement $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue) would return git.exe git.exe instead of just git.exe causing the $thisCommit = & $git log --decorate --oneline HEAD~1..HEAD expression to fail:

I simply addressed this issue by changing $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue) to $git = (Get-Command git -CommandType Application -ErrorAction SilentlyContinue)[0] to ensure it always is singular.

Thanks!