Replace `BinaryFormatter` with `PSSerializer`
Since the former has been removed from PowerShell 7.4 (because it was removed from .NET 7) and the latter can accomplish the same thing.
The default depth is 1, so we need to specify. Best I could find was that the prior implementation defaulted to a depth of 64, so we're going with that.
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.
When retrieving the permissions granted to a team for a repository, the API returns an array of booleans indicating what individual permissions the team currently has.
| name | permissions granted |
| ---- | ------------------ |
| pull | pull |
| triage | pull, triage |
| push | pull, triage, push |
| maintain | pull, triage, push, maintain |
| admin | pull, triage, push, maintain, admin |
As you can see, each permissions builds on top of the previous permission. When adding extra properties to this returned object via `Add-GitHubRepositoryTeamPermissionAdditionalProperties`, we also add a new `permission` property that attempts to represent the collection of permissions with their current top-permission level.
The logic however incorrectly favored `push` over `maintain` and thus would always said that a Team had `push` permission when in fact it may have actually had `maintain` permission.
This simple change corrects that ordering mistake.
The Get/Set/Remove-GitHubRepositoryTeamPermission functions will sometimes call Get-GitHubTeam to get missing information. In those instances, they weren't passing along the `AccessToken` parameter if it had been provided by the user. In those scenarios, the result will be a 404 since the Get-GitHubTeam call won't have the same auth permissions as the core API being called.
Doing some clarifying wording in the friendly error message that we add to a 404 to indicate that they could be getting the error because the item truly doesn't exist, not simply due to authentication issues.
**TL;DR;** Requesting to add [FabricBot](https://eng.ms/docs/products/1es-data-insights/merlinbot/extensions/fabricbot_overview) configuration associated with your repository to `.github/fabricbot.json`.
**Context**
FabricBot is now a [config-as-code-only](https://eng.ms/docs/products/1es-data-insights/merlinbot/extensions/bot-config-as-code) platform. As a result, while you can still use the [FabricBot Configuration Portal](https://portal.fabricbot.ms/bot/?repo=microsoft/PowerShellForGitHub) to modify your FabricBot configuration, you can no longer save the changes. The only way to save changes to your configuration at the moment is to _export configuration_ from the portal and upload the exported configuration to `.github/fabricbot.json` in your repository. In this pull request, we are adding your FabricBot configuration to your repository at `.github/fabricbot.json` so that you can make changes to it going forward.
While the [FabricBot Configuration Portal](https://portal.fabricbot.ms/bot/?repo=microsoft/PowerShellForGitHub) is the *only way* to modify your FabricBot configuration at the moment, we have a feature on our backlog to publish the JSON schema defining the structure of the FabricBot configuration file. With the JSON schema, you can (1) use a plaintext editor of your choice to modify the FabricBot configuration file and use the schema to validate the file after editing or (2) [configure](https://code.visualstudio.com/Docs/languages/json#_json-schemas-and-settings) VS Code to use the schema when editing FabricBot configuration file to take advantage of convenience features such as automatic code completion and field description on mouseover.
Co-authored-by: msftbot[bot] <48340428+msftbot[bot]@users.noreply.github.com>
Co-authored-by: Howard Wolosky <HowardWolosky@users.noreply.github.com>
The telemetry code was creating a singleton base telemetry event the first time that telemetry was being sent. That base event included the date. If a PowerShell session lasted multiple days, the telemetry reporting would eventually start to fail because the date being reported for the event was too old.
We now just create a new telemetry event every time one is requested (this also ensures that it honors changes to the ApplicationInsightsKey), and now we only cache a GUID that we use to represent the "session" ID which we consider to be the duration of the current PowerShell session.
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.
When experimenting with the the notifications API, it was necessary to be able to specify an additional header (If-Modified-Since).
Making this support generic by allowing callers to specify any number of additional headers to be included with the REST request.
Fixed some issues with `Build-Wiki`:
* Ensured that `Home.md` is not incorrectly categorized as deprecated.
* Fixed how we check for `platyPS` being installed.
* Fixed how we reference files in `Move-Item` to solve the issue when the file being moved is new.
* Added warning/reminder to run this under `PS7+` to avoid issue with how multi-line examples get formatted.
Also added Wiki updating instructions to the release section of `CONTRIBUTING.md`.
`Get-GitHubEvent` is currently broken if the issue contains and event that includes the "label" or "labels" property. This is because `Add-GitHubEventAdditionalProperties` treats the labels in the event object as full fledged label objects that normally contain a URL property and other additional pieces of data. The label property in a `GitHub.Event` is a lighter-weight object that simply contains the string for the label and color that was changed, it is not the full object that you would typically receive from a call like `Get-GithubLabel`.
Updated to add a new `GitHub.LabelSummary` type to describe this scenario, as well as passing in the needed `RepositoryUrl` when adding the additional label properties.
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.
The Build-* verb is new to PowerShell Core and so was considered
unapproved for Windows PowerShell. Given that these are internal
helper methods and it _is_ an approved verb in PS Core, keeping as-is
and just marking these warning instances to be suppressed.
This adds a new script utility, `Build-Wiki.ps1`, which can be used to auto-generate the documentation for the Wiki. This uses the [PlatyPS](https://github.com/PowerShell/PlatyPS) module to generate the actual help documentation.
Relevant notes:
* This will generate the `Home.md`, `_sidebar.md`, and `_footer.md` files for the Wiki if they don't already exist in the destination directory.
* If they do already exist, it intelligently updates the content, only replacing the parts that it generated itself (denoted with
comments in the markdown content itself).
* At present, this is not being hooked-up to CI because I don't want to deal with storing credentials that have admin access
to the actual repo.
Tip of the hat to @X-Guardian for the suggestion and the initial help with writing this out.
Resolves#208
In Azure Function Apps, the special `MyDocuments` folder resolves to an empty string, which means that the default `logPath` gets stored as an empty string.
3094c9789c/GitHubConfiguration.ps1 (L650-L657)3094c9789c/GitHubConfiguration.ps1 (L671)
This causes problems when `Write-Log` is called by any other function, because we directly assign the current configuration value for `LogPath` as the parameter's default, which throws an exception when an empty string is assigned.
3094c9789c/Helpers.ps1 (L142)
In this scenario, we'll fall back to using the `LocalApplicationDataFolder` folder and writing a verbose message to the user letting them know this has happened. I've opted for a verbose message as opposed to a warning to avoid a constant annoying warning for users. The alternate path is documented in the updated USAGE.md, and it's also retrievable by calling `Get-GitHubConfiguration -Name LogPath`.
Documentation has also been updated to reflect this behavior change.
Fixes#282
Updated the summary of the current API support in the README to account
for the recent `0.15.0` changes. Also added a direct link to the
CHANGELOG as well.
Howard Wolosky
Andy Jordan
Jason Vercellone
microsoft-github-policy-service[bot]
Simon Heather
Neil White
Mark
Neil White
msftbot[bot]
laustta
Matt Gucci
jing8956
Pepe Rivera
Jonathan Moss
Ted Hudek
John
Jack Samuel S