Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reimagining status for the module #253

Merged
merged 3 commits into from
Jun 30, 2020

Conversation

HowardWolosky
Copy link
Member

@HowardWolosky HowardWolosky commented Jun 29, 2020

Description

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.

Issues Fixed

Fixes #247

References

Pagination for GitHub API v3 REST API
List Users API which doesn't follow normal pagination guidelines (it uses since instead of page and has no last link.

Checklist

  • You actually ran the code that you just wrote, especially if you did just "one last quick change".
  • Comment-based help added/updated, including examples.
  • Static analysis is reporting back clean.
  • New/changed code adheres to our coding guidelines.
  • New/changed code continues to support the pipeline.
  • Changes to the manifest file follow the manifest guidance.
  • Unit tests were added/updated and are all passing. See testing guidelines. This includes making sure that all pipeline input variations have been covered.
  • Relevant usage examples have been added/updated in USAGE.md.
  • If desired, ensure your name is added to our Contributors list

@HowardWolosky HowardWolosky added the enhancement An issue or pull request introducing new functionality to the project. label Jun 29, 2020
@HowardWolosky
Copy link
Member Author

@X-Guardian - you've been quite vocal regarding your feelings of how status is handled in the module. I'd be interested in your thoughts on this change.

@X-Guardian
Copy link
Contributor

Sounds great @HowardWolosky. This remove all the complexity of Status, which was ending up radically slowing all requests down if it was enabled.
Using the built-in Write-Progress is a much better solution and keeps with standard PowerShell functionality and only triggering it when it is known that there will be multiple API requests avoids the 'flickering' progress bar for end-users.

@HowardWolosky
Copy link
Member Author

/azp run PowerShellForGitHub-CI

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@HowardWolosky
Copy link
Member Author

/azp run PowerShellForGitHub-CI

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@HowardWolosky
Copy link
Member Author

/azp run PowerShellForGitHub-CI

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

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 microsoft#247
@HowardWolosky
Copy link
Member Author

/azp run PowerShellForGitHub-CI

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@HowardWolosky HowardWolosky merged commit 2740026 into microsoft:master Jun 30, 2020
@HowardWolosky HowardWolosky deleted the newStatus branch June 30, 2020 22:05
HowardWolosky added a commit to HowardWolosky/PowerShellForGitHub that referenced this pull request Aug 11, 2020
The `NoStatus` parameter (and `DefaultNoStatus` config value) were
deprecated as part of microsoft#253 when we stopped showing status except for
multi-page requests that exceeded some minimum number of pages.

At that time, `NoStatus` (and `DefaultNoStatus`) were not removed in
order to minimize the churn to the module.  However, keeping it in
is adding unnecessary complexity to the module as we continue to
expand what the module can do.

This change removes `NoStatu` (and `DefaultNoStatus`) from the module
entirely.  The only impact that this may cause is with users who are
currently using one (or both) of them.  This breaking change impact
should be minimal, but its best for the breaking change to be part of
the coming release which already has a number of other breaking changes
as well, as opposed to having more breaking changes in a successive
release.
HowardWolosky added a commit to HowardWolosky/PowerShellForGitHub that referenced this pull request Aug 11, 2020
The `NoStatus` parameter (and `DefaultNoStatus` config value) were
deprecated as part of microsoft#253 when we stopped showing status except for
multi-page requests that exceeded some minimum number of pages.

At that time, `NoStatus` (and `DefaultNoStatus`) were not removed in
order to minimize the churn to the module.  However, keeping it in
is adding unnecessary complexity to the module as we continue to
expand what the module can do.

This change removes `NoStatu` (and `DefaultNoStatus`) from the module
entirely.  The only impact that this may cause is with users who are
currently using one (or both) of them.  This breaking change impact
should be minimal, but its best for the breaking change to be part of
the coming release which already has a number of other breaking changes
as well, as opposed to having more breaking changes in a successive
release.
HowardWolosky added a commit to HowardWolosky/PowerShellForGitHub that referenced this pull request Aug 11, 2020
The `NoStatus` parameter (and `DefaultNoStatus` config value) were
deprecated as part of microsoft#253 when we stopped showing status except for
multi-page requests that exceeded some minimum number of pages.

At that time, `NoStatus` (and `DefaultNoStatus`) were not removed in
order to minimize the churn to the module.  However, keeping it in
is adding unnecessary complexity to the module as we continue to
expand what the module can do.

This change removes `NoStatu` (and `DefaultNoStatus`) from the module
entirely.  The only impact that this may cause is with users who are
currently using one (or both) of them.  This breaking change impact
should be minimal, but its best for the breaking change to be part of
the coming release which already has a number of other breaking changes
as well, as opposed to having more breaking changes in a successive
release.
HowardWolosky added a commit that referenced this pull request Aug 12, 2020
The `NoStatus` parameter (and `DefaultNoStatus` config value) were deprecated as part of #253 when we stopped showing status except for multi-page requests that exceeded some minimum number of pages.

At that time, `NoStatus` (and `DefaultNoStatus`) were not removed in order to minimize the churn to the module.  However, keeping it in is adding unnecessary complexity to the module as we continue to expand what the module can do.

This change removes `NoStatus` (and `DefaultNoStatus`) from the module entirely.  The only impact that this may cause is with users who are currently using one (or both) of them.  This breaking change impact should be minimal, but its best for the breaking change to be part of the coming release which already has a number of other breaking changes as well, as opposed to having more breaking changes in a successive release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An issue or pull request introducing new functionality to the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Revisit how status is displayed to the user
2 participants