Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/RamblingCookieMonster/BuildHelpers
Helper functions for PowerShell CI/CD scenarios
https://github.com/RamblingCookieMonster/BuildHelpers
appveyor build build-automation build-pipelines ci-cd continuous-deployment continuous-integration powershell powershell-modules
Last synced: about 2 months ago
JSON representation
Helper functions for PowerShell CI/CD scenarios
- Host: GitHub
- URL: https://github.com/RamblingCookieMonster/BuildHelpers
- Owner: RamblingCookieMonster
- License: mit
- Created: 2016-05-26T12:36:00.000Z (over 8 years ago)
- Default Branch: master
- Last Pushed: 2023-08-11T15:04:37.000Z (about 1 year ago)
- Last Synced: 2024-05-01T13:26:05.261Z (5 months ago)
- Topics: appveyor, build, build-automation, build-pipelines, ci-cd, continuous-deployment, continuous-integration, powershell, powershell-modules
- Language: PowerShell
- Size: 345 KB
- Stars: 208
- Watchers: 14
- Forks: 48
- Open Issues: 43
-
Metadata Files:
- Readme: README.md
- Funding: .github/FUNDING.yml
- License: LICENSE
Awesome Lists containing this project
- awesome-powershell - BuildHelpers - Helper functions for PowerShell CI/CD scenarios. 🚧 (🛠️ Build Tools)
- jimsghstars - RamblingCookieMonster/BuildHelpers - Helper functions for PowerShell CI/CD scenarios (PowerShell)
README
[](https://ci.appveyor.com/project/RamblingCookieMonster/buildhelpers)
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
```powershell
# 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
```powershell
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:
```powershell
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
```powershell
# 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:
[](https://ci.appveyor.com/project/RamblingCookieMonster/psdepend/build/1.0.91)
### 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:
```powershell
# 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.
```powershell
# 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!