Add GitHub dependency type

[RamblingCookieMonster]

While we already have a git dependency type, this has pretty heavy overhead, either requiring you to have git installed, or to bootstrap git outside of this process. In some cases, this is an unrealistic expectation.

On the other hand, while we have a FileDownload dependency type, this doesn't account for the post-download operations (extracting archive, resulting folder name including the branch, etc.), which should ideally be abstracted out.

@dfinke Recently wrote a handy function to simplify installing a module from a GitHub repo. We'll borrow ideas and a little code from this. Additionally, we'll borrow BuildHelpers code to help identify PowerShell modules under a particular path, to accommodate repos that have module files at the root of the repo, in a nested folder, etc.

Down the line, I could see this being the default dependency type for simple syntax including a single '/', where full git urls would continue defaulting to the git dependency type.

[RamblingCookieMonster]

Initial work with no tests whatsoever in 1765455e

[RamblingCookieMonster]

A few quick examples to illustrate how this might be used:

@{
    'bundyfx/vamp' = 'master'
}

• Downloads https://github.com/bundyfx/vamp/
• Sees that the root vamp folder has a matching vamp.psd1. Copies this whole root folder to the target (defaults to $ENV:USERPROFILE\Documents\WindowsPowerShell\Modules)

@{
    'ramblingcookiemonster/psslack' = 'master'
}

• Downloads https://github.com/RamblingCookieMonster/PSSlack
• Sees that there is a PSSlack\PSSlack subfolder with matching PSSlack.psd1 manifest, identifies the subfolder as the project path
• Copies PSSlack\PSSlack to specified target

@{
    'powershell/demo_ci' = @{
        Version = 'master'
        DependencyType = 'GitHub'
        Target = 'C:\temp'
        Parameters = @{
            ExtractPath = 'Assets/DscPipelineTools',
                          'InfraDNS/Configs/DNSServer.ps1'
        }
    }
}

• Grabs https://github.com/PowerShell/Demo_CI
• Extracts Demo_CI/Assets/DscPipelineTools and InfraDNS/Configs/DNSServer.ps1 to C:\temp

Lastly, the logic for identifying a project underneath a repo is borrowed and tweaked from BuildHelpers, in this function. It's ugly, but covers typical PowerShell project layouts, and will default to repo root if none are found. This may need tweaking if more projects start using Plaster and the src subfolder...

Leaving this open until I can write tests, wrap up the PSDependAction 'Test' portion. Oh. The Test portion won't be fun - Do we just test if something already exists? Use file hashes? Overwrite? Not versioned like a gallery or real git repo. Sigh.

Cheers!

[dargmuesli]

I'm working on the versioning issue. Here are my thoughts, please comment on them:

1. GitHub repositories can be versioned. There can be releases. This seems to be the only logical way to version a PowerShell module within PS's logic (modules folder, ...). Because:

2. We can version GitHub project by their latest SHA. But then there can't be a version check by PowerShell. If there are two folders like this:

   • modules
   • 1a3\script (which is v1)
   • 32b\script (which is v2)

... with 1a3 and 32b being the hashes, which folder is PowerShell gonna import?

Answer: none! Those hash-folders are not recognized.

[dargmuesli]

After reading the documentation Installing a PowerShell Module, I see no way to have PowerShell find multiple commit-versions of the same module-version. We must use GitHub releases (and Git tags) for this issue.