Added a number of additional details for the breaking changes being
introduced in order to make it easier for existing users to migrate
their code.
Some very minor changes have been additionally made to fix some
documentation or parameter typename issues. Given that 0.15.0 still
hasn't been officially published yet, these changes will be part of
the eventual 0.15.0 release.
All state-changing commands (with the exception of `New-*`) are now silent by default. Users can pass-in `-PassThru` to make them return the result that used to be returned by default.
Users can revert back to the previous behavior by leveraging the new configuration value: `DefaultPassThru`.
Resolves#217
The `NoStatus` parameter (and `DefaultNoStatus` config value) were deprecated as part of #253 when we stopped showing status except for multi-page requests that exceeded some minimum number of pages.
At that time, `NoStatus` (and `DefaultNoStatus`) were not removed in order to minimize the churn to the module. However, keeping it in is adding unnecessary complexity to the module as we continue to expand what the module can do.
This change removes `NoStatus` (and `DefaultNoStatus`) from the module entirely. The only impact that this may cause is with users who are currently using one (or both) of them. This breaking change impact should be minimal, but its best for the breaking change to be part of the coming release which already has a number of other breaking changes as well, as opposed to having more breaking changes in a successive release.
Improves and standardizes the WhatIf/Confirm ('ShouldProcess') processing across all the functions.
* Moved the `$PSCmdlet.ShouldProcess` check out of `Invoke-GHRestMethod` and added it to the calling functions with the correct operation and target.
* Added `WhatIf:$false` and `Confirm:$false` to the `Out-File` Cmdlet call in the `Write-Log` function in the Helpers module. This will prevent the `Write-Log` function displaying `WhatIf` and `Confirm` prompts.
* Removed `ShouldProcess` from non-state changing functions.
* Modified the current `ShouldProcess` conditions to use an early return.
* Modified the `Set-GitHubIssueLabel` function to remove `ConfirmImpact='High'` and set `ConfirmPreference` to 'Low' if no labels have been specified instead.
* Modified the `Update-GitHubRepository` function to remove `ConfirmImpact='High'` and set `ConfirmPreference` to 'Low' if the repo is being renamed instead.
This completes the required work to support the set of Releases API's.
It adds the following functions:
* `New-GitHubRelease`
* `Set-GitHubRelease`
* `Remove-GitHubRelease`
* `Get-GitHubReleaseAsset`
* `New-GitHubReleaseAsset`
* `Set-GitHubReleaseAsset`
* `Remove-GitHubReleaseAsset`
`Invoke-GHRestMethod` has been updated to be able to upload a file (via the new `InFile` parameter) and download a file (via the `Save` switch which will cause it to return back a `FileInfo` object of a temporary file which can then be renamed as seen fit by the caller).
This also adds formatters for `GitHub.Release` and `GitHub.ReleaseAsset`.
Positional Binding has been set as `false` for the three functions, and `Position` attributes added to the function's mandatory parameters.
Reference: [GitHub Releases](https://developer.github.com/v3/repos/releases/)
Fixes#47Fixes#110
Somehow two spaces got added after `'Description' =` in a function and then got copy/paste repeated throughout the module.
This fixes that.
It also adds a ruler line at the 100 character mark in VS Code to help developers see when they should start to wrap their code/comments.
# Description
Comprehensively adds pipeline support throughout the entire module
This change required examining every method, and in some cases a few breaking changes (noted below) had to be introduced in order to make support work consistently end-to-end. UT's were added for every function, which resuled in a few bugs that were identified and fixed (also noted below).
## Breaking changes
### Unavoidable Breaks
* `Get-GitHubRepositoryBranch`: `Name` parameter is now `BranchName`.
> A `GitHub.Repository` object has a `name` property which is the name of the repo. Piping in the repo object to this method would confuse it, making it search for a branch with the name of the repo, as opposed to the desired effect of just listing out all branches in the repo.
* `*-GitHub*Label`: `Name` parameter is now `Label`.
> Similar to above.
> `Name` was too generic and was causing unintended conflicts when passing in certain objects over the pipeline (like a `GitHub.Repository`) which also has a `name` property, making it impossible to pipe in a repository to list all labels (since it was trying to query for a label in that repository named the same as the repo.
* `*-GitHubLabel`: `Milestone` parameter is now `MilestoneNumber`.
> A `GitHub.Issue` contains a `milestone` object property, and PowerShell was complaining that there was no way to convert that to an `[int64]` when an Issue was passed in via the pipeline. The only way to avoid this was to use `MilestoneNumber` which is the name of the property we add to `GitHub.Milestone` objects, and it's what we alias to in all other methods that interact with milestones.
* `*-GitHubIssue`: `Milestone` parameter is now `MilestoneNumber`.
> A `GitHub.Issue` contains a `milestone` object property, and PowerShell was complaining that there was no way to convert that to an `[int64]` when an Issue was passed in via the pipeline. The only way to avoid this was to use `MilestoneNumber` which is the name of the property we add to `GitHub.Milestone` objects, and it's what we alias to in all other methods that interact with milestones.
* `Get-GitHubLicense`: `Name` parameter is now `Key`.
> The `key` is what you can query against, but a License object has _both_ a `name` and a `key` property, which caused piped object queries to fail with the existing parameter name.
* `Get-GitHubCodeOfConduct`: `Name` parameter is now `Key`.
> Similar to above.
> The `key` is what you can query against, but a Code of Conduct object has _both_ a `name` and a `key` property, which caused piped object queries to fail with the existing parameter name.
* `New-ProjectCard`: Signature has changed. Instead of specifying `ContentId` and `ContentType`, you now just directly specify either `IssueId` or `PullRequestId`.
> Pipeline input would not have worked without this change. Additionally, this simply provides a cleaner interface for users in general, requiring one less input.
* `Get-GitHubUserContextualInformation`: Signature has changed. Instead of specifying `SubjectId` and `SubjectType`, you now just directly specify either `OrganizationId`, `RepositoryId`, `IssueId` or `PullRequestId`.
> Similar to above.
> Pipeline input would not have worked without this change. Additionally, this simply provides a cleaner interface for users in general, requiring one less input.
### Breaks With Workarounds
* A number of changes to the Comments functions
* `GitHubComments.ps1` was renamed to `GitHubIssueComments.ps1` given that there are 5 different types of comments, these functions focus on `Issue` comments, and there doesn't currently appear to be a path forward for creating a single unified API set for all comment types.
* All of these methods were renamed from `*-GitHubComment` to `*-GitHubIssueComment`, however they were also aliased back to their previous names (for now). You should really migrate to these new names however.
* The main parameter was renamed from `CommentId` to `Comment`, however it was aliased back to `CommentId`.
* `*-GitHubProject`: `ArchivedState` parameter is now `State` (but aliased back to `ArchivedState` to help with migration).
* `*-GitHubProject`: `Name` parameter is now `ColumnName` (but aliased back to `Name`)
* `*-GitHubProjectColumn`: `Name` parameter is now `ColumnName` (but aliased back to `Name`)
* `Move-GitHubProjectCard`: `ColumnId` parameter is now `Column` (but aliased back to `ColumnId` to support pipeline input).
* `Get-GitHubRelease`: `ReleaseId` parameter is now `Release` (but aliased back to `ReleaseId` to support pipeline input).
* `Rename-GitHubRepository` has been effectively deprectaed. It was built on top of the same endpoint that `Set-GitHubRepository` uses, but was only modifying a single property (the name). For now, the function remains, but it now just internally calls into `Set-GitHubRepository` to perform the same action.
* `Set-GitHubRepositoryTopic`: `Name` parameter is now `Topic` (but aliased back to `Name`).
* `Get-GitHubUser`: `User` parameter is now `UserName` (but aliased back to `User` and `Name`).
* `Get-GitHubUserContextualInformation`: `User` parameter is now `UserName` (but aliased back to `User` and `Name`).
## Bug Fixes:
* Events had been using a typo'd version of the `sailor-v` AcceptHeader. This was fixed as part of the migration to using the AcceptHeader constants.
* `Lock-GitHubIssue` was not correctly providing the `lock_reason` value to the API, so that metadata was getting lost. This was caught by new UT's and then fixed.
* `Update-GitHubLabel` was modified to accept colors both with and without a leading # sign, just like `New-GitHubLabel` already supported.
## New Features:
* `Get-GitHubGitIgnore` has a new `RawContent` switch which allows you to directly get back the content of the actual .gitignore file.
* `Set-GitHubRepository` has been updated to allow users to change the name (rename) the repository at the same time as making any of their other changes. If a new name has been specified, users will be required to confirm the change, or to specify `-Confirm:$false` and/or `-Force` to avoid the confirmation.
* `Get-GitHubRepositoryCollaborator` has gained a new parameter `Affiliation` allowing you to filter which collaborators you're interested in querying for.
## Minor updates:
* Fixed the casing of the "microsoft" OwnerName in any examples
* Fixed the casing of `GitHub` in the `Assignee` method names (was `Github` intead of `GitHub`
* Added new configuration property (`DisablePipelineSupport`) to assist with pipeline development
* All `AcceptHeader` usage has migrated to using script-wide constants
* `Split-GitHubUri` can now return both components in a single function call if no switch is specified.
* Added `Join-GitHubUri` which can reverse what `Split-GitHubUri` does, based on the configured `ApiHostName`.
* Adds type information (via `.OUTPUTS` and `[OutputType()]` for every function.
* Documentation updates reflecting the new pipeline support.
## Test changes:
* `Set-StrictMode -Version 1.0` has been specified for all tests to catch access to undeclared variables (which should help catch common typo errors)
* The workarounds for PSScriptAnalyzer's false complaint for rule `PSUseDeclaredVarsMoreThanAssignments` have been removed, and all test files now suppress that rule.
* A test file now exists for every module file, and some tests were moved around to the appropriate file (away from GitHubAnalytics.tests.ps1 which had previously been a dumping ground for tests).
* A _substantial_ number of new tests have been added. Every function should now be tested with limited exceptions (like for Organizations and Teams where we don't yet have the support in the module to get the account in the appropriate state to be able to query with those existing functions).
> Note: These tests fully pass with Pester 4.10.1. Some additional work may be done prior to merging to get them passing with Pester 5.0, but the priority is to get this merged into master soon in order to unblock the pipeline of existing pull requests that have been waiting on this change.
#### Issues Fixed
- Fixes#63
#### References
[The whole API set](https://developer.github.com/v3/)
Howard Wolosky
Simon Heather
Tyler James Leonhardt