As you put time and effort into that awesome next script or module, what happens to it after it’s fulfilled its immediate use for you? Chances are, it’s probably doomed to be forgotten in some long-lost folder provided value to no one. Just because you’re done with it doesn’t mean that you should just abandon it. Why not spruce it up a bit and share it with the community?
I can hear you now, “but.but..there’s requirements that must be met that I don’t feel like doing and, besides, my code isn’t good enough!”. Well, the first complaint I’m about to show you how to remove but the second is up to you to decide. To push code to the PowerShell Gallery, there has to be some kind of requirements. However, if you look at the current requirements, you’ll see that Microsoft isn’t asking for much. In any case, it was still an excuse you could use.until now.
Even though the requirements are minimal, there still is a little bit of work that must happen before a module can be uploaded. I’m always up for an automation challenge so let’s see if how little we can make the barrier to entry here.
First up, we need to define all of the possible changes that may have to occur with our module before it can be uploaded. Here are a few I can think of off the top of my head including the actual Gallery requirements:
- Clean up for any proprietary information (company references, internal paths, functions referenced in other related modules, etc.)
- I’ve started a module called ScrubShare for this, but it needs some TLC. It’s a good start, though.
- Pester tests
- A module manifest exists with at least the
- Passes a
The only real requirement for a Gallery module is the module manifest so why did I include the other “requirements”? Because these aren’t technically requirements but tasks you probably want to do as a best practice. If you can define your own “requirements” for publishing a module to the Gallery you can then begin to develop some automation around this. This is exactly what I did.
Introducing the PowerShellGallery module.
This is a script that removes all the barriers to entry to publishing a new module to the PowerShell Gallery that tests to ensure your module meets certain requirements and, if not, prompts you to fix them in the script itself. Then when all the tests have passed, it will publish the module as well!
I implemented all of this module because I found that I’d run the test, forget about it and then not end up fixing it because I’d get sidetracked. I’d then have to remember the syntax for
Publish-Module, track down my NuGet key and by that time, I was just out of the notion. Now, I have no excuse, and neither do you!
Here’s how it works:
Point it at a PSM1 file that you’d like to publish to the Gallery, answer a few questions if any of the tests fail and answer ‘Yes’ to publish it to the Gallery. Done.
Well, technically, it’s not that easy, but that was what I was shooting for. If you haven’t already published anything to the Gallery, you’ll have to get a NuGet API key. Instructions for signing up can be found on the Gallery. You’ll then need to open up the script and place this key as the default value for the
NuGetApiKey parameter or you can use
$PSDefaultParameters to do so.
That is honestly the only manual step you’ll have to do if you’re happy with the default tests. By default, it will ensure all of the typical Gallery requirements are fulfilled like a manifest being available and all of the required keys to be populated. It also runs
Test-ModuleManifest to ensure the manifest is well formed and even includes configurable optional tests that, for now, just test to ensure you have a
Tests.ps1 file in the same folder. If not, it will read all of the exported functions inside of the module and create some
Describe blocks for you as a guide.
Once it’s through the tests, it will ask you if you’d like to publish to the Gallery right there. You can publish immediately or just hit ‘N’ to forego that to do it manually which it will then produce the syntax to do that for you!