I’ve been fumbling my way through creating a proof of concept pipeline for PowerShell modules and I’m happy with how it is coming along but I’m getting stuck on how to actually control the flow of the pipeline when you do a commit. In other words, how do I control whether it builds and publishes or builds and deploys to prod/dev as examples. Currently, if I commit to master, the whole pipeline kicks off, my build tasks run and the compiled module is deployed to a file share. But what if I wanted to deploy to a different file share for testing?
I’ve seen a few examples of people using a build.settings.ps1 file and declaring some variables/parameters in there or using Tags to define if the build should be for dev or prod but unless i’m missing something that means I’d have to make sure I edit that settings.ps1 file each time I want to change the behavior.
(TLDR) So, I guess my question is: What is recommended or considered best practice for controlling pipeline flows?
Quick overview of how I’ve set up the pipeline and what tools I’m using:
<p class=“s1wjcqzz-10 lkEbBw”>- Project is in azure devops</p>
<p class=“s1wjcqzz-10 lkEbBw”>- Using a self hosted agent</p>
<p class=“s1wjcqzz-10 lkEbBw”>- Using azure-pipelines.yml file to define the job tasks</p>
<p class=“s1wjcqzz-10 lkEbBw”>- This calls a bootstrap.ps1 file first to install dependencies (using PSDepend)</p>
<p class=“s1wjcqzz-10 lkEbBw”>- Next it calls a build.ps1 script using InvokeBuild</p>
<p class=“s1wjcqzz-10 lkEbBw”>- build tasks include Analyze (runs PSScriptanalyzer), Test (Pester tests), and build (compiles the public functions into a single .psm1 file)</p>