I generally don't like aliases being used (neither does PSScriptAnalyzer), but in this case, `New-GitHubDeploymentEnvironment` was writting to be able to behave as `Set-GitHubDeploymentEnvironment` as well, and we should be testing it the way that a user would likely be calling it.
Adds the `SecretScanning` parameter to the `Set-GitHubRepository` function.
> The parameter was implemented using the `Enabled, Disabled` parameter validate set rather than a switch to mirror the pattern used by the GitHub API.
Fixes#390
#### References
- https://docs.github.com/en/rest/repos/repos#update-a-repository
Updated all Pester tests in the project to support Pester v5. The main benefit that we get out of this, besides just moving on to the currently supported version of the test framework, is that we can now execute individual tests directly within VS Code.
In the process of doing this migration:
* Removed repository Code of Conduct tests from GitHubMiscellaneous.tests.ps1 since the command has been deprecated by GitHub
* Updated GitHubReleases.tests.ps1 to account for pre-releases
* Updated run-unitTests.yaml and CONTRIBUTING.md to have the Pester v5.3.3 install command, as well as to update its invocation commands.
* Removed the language-specific error messages in some `-Throws` tests because the wording keeps changing.
* Updated this project's VSCode settings.json to take advantage of the fact that the tests are now Pester 5 compatible. This allows each individual block to have a Run/Debug link associated with it. ([More info](https://pester.dev/docs/usage/vscode)).
* Disabled all of the Projects/ProjectCards/ProjectColumns tests because Classic Projects have been deprecated by GitHub (#380 for more info)
Fixes#194
Co-authored-by: Howard Wolosky <HowardWolosky@users.noreply.github.com>
This reverts commit 1afe5ac872.
It turns out that this isn't quite working right.
The `use_squash_pr_title_as_default` parameter [has been deprecated per the documentation](https://docs.github.com/en/rest/repos/repos?apiVersion=2022-11-28#update-a-repository) in favor of `squash_merge_commit_title ` which works a bit differently.
Additionally, there appears to be a GitHub-side bug at the moment with changing the value of `allow_auto_merge` (it does not honor the request being sent).
Given this, for the time being we'll revert the change until we know that the feature is working correctly.
octocat recently updated all of its gists, starting on 2/24/2021.
The test previously would query for gists that were updated since 2016, but as of 2/24/2021, that included all of them.
The test has been made more robust by choosing the most recent date of all the gists and then requerying, which should hopefully now always guarantee that we'll get a reduced set of gists, unless all of the gists are suddenly updated in the future at the exact same second.
GitHub will return back a `202` response when the result for the query is not yet ready. GitHub requests that we "give the job a few moments to complete, and then submit the request again."
We already had the configuration value `RetryDelaySeconds` which covered how many seconds we would sleep before trying the request again. We tried the request again via a recursive call to `Invoke-GHRestMethod`.
It turns out that there's something going on with GitHub right now, and trying to get contributor statistics for a completely new repository never returns back a 200, even after 145 retry attempts over 72 minutes.
That many recursive calls ends up causing a call depth overflow exception with PowerShell. While this scenario should be an edge-case, nonetheless it seems better to remove the possibility of this error from occurring by modifying the retry logic to be a loop rather than a recursive call.
I've also added a new configuration value: `MaximumRetriesWhenResultNotReady` to help control and limit the number of retries that we'll attempt in this situation, ultimately throwing an exception if the retry limit is exceeded without a 200 response.
Finally, I've disabled the `When getting Github Repository Contributors with Statistics` test until the problem is fixed on the GitHub end. I've disabled the test by commenting the test out vs using the disable keyword to avoid the Pester failure for disabled tests, and I've opened a [support issue](https://github.community/t/unable-to-retrieve-contributor-statistics-for-a-brand-new-repo/136658) on this problem.
#257 did a fantastic job closing the gap on missing functionality in the module related to GitHub Teams.
This PR just adds onto that work by providing options that will reduce the need for additional queries during common operations.
* `Get-GitHubTeam`: **Breaking Change** Looking up a team by its `ID` has been deprecated per GitHub documentation. Removed that functionality and added the ability to look up by `slug` instead. This also means that you can now pipe in a team and get back the specific result without needing to filter through all org results.
* `Get-GitHubTeamMember`: Updated to use the `slug` instead of the team `ID`.
* `New-GitHubTeam`: Added ability to pass in the `ParentTeamId` (also via the pipeline) to avoid the need to query through all org teams.
* `Set-GitHubTeam`: Added ability to pass in the team `slug` (also via the pipeline) to avoid the need to query through all org teams. Similar to `New-GitHubTeam`, also added the ability to pass-in the `ParentTeamId` to avoid the full org team lookup.
* `Remove-GitHubTeam`: Added ability to pass in the team `slug` (also via the pipeline) to avoid the need to query through all org teams.
* Added `Rename-GitHubTeam` as a helper/wrapper on top of `Set-GitHubTeam`
* Added additional pipeline tests for existing functions
* Added new tests for `Rename-GitHubTeam` and `Get-GitHubTeamMember`
* Small update to formatters to simplify the display of the team parent
References: [GitHub Teams API](https://developer.github.com/v3/teams/)
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
* Updates `New-GitHubBranch` to be able to take a `GitHub.Branch` object as pipeline input (for the base branch)
* Updates `New-GitHubBranch` to be able to take in a `Sha` so that a branch can be created from an arbitrary commit (which also enables a new branch to be created from a `GitHub.Branch` pipeline input value without needing to perform an additional query on `BranchName` to get its `Sha`)
* Updates `GitHub.Branch` to have `Sha` as a top-level property.
* Updated existing tests and added additional tests.
Reference: [GitHub Refs API](https://developer.github.com/v3/git/refs/)
Fixes#261
Adds the following functions:
- `Add-GitHubTeam`
- `Update-GitHubTeam`
- `Remove-GitHubTeam`
It also adds the `TeamName` parameter to the `Get-GitHubTeam` function to allow getting team details by team name, which is used by the new functions.
Pester tests have also been added for the following functions:
- `Get-GitHubTeam`
- `Add-GitHubTeam`
- `Update-GitHubTeam`
- `Remove-GitHubTeam`
Positional Binding has been set as `false` for the three functions, and `Position` attributes added to the function's mandatory parameters.
Type view formats have been added for the `GitHub.TeamSummary` and `GitHub.Team` types.
API Reference: [GitHub Teams API](https://developer.github.com/v3/teams/)
Fixes the pipeline input for the following GitHub Repository functions:
- `Disable-GitHubRepositoryVulnerabilityAlert`
- `Enable-GitHubRepositorySecurityFix`
- `Disable-GitHubRepositorySecurityFix`
The unit tests for the functions are also updated to add pipeline tests.
Fixes#270
This PR fixes the `Describe 'GitHubRepositories\Enable-GitHubRepositorySecurityFix'` and `Describe 'GitHubRepositories\Disable-GitHubRepositorySecurityFix'` GitHubRepositories tests following on from the change to the GitHub Automated Security Fixes API.
Reference: [Enable Automated Security Fixes](https://docs.github.com/en/rest/reference/repos#enable-automated-security-fixes)
Fixes#269
This completes the required work to support the full set of API's around gists.
It adds the following functions:
* `Get-GitHubGist`
* `Remove-GitHubGist`
* `Copy-GitHubGist` (aka. `Fork-GitHubGist`)
* `Add-GitHubGistStar`
* `Remove-GitHubGistStar`
* `Set-GitHubGistStar` (just a wrapper around `Add/Remove-GitHubGistStar`
* `Test-GitHubGistStar`
* `New-GitHubGist`
* `Set-GitHubGist`
* `Rename-GitHubGistFile` (exposed helper function)
* `Remove-GitHubGistFile` (exposed helper function)
* `Set-GitHubGistFile` (exposed helper function, also known as `Add-GitHubGistFile`)
* `Get-GitHubGistComment`
* `Set-GitHubGistComment`
* `New-GitHubGistComment`
* `Remove-GitHubGistComment`
This also adds formatters for all newly introduced types: `GitHub.Gist`, `GitHub.GistCommit`, `GitHub.GistDetail`, and `GitHub.GistFork`.
Positional Binding has been set as `false`, and `Position` attributes added to the functions' mandatory parameters.
References:
[GitHub Gist](https://developer.github.com/v3/gists/)
[GitHub Gist Comments](https://developer.github.com/v3/gists/comments/)
Fixes#32
This completes the required work to support the set of Releases API's.
It adds the following functions:
* `New-GitHubRelease`
* `Set-GitHubRelease`
* `Remove-GitHubRelease`
* `Get-GitHubReleaseAsset`
* `New-GitHubReleaseAsset`
* `Set-GitHubReleaseAsset`
* `Remove-GitHubReleaseAsset`
`Invoke-GHRestMethod` has been updated to be able to upload a file (via the new `InFile` parameter) and download a file (via the `Save` switch which will cause it to return back a `FileInfo` object of a temporary file which can then be renamed as seen fit by the caller).
This also adds formatters for `GitHub.Release` and `GitHub.ReleaseAsset`.
Positional Binding has been set as `false` for the three functions, and `Position` attributes added to the function's mandatory parameters.
Reference: [GitHub Releases](https://developer.github.com/v3/repos/releases/)
Fixes#47Fixes#110
This is re-implementing #265 in a more robust way, thanks to a suggestion from @X-Guardian in #267.
Instead of adding in one-off sleeps throughout the test codebase, there is now a new configuration value `StateChangeDelaySeconds`) that will allow us to insert a delay before returning the result of _any_ state change request.
This should ideally consistently add reliability throughout the entire test codebase.
We're seeing some inconsistent failures in some of the Pester tests.
The hypothesis is that GitHub may need a little bit more time after the creation of objects before performing certain operations on them (like renaming repos), or may need more time after deleting them before it will successfully return a 404 on a successive Get request.
I have added a number of `Start-Sleep`'s throughout the test codebase wherever we've encountered inconsistent failures, and that appears to have resolved the problem. We may need to continue to do more of these if additional ones pop up.
The duration of the sleep itself is controlled by `$script:defaultSleepSecondsForReliability` which is defined in `Tests/Common.ps1`.
Long term, I have opened #267 which poses the idea of switching over to mocking out `Invoke-WebRequest` for the majority of the tests, and instead focus on validating the data that it's sending matches the expected values per the API documentation, and having just a limited number of tests that do actual end-to-end testing.
Fixes#264
Adds the following functions to the `GitHubBranches` module:
* `New-GitHubRepositoryBranch`
* `Remove-GitHubRepositoryBranch`
#### References
[GitHub Refs API](https://developer.github.com/v3/git/refs/)
* Reimagining status for the module
Status for commands was originally added to this module based on my experience with other REST API's where individual commands could easily take 10-20 seconds.
Practical usage has shown that most GitHub requests in reality take under one second. The additional work that PowerShell has to do in order to display progress to the user can easily make the overall command take 4-6 times longer than its actual execution time.
Therefore, status is being ripped out of this module (for the most part). `Invoke-GHRestMethod` and `Invoke-SendTelemetryEvent` no longer have bifurcating execution paths based on the value of `$NoStatus`. Everything runs synchronously now on the command prompt.
* `DefaultNoStatus` has been deprecated. Its value will be ignored.
* The `NoStatus` switch has not been removed from the module commands in order to avoid a breaking change. It may be removed in a future update.
* `Invoke-GHRestMethod -ExtendedResult` has been updated to include the next page's number and the total number of pages for the REST request.
* A new configuration value has been added: `MultiRequestProgressThreshold
`Invoke-GHRestMethodMultipleResult` will display a ProgressBar to the user tracking the number of remaining requests for the overall execution of the requested command based on this threshold value. It will only display the progress bar if the number of requets needed meets or exceeds this threshold value. This defaults to 10, and can be disabled with a value of 0.
Practical usage has shown that this adds less than a second of additional time to the overall execution of a multi-request command (quite different than the previous status).
* `Wait-JobWithAnimation` has been removed since it's no longer used.
Fixes#247
Added in #221, `New-GitHubRepositoryFromTemplate was not capturing the passed-in value for the RepositoryName if provided via a Uri parameter.
There was a pipeline test in place, however it missed this fact because it was only testing the pipeline input scenario using `-WhatIf`, and the error was only found when calling the actual REST API and GitHub noticed that the `RepositoryName` was missing from the URI.
Pull #251 changed the repo targeted by the forks tests from `microsoft/PowerShellForGitHub` to `octocat/Hello-World` in order to prevent the accidental deletion of real forks when running the UT's locally against your own account.
In practice, this almost doubled the execution time of the UT's, because the execution time of the Forks API's took so much longer against a repo with 1400+ forks.
Changing the test over to use a repo that currently only has 39 forks (several orders of magnitude fewer).
This attempts to rectify some improper verb usage in the module based on the explanations of intended verb usage from [previous PowerShell documentation](https://web.archive.org/web/20171222220053/https://msdn.microsoft.com/en-us/library/windows/desktop/ms714428(v=vs.85).aspx).
* We're standardizing on the following pattern for most object actions:
`Get` / `Set` / `New` / `Remove`
* We will continue to alias `Remove-*` as `Delete-*`.
* When possible, this change attempts to avoid breaking changes by re-aliasing the newly named functions with their previous names. This was not possible in one instance, hence this is still a breaking change (although based on telemetry, it should be minimally impacting).
Result:
* `Update-GitHubCurrentUser` -> `Set-GitHubProfile` `[Alias('Update-GitHubCurrentUser')]`
* `Update-GitHubIssue` -> `Set-GitHubIssue` `[Alias('Update-GitHubIssue')]`
* `Update-GitHubRepository` -> `Set-GitHubRepository` `[Alias('Update-GitHubRepository')]`
* `New-GitHubAssignee` -> `Add-GitHubAssignee` `[Alias('New-GitHubAssignee')]`
* [breaking] `Update-GitHubLabel` -> `Set-GitHubLabel` `[Alias('Update-GitHubLabel')]`
* [breaking] `Set-GitHubLabel` -> `Initialize-GitHubLabel` `<no alias due to above>`
Changing an existing label has much more regular usage than replacing all of the labels in a repository, hence allowing the _new_ `Set-GitHubLabel` to keep the alias of `Update-GitHubLabel`.
Our usage of the `Set-*` verb in general is a bit arguable based on the documentation ... in theory `Edit-*` might be a better fit since we're _editing_ aspects of an object as opposed to _replacing_ the entire content of an object. However, I think `Set-*` _feels_ ok in this module. We're _setting_ the state of these objects. Again...arguable, but this is a much smaller breaking change to get to a consistent terminology state.
Updates the Pester tests for the `GitHubRepositories` module to increase the code coverage.
This also:
* Refactors `Get-GithubRepository` to remove a code path that could never be taken
* Adds a `ValidateSet` to the `Affiliation` parameter of the `Get-GitHubRepository` function
* Fixes the Comment Based Help descriptions for the `Get-GitHubRepositoryCollaborator` and `Move-GitHubRepositoryOwnership`
* Adds formatting for all of the types exposed in GitHubRepositories.ps1.
* Fixes the `OutputType` for RepositoryCollaborator and RepositoryContributor.
This adds the following functions to the `GitHubRepositories` module to manage the GitHub Dependabot services.
- `Test-GitHubRepositoryVulnerabilityAlert`
- `Enable-GitHubRepositoryVulnerabilityAlert`
- `Disable-GitHubRepositoryVulnerabilityAlert`
- `Enable-GitHubRepositorySecurityFix`
- `Disable-GitHubRepositorySecurityFix`
There is no `Test-GitHubRepositorySecurityFix` function is there is currently no API for this.
[GitHub Repositories Rest API v3](https://developer.github.com/v3/repos/)
There are only four legitimate instances in the module as of today where we should be disabling the validation that Resolve-RepositoryElements provides. All other instances were likely introduced due to mistaken copy/paste issues.
The only reason we'd want to disable the validation is if there are multiple parametersets that need to be considered for the function, where at least one _would_ require `OwnerName`/`RepositoryName` while at least one other one _would not_.
This would have meant that we would have attempted to call those GitHub endpoints with incomplete path information which would have most likely resulted in an error that we could have caught sooner without needing to invoke a web request.
I've fixed up all of these incorrect instances, and added a comment to the two remaining ones to remind others later on why that switch is being used, and help prevent incorrect usage in the future.
I've also cleaned up unnecessary passing of `BoundParameters` since it already does the correct thing by default.
# 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/)
The call to `ConvertTo-SmarterObject` was adding a significant amount of time to the execution of Get-GitHubContent.
```powershell
Set-GitHubConfiguration -DisableSmarterObjects:$false
Measure-Command { $c = Get-GitHubContent -OwnerName microsoft -RepositoryName PowerShellForGitHub -Path README.md }
# This averages to be around 1.2 seconds
Set-GitHubConfiguration -DisableSmarterObjects:$true
Measure-Command { $c = Get-GitHubContent -OwnerName microsoft -RepositoryName PowerShellForGitHub -Path README.md }
# This averages to be around 14 seconds
```
The reasoning behind this was that the return of `Invoke-WebRequest` for this repo's `README.md` was an array of [int32] that contained 22,000+ entries (one byte per entry). Because the array was created by `ConverFrom-Json`, each `[int32]` was also an `[object]`, which meant that it was considered a `[PSCustomObject]` inside of `ConverTo-SmarterObject`, which caused it to do a lot of unnecessary work. Piping in 22,000 objects and doing all of that unnecessary work to end up just calling `Write-Output` on the original value took a _lot_ of time.
The fix here was to skip trying to convert the result to a smarter object if it wasn't going to be a convertible object in the first place.
I also added in protection directly to `ConverTo-SmarterObject` as well. It made things better than the current runtime, but still twice as slow as not calling it in the first place (average runtime of above command was 3.5 seconds when we allowed it to go into the command and then do nothing).
This doesn't end up saving much time with the execution of `Tests/GitHubContents.tests.ps1` because the file being returned is so small, but this should have some nice user experience improvements in practical usage.
In a previous commit (b4439f4a6b), the three platforms in the CI pipeline (Windows, Linux, and Mac) were modified to execute serially since they were all operating against the same shared test account, which caused the Pester tests to operate unstabily.
I've now created multiple test accounts so that that each platform can operate in isolation of each other. I've updated the UT template to accept parameter input, and modified the CI (and release) pipeline to reference a different AccessToken/OwnerName/OrganizationName based on which platform is being targeted.
Additionally:
* Had to fix some tests to keep everything passing as well;
* Two Contents tests started failing again because GitHub once again changed the HTML output for the standard generated README.md file. This time around, I've attempted to make the tests more robust to future changes.
* Two RepositoryForks tests were unreliable in the way that they were written, so they were updated as well to be more robust when being executed in a parallel UT environment (since we can't control when a fork for this repository is being created/removed).
* Updates the pipelines to always use the most recent OS images.
* Fixes some invalid links on some of the Azure DevOps badges in the README
This PR adds the following parameters to the `New-GitHubRepository` and `Update-GitHubRepository` functions:
- DeleteBranchOnMerge
- IsTemplate
It also adds substantial UT's to verify these changes.
Fixes#189
Updates all Remove-* functions to set `ConfirmImpact='High'`, wraps the execution in `$PSCmdlet.ShouldProcess()`, and adds examples which show how to call the functions with `-Confirm:$false` to avoid the confirmation prompt.
## Breaking Change
This will be considered a breaking change for anyone using this module in an automated, scripted basis and calling any Remove-* methods. They will need to add `-Confirm:$false` to those API calls, similar to what was done for the unit tests.
Fixes#171
Jason Vercellone
Howard Wolosky
Simon Heather
Neil White
Mark
Tyler James Leonhardt
Giuseppe Campanelli