microsoft
/
PowerShellForGitHub
зеркало из https://github.com/microsoft/PowerShellForGitHub.git
1
0
Форкнуть 0
Код Задачи Пакеты Проекты Релизы Вики Активность
PowerShellForGitHub/Tests/GitHubProjectCards.tests.ps1

524 строки
20 KiB
PowerShell
Исходник Обычный вид История

Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License.
<#
.Synopsis
Tests for GitHubProjectCards.ps1 module
#>
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
[CmdletBinding()]
[Diagnostics.CodeAnalysis.SuppressMessageAttribute('PSUseDeclaredVarsMoreThanAssignments', '',
Justification='Suppress false positives in Pester code blocks')]
param()
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
# This is common test code setup logic for all Pester test files
$moduleRootPath = Split-Path -Path $PSScriptRoot -Parent
. (Join-Path -Path $moduleRootPath -ChildPath 'Tests\Common.ps1')
try
{
# Define Script-scoped, readOnly, hidden variables.
@{
defaultProject = "TestProject_$([Guid]::NewGuid().Guid)"
defaultColumn = "TestColumn"
defaultColumnTwo = "TestColumnTwo"
defaultCard = "TestCard"
defaultCardTwo = "TestCardTwo"
defaultCardUpdated = "TestCard_Updated"
defaultArchivedCard = "TestCard_Archived"
defaultIssue = "TestIssue"
}.GetEnumerator() | ForEach-Object {
Set-Variable -Force -Scope Script -Option ReadOnly -Visibility Private -Name $_.Key -Value $_.Value
}
$repo = New-GitHubRepository -RepositoryName ([Guid]::NewGuid().Guid) -AutoInit
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$project = New-GitHubProject -OwnerName $script:ownerName -RepositoryName $repo.name -ProjectName $defaultProject
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$column = New-GitHubProjectColumn -Project $project.id -ColumnName $defaultColumn
$columntwo = New-GitHubProjectColumn -Project $project.id -ColumnName $defaultColumnTwo
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
$issue = New-GitHubIssue -Owner $script:ownerName -RepositoryName $repo.name -Title $defaultIssue
Describe 'Getting Project Cards' {
BeforeAll {
$card = New-GitHubProjectCard -Column $column.id -Note $defaultCard
$cardArchived = New-GitHubProjectCard -Column $column.id -Note $defaultArchivedCard
Updates all state-changing commands to be silent by default (with -PassThru) (#276) 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
2020-08-14 22:35:53 +03:00
Set-GitHubProjectCard -Card $cardArchived.id -Archive
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
Get PSScriptAnalyzer clean again (#180) Somehow a number of PSScriptAnalyzer issues snuck in. This fixes them. The main PSScriptAnalyzer issues needing to be fixed were: * `PSReviewUnusedParameter` - This one came up a lot due to our heavy usage of `Resolve-RepositoryElements` and `Resolve-ParameterWithDefaultConfigurationValue` which both end up referencing their parameters by grabbing them off the stack. That means that `NoStatus` and `Uri` are frequently never directly referenced. So, exceptions were added. There were two cases (in GitHubAnalytics) where there was a false positive due to PowerShell/PSScriptAnalyzer#1472 * `PSUseProcessBlockForPipelineCommand` - We had a number of functions that took pipeline input, but didn't actuall use the `process` block. This actually caught a bug with `Group-GitHubIssue` and `Group-GitHubPullRequest`. Added correct `process` block usage for most of the functions, but removed pipeline support for those where it didn't actually make sense anymore. * `PSUseDeclaredVarsMoreThanAssignments` - These are false positives in the Pester tests due to the usage of `BeforeAll`. There wasn't an obvious way to use `SuppressMessageAttribute` in the Pester test, so I used a hacky workaround to "use" the variable in the `BeforeAll` block. I could have added the suppression to the top of the file, but I still want to catch real issues in those files later. * `PSAvoidOverwritingBuiltInCmdlets` - It turns out that there's a bug with PSDesiredStateConfiguration in PS Core 6.1.0 where it was exporting internal functions. This was thus a false-postive flag for Write-Log. See PowerShell/PowerShell#7209 for more info. Also, it turns out that `Group-GitHubPullRequest` hadn't actually been exported, so I fixed that too.
2020-05-26 18:01:17 +03:00
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
AfterAll {
$null = Remove-GitHubProjectCard -Card $card.id -Confirm:$false
}
Context 'Get cards for a column' {
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$results = @(Get-GitHubProjectCard -Column $column.id)
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get cards' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results | Should -Not -BeNullOrEmpty
}
It 'Should only have one card (since it defaults to not archived)' {
$results.Count | Should -Be 1
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Note is correct' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results[0].note | Should -Be $defaultCard
}
It 'Has the expected type and additional properties' {
$results[0].PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$results[0].CardId | Should -Be $results[0].id
$results[0].ProjectId | Should -Be $project.id
$results[0].ColumnId | Should -Be $column.id
$results[0].IssueNumber | Should -BeNullOrEmpty
$results[0].RepositoryUrl | Should -BeNullOrEmpty
$results[0].PullRequestNumber | Should -BeNullOrEmpty
$results[0].creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Get all cards for a column' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results = @(Get-GitHubProjectCard -Column $column.id -State All)
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get all cards' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results.Count | Should -Be 2
}
It 'Has the expected type and additional properties' {
foreach ($item in $results)
{
$item.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$item.CardId | Should -Be $item.id
$item.ProjectId | Should -Be $project.id
$item.ColumnId | Should -Be $column.id
$item.IssueNumber | Should -BeNullOrEmpty
$item.RepositoryUrl | Should -BeNullOrEmpty
$item.PullRequestNumber | Should -BeNullOrEmpty
$item.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Get archived cards for a column' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result = Get-GitHubProjectCard -Column $column.id -State Archived
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get archived card' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Note is correct' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.note | Should -Be $defaultArchivedCard
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Should be archived' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.Archived | Should -Be $true
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
Context 'Get non-archived cards for a column (with column on pipeline)' {
$result = $column | Get-GitHubProjectCard -State NotArchived
It 'Should get non-archived card' {
$result | Should -Not -BeNullOrEmpty
}
It 'Should have the right ID' {
$result.id | Should -Be $card.id
}
It 'Should not be archived' {
$result.Archived | Should -Be $false
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
}
Describe 'Modify card' {
BeforeAll {
$card = New-GitHubProjectCard -Column $column.id -Note $defaultCard
$cardTwo = New-GitHubProjectCard -Column $column.id -Note $defaultCardTwo
$cardArchived = New-GitHubProjectCard -Column $column.id -Note $defaultArchivedCard
}
Get PSScriptAnalyzer clean again (#180) Somehow a number of PSScriptAnalyzer issues snuck in. This fixes them. The main PSScriptAnalyzer issues needing to be fixed were: * `PSReviewUnusedParameter` - This one came up a lot due to our heavy usage of `Resolve-RepositoryElements` and `Resolve-ParameterWithDefaultConfigurationValue` which both end up referencing their parameters by grabbing them off the stack. That means that `NoStatus` and `Uri` are frequently never directly referenced. So, exceptions were added. There were two cases (in GitHubAnalytics) where there was a false positive due to PowerShell/PSScriptAnalyzer#1472 * `PSUseProcessBlockForPipelineCommand` - We had a number of functions that took pipeline input, but didn't actuall use the `process` block. This actually caught a bug with `Group-GitHubIssue` and `Group-GitHubPullRequest`. Added correct `process` block usage for most of the functions, but removed pipeline support for those where it didn't actually make sense anymore. * `PSUseDeclaredVarsMoreThanAssignments` - These are false positives in the Pester tests due to the usage of `BeforeAll`. There wasn't an obvious way to use `SuppressMessageAttribute` in the Pester test, so I used a hacky workaround to "use" the variable in the `BeforeAll` block. I could have added the suppression to the top of the file, but I still want to catch real issues in those files later. * `PSAvoidOverwritingBuiltInCmdlets` - It turns out that there's a bug with PSDesiredStateConfiguration in PS Core 6.1.0 where it was exporting internal functions. This was thus a false-postive flag for Write-Log. See PowerShell/PowerShell#7209 for more info. Also, it turns out that `Group-GitHubPullRequest` hadn't actually been exported, so I fixed that too.
2020-05-26 18:01:17 +03:00
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
AfterAll {
Adding -Force switch to ConfirmImpact=High functions (#226) Adding -Force switch to ConfirmImpact=High functions and updated affected tests/documentation Fixes #218
2020-06-10 17:59:23 +03:00
$null = Remove-GitHubProjectCard -Card $card.id -Force
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
Context 'Modify card note' {
Updates all state-changing commands to be silent by default (with -PassThru) (#276) 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
2020-08-14 22:35:53 +03:00
Set-GitHubProjectCard -Card $card.id -Note $defaultCardUpdated
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$result = Get-GitHubProjectCard -Card $card.id
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get card' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Note has been updated' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.note | Should -Be $defaultCardUpdated
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
Context 'Modify card note (via card on pipeline)' {
$result = $card | Get-GitHubProjectCard
It 'Should have the expected Note value' {
$result.note | Should -Be $defaultCardUpdated
}
Updates all state-changing commands to be silent by default (with -PassThru) (#276) 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
2020-08-14 22:35:53 +03:00
$card | Set-GitHubProjectCard -Note $defaultCard
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result = $card | Get-GitHubProjectCard
It 'Should have the updated Note' {
$result.note | Should -Be $defaultCard
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Archive a card' {
Updates all state-changing commands to be silent by default (with -PassThru) (#276) 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
2020-08-14 22:35:53 +03:00
Set-GitHubProjectCard -Card $cardArchived.id -Archive
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$result = Get-GitHubProjectCard -Card $cardArchived.id
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get card' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Card is archived' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.Archived | Should -Be $true
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Restore a card' {
Updates all state-changing commands to be silent by default (with -PassThru) (#276) 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
2020-08-14 22:35:53 +03:00
$cardArchived | Set-GitHubProjectCard -Restore
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$result = Get-GitHubProjectCard -Card $cardArchived.id
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Should get card' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Card is not archived' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.Archived | Should -Be $false
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Move card position within column' {
$null = Move-GitHubProjectCard -Card $cardTwo.id -Top
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$results = @(Get-GitHubProjectCard -Column $column.id)
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Card is now top' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results[0].note | Should -Be $defaultCardTwo
}
It 'Has the expected type and additional properties' {
$results[0].PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$results[0].CardId | Should -Be $results[0].id
$results[0].ProjectId | Should -Be $project.id
$results[0].ColumnId | Should -Be $column.id
$results[0].IssueNumber | Should -BeNullOrEmpty
$results[0].RepositoryUrl | Should -BeNullOrEmpty
$results[0].PullRequestNumber | Should -BeNullOrEmpty
$results[0].creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Move card using after parameter' {
$null = Move-GitHubProjectCard -Card $cardTwo.id -After $card.id
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$results = @(Get-GitHubProjectCard -Column $column.id)
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Card now exists in new column' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results[1].note | Should -Be $defaultCardTwo
}
It 'Has the expected type and additional properties' {
$results[1].PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$results[1].CardId | Should -Be $results[1].id
$results[1].ProjectId | Should -Be $project.id
$results[1].ColumnId | Should -Be $column.id
$results[1].IssueNumber | Should -BeNullOrEmpty
$results[1].RepositoryUrl | Should -BeNullOrEmpty
$results[1].PullRequestNumber | Should -BeNullOrEmpty
$results[1].creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
Context 'Move card using before parameter (card on pipeline)' {
$null = $cardTwo | Move-GitHubProjectCard -After $card.id
$results = @($column | Get-GitHubProjectCard)
It 'Card now exists in new column' {
$results[1].note | Should -Be $defaultCardTwo
}
It 'Has the expected type and additional properties' {
$results[1].PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$results[1].CardId | Should -Be $results[1].id
$results[1].ProjectId | Should -Be $project.id
$results[1].ColumnId | Should -Be $column.id
$results[1].IssueNumber | Should -BeNullOrEmpty
$results[1].RepositoryUrl | Should -BeNullOrEmpty
$results[1].PullRequestNumber | Should -BeNullOrEmpty
$results[1].creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Move card to another column' {
$null = Move-GitHubProjectCard -Card $cardTwo.id -Top -ColumnId $columnTwo.id
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$results = @(Get-GitHubProjectCard -Column $columnTwo.id)
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Card now exists in new column' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$results[0].note | Should -Be $defaultCardTwo
}
It 'Has the expected type and additional properties' {
$results[0].PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$results[0].CardId | Should -Be $results[0].id
$results[0].ProjectId | Should -Be $project.id
$results[0].ColumnId | Should -Be $columnTwo.id
$results[0].IssueNumber | Should -BeNullOrEmpty
$results[0].RepositoryUrl | Should -BeNullOrEmpty
$results[0].PullRequestNumber | Should -BeNullOrEmpty
$results[0].creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
Context 'Move card to another column (with column on pipeline)' {
$null = ($column | Move-GitHubProjectCard -Card $cardTwo.id -Top)
$result = $cardTwo | Get-GitHubProjectCard
It 'Card now exists in new column' {
$result.ColumnId | Should -Be $column.ColumnId
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Context 'Move command throws appropriate error' {
It 'Appropriate error is thrown' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
{ Move-GitHubProjectCard -Card $cardTwo.id -Top -Bottom } | Should -Throw 'You must use one (and only one) of the parameters Top, Bottom or After.'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
}
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
Describe 'Create Project Cards' {
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
Context 'Create project card with note' {
BeforeAll {
$card = @{id = 0}
}
Get PSScriptAnalyzer clean again (#180) Somehow a number of PSScriptAnalyzer issues snuck in. This fixes them. The main PSScriptAnalyzer issues needing to be fixed were: * `PSReviewUnusedParameter` - This one came up a lot due to our heavy usage of `Resolve-RepositoryElements` and `Resolve-ParameterWithDefaultConfigurationValue` which both end up referencing their parameters by grabbing them off the stack. That means that `NoStatus` and `Uri` are frequently never directly referenced. So, exceptions were added. There were two cases (in GitHubAnalytics) where there was a false positive due to PowerShell/PSScriptAnalyzer#1472 * `PSUseProcessBlockForPipelineCommand` - We had a number of functions that took pipeline input, but didn't actuall use the `process` block. This actually caught a bug with `Group-GitHubIssue` and `Group-GitHubPullRequest`. Added correct `process` block usage for most of the functions, but removed pipeline support for those where it didn't actually make sense anymore. * `PSUseDeclaredVarsMoreThanAssignments` - These are false positives in the Pester tests due to the usage of `BeforeAll`. There wasn't an obvious way to use `SuppressMessageAttribute` in the Pester test, so I used a hacky workaround to "use" the variable in the `BeforeAll` block. I could have added the suppression to the top of the file, but I still want to catch real issues in those files later. * `PSAvoidOverwritingBuiltInCmdlets` - It turns out that there's a bug with PSDesiredStateConfiguration in PS Core 6.1.0 where it was exporting internal functions. This was thus a false-postive flag for Write-Log. See PowerShell/PowerShell#7209 for more info. Also, it turns out that `Group-GitHubPullRequest` hadn't actually been exported, so I fixed that too.
2020-05-26 18:01:17 +03:00
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
AfterAll {
$null = Remove-GitHubProjectCard -Card $card.id -Confirm:$false
Remove-Variable -Name card
}
$card.id = (New-GitHubProjectCard -Column $column.id -Note $defaultCard).id
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$result = Get-GitHubProjectCard -Card $card.id
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Card exists' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Note is correct' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.note | Should -Be $defaultCard
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
Context 'Create project card with note (with column object via pipeline)' {
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
BeforeAll {
$card = @{id = 0}
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
}
AfterAll {
$null = Remove-GitHubProjectCard -Card $card.id -Confirm:$false
Remove-Variable -Name card
}
$newCard = $column | New-GitHubProjectCard -Note $defaultCard
$card.id = $newCard.id
$result = $newCard | Get-GitHubProjectCard
Get PSScriptAnalyzer clean again (#180) Somehow a number of PSScriptAnalyzer issues snuck in. This fixes them. The main PSScriptAnalyzer issues needing to be fixed were: * `PSReviewUnusedParameter` - This one came up a lot due to our heavy usage of `Resolve-RepositoryElements` and `Resolve-ParameterWithDefaultConfigurationValue` which both end up referencing their parameters by grabbing them off the stack. That means that `NoStatus` and `Uri` are frequently never directly referenced. So, exceptions were added. There were two cases (in GitHubAnalytics) where there was a false positive due to PowerShell/PSScriptAnalyzer#1472 * `PSUseProcessBlockForPipelineCommand` - We had a number of functions that took pipeline input, but didn't actuall use the `process` block. This actually caught a bug with `Group-GitHubIssue` and `Group-GitHubPullRequest`. Added correct `process` block usage for most of the functions, but removed pipeline support for those where it didn't actually make sense anymore. * `PSUseDeclaredVarsMoreThanAssignments` - These are false positives in the Pester tests due to the usage of `BeforeAll`. There wasn't an obvious way to use `SuppressMessageAttribute` in the Pester test, so I used a hacky workaround to "use" the variable in the `BeforeAll` block. I could have added the suppression to the top of the file, but I still want to catch real issues in those files later. * `PSAvoidOverwritingBuiltInCmdlets` - It turns out that there's a bug with PSDesiredStateConfiguration in PS Core 6.1.0 where it was exporting internal functions. This was thus a false-postive flag for Write-Log. See PowerShell/PowerShell#7209 for more info. Also, it turns out that `Group-GitHubPullRequest` hadn't actually been exported, so I fixed that too.
2020-05-26 18:01:17 +03:00
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
It 'Card exists' {
$result | Should -Not -BeNullOrEmpty
}
It 'Note is correct' {
$result.note | Should -Be $defaultCard
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -BeNullOrEmpty
$result.RepositoryUrl | Should -BeNullOrEmpty
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
Context 'Create project card from issue' {
BeforeAll {
$card = @{id = 0}
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
Get PSScriptAnalyzer clean again (#180) Somehow a number of PSScriptAnalyzer issues snuck in. This fixes them. The main PSScriptAnalyzer issues needing to be fixed were: * `PSReviewUnusedParameter` - This one came up a lot due to our heavy usage of `Resolve-RepositoryElements` and `Resolve-ParameterWithDefaultConfigurationValue` which both end up referencing their parameters by grabbing them off the stack. That means that `NoStatus` and `Uri` are frequently never directly referenced. So, exceptions were added. There were two cases (in GitHubAnalytics) where there was a false positive due to PowerShell/PSScriptAnalyzer#1472 * `PSUseProcessBlockForPipelineCommand` - We had a number of functions that took pipeline input, but didn't actuall use the `process` block. This actually caught a bug with `Group-GitHubIssue` and `Group-GitHubPullRequest`. Added correct `process` block usage for most of the functions, but removed pipeline support for those where it didn't actually make sense anymore. * `PSUseDeclaredVarsMoreThanAssignments` - These are false positives in the Pester tests due to the usage of `BeforeAll`. There wasn't an obvious way to use `SuppressMessageAttribute` in the Pester test, so I used a hacky workaround to "use" the variable in the `BeforeAll` block. I could have added the suppression to the top of the file, but I still want to catch real issues in those files later. * `PSAvoidOverwritingBuiltInCmdlets` - It turns out that there's a bug with PSDesiredStateConfiguration in PS Core 6.1.0 where it was exporting internal functions. This was thus a false-postive flag for Write-Log. See PowerShell/PowerShell#7209 for more info. Also, it turns out that `Group-GitHubPullRequest` hadn't actually been exported, so I fixed that too.
2020-05-26 18:01:17 +03:00
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
AfterAll {
Adding -Force switch to ConfirmImpact=High functions (#226) Adding -Force switch to ConfirmImpact=High functions and updated affected tests/documentation Fixes #218
2020-06-10 17:59:23 +03:00
$null = Remove-GitHubProjectCard -Card $card.id -Force
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
Remove-Variable -Name card
}
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$card.id = (New-GitHubProjectCard -Column $column.id -IssueId $issue.id).id
Fix multi-result behavior across all versions of PowerShell (fixes CI UT's on all platforms) (#199) Tests were failing on Mac and Linux, but not Windows ([recent test run](https://dev.azure.com/ms/PowerShellForGitHub/_build/results?buildId=83887&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb)). That's because Windows CI was running against PoSh 5.x while Linux and Mac were running on PoSh 7.x. There's a slight difference in behavior for how those two treat arrays. The real root cause for this was the behavior of `Invoke-GHRestMethodMultipleResult`. When creating `$finalResult`, it was always blindly adding the result to the existing array: https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L648 `...` https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L670 Oddly enough, this created a difference in behavior between PowerShell versions when making the result an array on the caller side. Now I ensure that I don't add anything to `$finalResult` unless there's actually a value. With that change, we can now be sure that when we grab the result as an array, it'll be appropriately empty or populated (and not populated with a single `$null` entry, thus making `Count` 1, erroneously). I removed the attempt to force the results to be an array, because this is pointless. PowerShell will always unwrap an array of 0 or 1 in a return result. If you want to ensure that a result is always an array, you have to [wrap the result in an object](https://stackoverflow.com/a/60330501) or you have to do wrap the result in an array on the caller side. https://github.com/microsoft/PowerShellForGitHub/blob/587e2042621091c79cc06be2aa9cc6ea836561f4/GitHubCore.ps1#L684-L685 I also normalized some naming in all of the tests, so that when we're getting back a singular result (by querying for a specific item) that we use a singular variable name, and a plural variable name otherwise. With this change, we should now be passing CI on all OS platforms and across PowerShell 4+. Resolves #198
2020-05-31 01:42:04 +03:00
$result = Get-GitHubProjectCard -Card $card.id
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
It 'Card exists' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result | Should -Not -BeNullOrEmpty
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
It 'Content url is for an issue' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
$result.content_url | Should -Match 'issues'
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -Be $issue.number
$result.RepositoryUrl | Should -Be $issue.RepositoryUrl
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
Context 'Create project card from issue (with issue object on pipeline)' {
BeforeAll {
$card = @{id = 0}
}
AfterAll {
$null = Remove-GitHubProjectCard -Card $card.id -Force
Remove-Variable -Name card
}
$newCard = $issue | New-GitHubProjectCard -Column $column.id
$card.id = $newCard.id
$result = $newCard | Get-GitHubProjectCard
It 'Card exists' {
$result | Should -Not -BeNullOrEmpty
}
It 'Content url is for an issue' {
$result.content_url | Should -Match 'issues'
}
It 'Has the expected type and additional properties' {
$result.PSObject.TypeNames[0] | Should -Be 'GitHub.ProjectCard'
$result.CardId | Should -Be $result.id
$result.ProjectId | Should -Be $project.id
$result.ColumnId | Should -Be $column.id
$result.IssueNumber | Should -Be $issue.number
$result.RepositoryUrl | Should -Be $issue.RepositoryUrl
$result.PullRequestNumber | Should -BeNullOrEmpty
$result.creator.PSObject.TypeNames[0] | Should -Be 'GitHub.User'
}
}
# TODO: Create a test that verifies cards created based on a pull request
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
Describe 'Remove card' {
Context 'Remove card' {
BeforeAll {
$card = New-GitHubProjectCard -Column $column.id -Note $defaultCard
}
$null = Remove-GitHubProjectCard -Card $card.id -Confirm:$false
It 'Project card should be removed' {
Adding complete Pipeline support to the entire module (#242) # 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/)
2020-06-18 08:26:59 +03:00
{Get-GitHubProjectCard -Card $card.id} | Should -Throw
}
}
Context 'Remove card (via pipeline)' {
BeforeAll {
$card = $column | New-GitHubProjectCard -Note $defaultCard
}
$null = $card | Remove-GitHubProjectCard -Force
It 'Project card should be removed' {
{$card | Get-GitHubProjectCard} | Should -Throw
Adding functionality for Project Cards (#163) Covers: - List project cards - Get a project card - Create a project card - Update a project card - Delete a project card - Move a project card
2020-05-12 20:41:34 +03:00
}
}
}
Remove-GitHubProject -Project $project.id -Confirm:$false
}
finally
{
if (Test-Path -Path $script:originalConfigFile -PathType Leaf)
{
# Restore the user's configuration to its pre-test state
Restore-GitHubConfiguration -Path $script:originalConfigFile
$script:originalConfigFile = $null
}
}