pcgeek86 / PSGitHub

This PowerShell module contains commands to manage GitHub through its REST API.
MIT License
186 stars 37 forks source link

Set up continuous integration service #16

Closed pcgeek86 closed 8 years ago

pcgeek86 commented 8 years ago

We need to configure a continuous integration system, such as AppVeyor, to automatically publish new versions of the PSGitHub PowerShell module to the PowerShell Gallery. We could potentially use Azure Automation for this purpose as well, by triggering a Runbook using webhook integration.

NOTE: New versions of the module should only be published when code is pushed to a certain Git branch or Git tag.

If you have a proposal for the best method of configuring this, then let me know. I've successfully used AppVeyor for this purpose in the past, but we don't have to use it either.

PlagueHO commented 8 years ago

I've got my LabBuilder Module doing this. You can see the AppVeyor.yml here.

On each commit it:

  1. Runs Pester tests.
  2. Assembles all build artifacts and publishes them with the AppVeyor build (just in case I need to check out what went wrong with the tests etc).
  3. The files for the module are staged and converted into a NUGET package.
  4. If the commit is a Push to Master (any other branches don't do this) and all tests have passed then the NUGET package will be published to PSGallery (using the encrypted credentials that you create via your AppVeyor account).

It would be fairly easy to adapt this process to your module if it would help?

pcgeek86 commented 8 years ago

That sounds good to me, @PlagueHO :) I added a few specific child tasks to the original report. Don't forget to patch the module manifest! :smile: I did something similar to you, in this project: https://github.com/pcgeek86/azure-powershell-extensions

PlagueHO commented 8 years ago

Nice! I really do need to automate the module manifest build number - mind if I borrow your https://github.com/pcgeek86/azure-powershell-extensions/blob/production/Patch-ModuleManifest.ps1? :smile:

pcgeek86 commented 8 years ago

@PlagueHO You're more than welcome to use it! Sorry, didn't see your reply right away last night.

ps. There's a better way of substituting the build number -- mine uses regular expressions, which is rather "hacky."

PlagueHO commented 8 years ago

Thanks @pcgeek86 ! I actually ended up snagging your Regex and using that. I reversed the process though so that the Version number in the Manifest is the master version. The AppVeyor.yml script reads that Version number out of the manifest when it first starts and then adds the build number to it and:

  1. Inserts it back into the Manifest (using more of your code)
  2. Tells AppVeyor to use this build number.

The reason I did this is that I have a user who automates their environments by pulling the master branch directly from GitHub. Therefore they needed the correct major/minor version number (minus the build) in the manifest to begin with. This just enables me to have a single master version number location that everything pulls from.

Thanks again!

Anyway, do you want me to pop through a PR with the AppVeyor.yml for this project? If so, shall I use your model or my one?

pcgeek86 commented 8 years ago

@PlagueHO A PR would be great! I'll probably substitute that with my encrypted NuGet API key for the PowerShell Gallery, and then point AppVeyor over at this repo. Thanks!