Category Archives: Powershell

PowerShell for Visual Studio Code Updates – February 2021

This post was originally published on this site

 

We are excited to announce that updates to our PowerShell extension and PowerShell Preview extension are now available on the Visual Studio Code marketplace. This blog will explain what is new in these releases as well as what you can expect from the extension in the coming months.

What’s new in the PowerShell Extension release

This incremental release incorporates changes from four preview releases! Some highlights of the release include:

For the full list of updates please refer to the changelog. Further goals of this release are well discussed on GitHub.

What’s new in PowerShell Preview release

This preview release contains updates to our build infrastructure, bug fixes, and updates to our language server client. For the full list of updates please refer to the changelog.

This release contains a breaking change which removes PowerShell notebook mode. This feature, which was only available on Visual Studio Code insiders in the PowerShell preview extension, was removed due to changes to the preview notebook APIs breaking the functionality of the feature. We have chosen to prioritizes fixes which we believe will improve the stability and reliability of the extension overall in the short term and hope to re-invest in PowerShell extension integration with the Visual Studio code notebook APIs once they stabilize.

A PowerShell notebook experience in Visual Studio Code insiders is still available through the .NET Interactive Notebooks extension.

What’s been happening since the last release

This is our first stable release of the PowerShell extension since June 2020. The time between these releases was longer than we anticipated and would have liked. We recognize that in the time since users have had to deal with longstanding bugs and performance deficiencies. This gap in releases reflects competing priorities across the PowerShell engineering team but does not reflect a shift in investment or commitment to Visual Studio Code as the premier free development environment for PowerShell.

In January 2021 we were also excited to welcome Andy to the PowerShell extension development team. With their support we plan to increase the cadence of improvements for the extension in the coming months.

What’s next for the extensions

Over the coming months we plan to improve the extension with the following areas of focus:

We are also currently investigating new feature areas for the extension like Predictive IntelliSense integrations for the editor, GitHub Codespaces, and notebook integrations. You can track the progress on all of these projects in our GitHub repository.

Getting support and giving feedback

If you encounter any issues with the PowerShell extension in Visual Studio Code or have feature requests, the best place to get support is through our GitHub repository.

Sydney Smith, PowerShell Team

 

The post PowerShell for Visual Studio Code Updates – February 2021 appeared first on PowerShell Team.

Announcing PowerShell Community Blog

This post was originally published on this site

Announcing PowerShell Community Blog

We want to share the exciting news about the new
PowerShell Community Blog. Since the retirement of the Scripting
Guy (Ed Wilson) the Scripting blog has had fewer new posts. With the rapid ongoing growth of
PowerShell, this means fewer community members finding the help and answers they need to be
successful.

Community members, along with some partner teams within Microsoft, have taken up the challenge to
refresh and revitalize the blog. Now focused exclusively on PowerShell and with new
features/technology driven by the community.

We are happy to help get the word out and announce the new
PowerShell Community Blog. Focused on PowerShell with new and
relevant content from the community.

Wait! If you’re wondering about all that valuable content on the
original Scripting blog, don’t worry! All the work
from the original blog will remain intact and available to you. In fact, some of the
older-but-popular content will get updated and posted on the new community blog.

Visit the new blog, and
while you’re there, share your problems and knowledge with the community and help everyone automate
solutions with PowerShell.

Jason Helmick

PowerShell Team

The post Announcing PowerShell Community Blog appeared first on PowerShell Team.

SecretManagement and SecretStore Release Candidates

This post was originally published on this site

The SecretManagement and SecretStore release candidate (RC) modules are now available on the PowerShell Gallery.

The SecretManagement module helps users manage secrets by providing a common set of cmdlets to interface with secrets across vaults. This module supports an extensible model where local and remote vaults can be registered and unregistered for use in accessing and retrieving secrets. SecretStore is a cross-platform local extension vault for use with SecretManagement. We designed this vault as a best attempt at creating a vault that is available where PowerShell is, usable in popular PowerShell scenarios (like automation and remoting) and utilizes common security practices.

For more information on these modules check out these previous blog posts:

Before installing these modules, please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
# Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement Updates

  • Register-SecretVault no longer emits error when strict language mode is set
  • Set-DefaultVault cmdlet has been renamed to Set-SecretVaultDefault

General Availability (GA)

This is a “go live” release, which means that we feel that this RC is feature complete and of GA quality. If no bugs are identified through this release, we will increment the versioning and declare the modules as GA in early February. If any high-risk bugs are identified we will continue to release RCs until the quality bar is met for a GA release.

The Extension Vault Ecosystem

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and Support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith

PowerShell Team

 

The post SecretManagement and SecretStore Release Candidates appeared first on PowerShell.

PowerShell 7.2 Preview 2 release

This post was originally published on this site

PowerShell 7.2 Preview 2

Today we are proud to announce the second preview release of PowerShell 7.2.
This preview is still based on .NET 5 as we wait for the first preview of .NET 6 which we expect PowerShell 7.2 to be based upon.

This preview includes many changes including code cleanup, bug fixes, and a few new features.

Code cleanup

The community has made significant contributions to code cleanup
which is a focus early in a new release.
Approximately two thirds of the 120 pull requets were for code cleanup!

Thanks to all the community members involved in submitting pull requests and reviewing them!

Notable bug fixes

Although we appreciate all bug fixes from the community, there are a few I believe have a broader impact and worth mentioning.

Correct handling of Windows invalid reparse points

On Windows, reparse points are a collection of user-defined data that define specific filesystem behaviors.
For example, symbolic links, OneDrive files, and Microsoft installed applications use reparse points.
Due to a bug introduced in PowerShell 7.1, if you try to use an executable on a drive that isn’t NTFS, you’ll get an Incorrect Function error.
This can be a local USB drive or a network share, for example.

Thanks to our community maintainer Ilya Sazonov for the fix.

We expect to backport this fix to PowerShell 7.1 for the next servicing release.

Breaking changes

-PipelineVariable common parameter

The -PipelineVariaable common parameter
now correctly contains all the objects passed in from the pipeline making script cmdlets work the same as C# cmdlets instead of just the first input object.

You can see an example of the change in behavior in the original issue.

Thanks to Joel Sallow for the fix.

New features

$PSStyle automatic variable for ANSI rendering

When working in the console with a modern terminal, color and text effects can help
make text information more interesting and useful.

This experimental feature called PSAnsiRendering exposes a new $PSStyle automatic variable that can be used for two different purposes.

The first is to make it easier to author text content that contains ANSI escape codes which control
text decorations like color, bold, italics, etc…

This example simply dumps the contents of $PSStyle and shows you the members you can use and their effect on text as well as the actual ANSI escape sequence.
Note that the custom formatting for this variable includes nested types like Formatting, Foreground, and Background.

$PSStyle variable

You can use multiple ANSI escape sequences together.
In this example, I’ve set warning messages to have bold and italicized yellow text on a magenta background:

Warning message style customization

There are also FromRgb() methods available to make use of full 24-bit color if your terminal supports it:

24-bit color text

C# module authors can also leverage $PSStyle by using the PSStyle singleton class in the System.Management.Automation namespace:

string text = $"{PSStyle.Instance.Reverse}{PSStyle.Instance.Foreground.Green}PowerShell{PSStyle.Instance.Foreground.Yellow} Rocks!{PSStyle.Instance.Reset}";

You can control how PowerShell outputs strings that contain ANSI escape sequences by setting $PSStyle.OutputRendering:

  • Automatic
    This is the default and currently will output the text as-is whether it is to the host or through the pipeline if the
    terminal supports ANSI escape sequences (otherwise the output will be plaintext). This is similar behavior to what you
    would get on Linux.
  • Ansi
    This value will output the text as-is whether it is to the host or through the pipeline.
  • PlainText
    This value will remove ANSI escape sequences from any text output whether it is to the host or through the pipeline.
  • Host
    This value will output the text as-is if sent to the host if ANSI escape sequences are supported, but will output plaintext
    if the output is sent through the pipeline or redirected. This is similar behavior to what you would get on macOS.

As this is an experimental feature, we encourage feedback on this before we make a decision to take it out of experimental.
See the original issue for additional details, but open new issues if you have any problems or
suggestions on how to improve this feature.

We very much appreciate on going feedback on our preview releases so we can make adjustments before the release is finalized.
Please participate in on going discussions or create new issues in our repo.

Thanks again to the PowerShell community and all the amazing contributors!

Steve Lee
Pricipal Software Engineer Manager
PowerShell Team

The post PowerShell 7.2 Preview 2 release appeared first on PowerShell.

Incident Report – PowerShell Gallery Downtime October 30, 2020

This post was originally published on this site

 

The PowerShell gallery experienced downtime on October 30th 2020. This report will give context as to what caused the downtime, what actions were taken to mitigate the issue, and what steps we are taking to improve the PowerShell gallery experience moving forward.

Downtime Impact

The downtime was declared at 2020-10-30 03:29 PDT, and was mitigated about 12 hours later at 2020-10-30 15:39 PDT. During this time packages were not available from the gallery, and the web interface was not accessible.

Root Cause of the Downtime

The downtime was a result of an attempt to fix ongoing statistics errors with the gallery. For roughly 3 weeks the PowerShell gallery was experiencing many server errors (roughly 100-200 per minute) due to a key that had reached a max int value (total downloads reached over 2 billion) and was causing persistent int overflow errors on the gallery. This prevented new entries from being added to the ‘PackageStatistics’ table (required for the intermediary processing of statistics). The int overflow first occurred on 9/18/2020.

After an attempt to perform database migrations failed due to the persistent errors manual updates were made to the database to fix inflated package statistics numbers.
These changes triggered a series of deadlock and timeout errors which consumed all our available cloud resources.
This caused a spike in DTU/CPU utilization for the database which inversely correlated with the availability for the service. The availability for the gallery was so low that it was non-functional and declared down.

Mitigating the Downtime

The first mitigation step was to restore the gallery database (DB) to a previous timestamp. It was believed that an error in the attempted fix of gallery statistics caused the DB to get into a bad state and thus restoring the DB reverted those changes. This initial error was likely due to a trigger on the database that we did not account for. Unfortunately, reverting the DB caused additional issues. Checking the PowerShell gallery backend logs, we saw that the service had trouble connecting to the DB with an error that user credentials were wrong. This indicated that the user had been orphaned by the restore so we re-created the user in the DB. After this step, checking the PowerShell gallery backend logs again, the service had additional trouble connecting to the DB with an error that login was failing. We determined that this error was caused by the DB restore dropping the DB from the gallery’s failover group. The next mitigation step was to re-add the DB to the gallery’s failover group. The final mitigation step was to restart the cloud services so they could re-connect to the failover group. At this point the gallery started working again. We validated these fixes with customers, as well as with our own testing and continued to closely monitor the DTU/CPU utilization and service availability.

Statistics Errors

The gallery has had ongoing issues with the package statistics since August 2020.

These errors came from the gallery reaching a scale (more than 2 billion installations) that was not supported by the design of the statistics pipeline. The impact of this has been both incorrect and unavailable package statistics. The package statistics from 2020-09-18 through 2020-10-07 were never recorded, which meant we were unable to recover statistics from this period.

Restoring Statistics

We restored statistics in two ways, first we repaired statistics for individual packages (surfaced on a package’s page), and then we repaired aggregated statistics (surfaced on the gallery homepage and statistics page).

In ordered to repair package statistics we updated values in our main database and within the code base itself, that referenced a key for package statistics from an integer to a bigint/long. There was some pending data that was dropped when the int overflow error first appeared. We retrieved specific ‘lost’ data from a restored database, but were unfortunately unable to recover some data (mentioned in Statistics Errors).

To repair the aggregated statistics, we then made parallel changes to our data warehouse.

Our repair items are focused on 3 categories: detect, diagnose, and fix. By focusing on these three areas, we hope to not only improve the overall performance of the gallery but also, more quickly find and mitigate issues as they arise.

  • Detect:
    • Add more notifications to the production database
    • Create alerts for when critical metrics are reached in the DB
    • Improve post-deployment validation so that we can quickly roll back undesirable changes
  • Diagnose:
    • Send database logs to a central location outside of the service so that logs are more easily available
  • Fix:
    • Improve the deployment process for gallery cloud services
    • Better document (internal) procedures for recovery and communication during an outage

 

We are also in the process of designing architectural changes to the PowerShell gallery, to ensure this is a reliable, performant, and supportable service moving forward.

Expectations going forward

In conjunction with these repairs, we are working to set and monitor Service Level Objectives (SLOs). Look forward to a future post detailing these expectations and how gallery users can track our progress against these objectives.

Reporting Issues

If you notice any issues with the PowerShell gallery please open an issue in our GitHub repository.

If you are a package owner and have an issue with your package please use our support alias: cgadmin@microsoft.com.

We continue to update the status of the PowerShell gallery at: aka.ms/PSGalleryStatus.

Sydney

PowerShell Team

 

The post Incident Report – PowerShell Gallery Downtime October 30, 2020 appeared first on PowerShell.

SecretManagement preview 6 and SecretStore preview 4

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

For more information on these modules check out these previous blog posts:

Before installing these modules, please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
# Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -AllowPrerelease -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -AllowPrerelease -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement preview 6 updates

This update to SecretManagement improves the compatibility of the module with Windows PowerShell, and improved the usability of the module by providing more ways to unregister vaults and by setting the first registered vault as default as well a few other changes. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell 5.1 (Issue #73)
  • The first extension vault added will automatically be designated the default vault (Issue #61)
  • Unregister-SecretVault -Name property now supports string[] type and wild cards (Issue #57#58)
  • Register-SecretVault now checks -VaultParameters hashtable for reserved Verbose entry and throws error if found
  • Set-DefaultVault now has a -ClearDefault parameter that designates no registered vault as the default vault
  • Register-SecretVault now supports a -Description parameter and registration information will include an optional extension vault description (Issue #46)

SecretStore preview 4 updates

This update to SecretStore focuses on updates which improve the compatibility with Windows PowerShell. Read the full list of changes below:

  • Improved compatibility with Windows PowerShell when creating new store files (Issue #28)
  • SecretStore binary is now built against net461 to provide full compatibility when run in PowerShell 6 or Windows PowerShell
  • System.IO.FileSystem.AccessControl.dll is now shipped with module to maintain compatibility with Windows PowerShell

Finding other available extension Vaults

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! As we approach General Availability, targeted for later this year, for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith

PowerShell Team

The post SecretManagement preview 6 and SecretStore preview 4 appeared first on PowerShell.

Announcing PowerShell 7.1

This post was originally published on this site

We’re proud to announce the release of PowerShell 7.1, the latest major update to PowerShell 7. This release includes a number of improvements and fixes that build on top of the PowerShell 7.0 release in March and the recent GA release of .NET 5. Since then, the PowerShell Team (and many of you, our community contributors, thank you!) have been hard at work addressing some of the community’s top bug reports and feature requests.

What’s new in PowerShell 7.1?

For PowerShell 7.1, we decided to build on the foundation established in PowerShell 7.0 with a strong focus on community issues, especially where we could make additive changes and quality-of-life improvements without introducing instability or breaking changes. As a platform with over 115 million sessions per month, we’re absolutely committed to ensuring that PowerShell remains a stable and performant platform, even after significant version upgrades like 7.1.

For more details about what’s been added and fixed, make sure to check out the PowerShell 7.1 release notes.

Where can I get the latest version?

Our latest releases can always be found within the GitHub Releases for PowerShell.

For the first time, on Windows 10, you can also now pick up the latest version of PowerShell on the Microsoft Store.

More information on how to install across various platforms and architectures can be found at https://aka.ms/Install-PowerShell.

Why should I upgrade to PowerShell 7?

PowerShell 7 is the modern, cross-platform edition of PowerShell
built on top of .NET 5+ (formerly .NET Core). PowerShell 7 offers cross-platform support on Linux, macOS, and Windows, SSH-based remoting, parallelization, Docker containers, new operators and language features, and a massive long tail of small improvements and bug fixes.

If you’re still primarily a Windows PowerShell user, and you’re interested to learn more about the benefits and mechanics of moving to PowerShell 7, check out this doc on upgrading from Windows PowerShell to PowerShell 7.

What operating systems and distributions does PowerShell 7.1 support?

PowerShell 7.1 supports a wide variety of operating systems and platforms including:

  • Windows 8.1/10 (including ARM64)
  • Windows Server 2012 R2, 2016, 2019, and Semi-Annual Channel (SAC)
  • Ubuntu 16.04/18.04/20.04 (including ARM64)
  • Ubuntu 19.10 (via Snap package)
  • Debian 9/10
  • CentOS and RHEL 7/8
  • Fedora 30
  • Alpine 3.11+ (including ARM64)
  • macOS 10.13+

We also have community support for:

  • Arc Linux
  • Raspbian Linux
  • Kali Linux

Support lifecycle

PowerShell 7.1 is supported under the Microsoft Modern Lifecycle Policy for the same support timeline as .NET 5: currently 3 months after the release of .NET 6 in roughly one year.

This is in contrast to the PowerShell 7.0, an LTS release that will be supported until December of 2022.

For more information on the PowerShell 7 support lifecycle and requirements, check out https://aka.ms/PSLifecycle.

What else has the PowerShell Team been working on?

Over the last 6-12 months, you may have noticed that some of the more interesting new PowerShell Team functionality is being developed outside of the PowerShell repository within the PowerShell GitHub organization. In upholding our commitment to stability within the PowerShell language runtime, we’re doing as much of our fresh and experimental outside of the primary PowerShell project. Most of this work will live on the PowerShell Gallery, but some may eventually find its way back into the PowerShell project once the PowerShell Team is confident that it’s stable enough to reach the high stability bar that PowerShell 7 necessitates.

Some of these other projects and repositories include

Keep your eyes peeled on the PowerShell Team blog and @PowerShell_Team account on Twitter for more updates, previews, and developments on these efforts.

How can I give feedback

Please file issues in the PowerShell repository on GitHub to let us know about any features you’d like added or bugs that you encounter. Additionally, you can join us for the PowerShell Community Call on the 3rd Thursday of every month. The Community Call is a great opportunity to talk directly to the team, hear about the latest developments in PowerShell, and to voice your opinions into ongoing feature design.

And as always, we accept code, test, and documentation contributions in the form of pull requests on GitHub. If you’re interested in helping out on the project, check out our contribution guide.

Until next time!

Joey Aiello
Program Manager, PowerShell

The post Announcing PowerShell 7.1 appeared first on PowerShell.

Updating help for the PSReadLine module

This post was originally published on this site

Updating help for the PSReadLine module

You may have noticed an error message when trying to update the help for the PSReadLine module.

Error updating PSReadLine help

In the example above, I am trying to update help for the PSReadLine module on my Windows
computer. Take a close look at the error message. Notice the spelling of the module name in the
message:

Failed to update Help for the module(s) ‘PSReadline

In PowerShell 6 and higher, the PSReadLine module is spelled with a capital L character. But the
error message is using a lowercase letter.

The root cause of the error

The problem comes from Windows PowerShell 5.1. The version of the PSReadline module that shipped
in Windows PowerShell 5.1 used a lowercase letter in the name. The name of the module was changed
for the release of PowerShell 6. It now uses a capital L in the name.

The Update-Help cmdlet constructs the URL of the CAB file containing the updated help. The URL
path is case-sensitive. The updated help files use the new name with the capital L. PowerShell 6
and higher is installed side-by-side with Windows PowerShell. When you run Update-Help, the cmdlet
attempts to update the help for both versions of PowerShell. The name of the module that
Update-Help uses is based on the name of the folder where the help is stored. For Windows
PowerShell this is C:Program FilesWindowsPowerShellModulesPSReadline.

Note that only the update of help for the Windows PowerShell location is failing.

How to fix this problem

Fortunately the fix is simple. Just rename the folder to
C:Program FilesWindowsPowerShellModulesPSReadLine. To rename this folder, you must be sure to
close all Windows PowerShell sessions to release any open file handles on the directory. Use the
Windows File Explorer to rename the file. If you try to rename the folder from the command line, you
receive the following error message.

Rename-Item: Source and destination path must be different.

Rename module folder

 

The post Updating help for the PSReadLine module appeared first on PowerShell.

SecretManagement and SecretStore Updates

This post was originally published on this site

Two updated preview releases are now available on the PowerShell Gallery:

Before installing these modules please uninstall the current preview versions of the modules and restart your PowerShell session.

To install these updates run the following commands:

Uninstall-Module Microsoft.PowerShell.SecretManagement -Force 
Uninstall-Module Microsoft.PowerShell.SecretStore -Force 
#Restart your PowerShell session 
Install-Module -Name Microsoft.PowerShell.SecretManagement -AllowPrerelease -Repository PSGallery 
Install-Module -Name Microsoft.PowerShell.SecretStore -AllowPrerelease -Repository PSGallery 
Register-SecretVault -Name SecretStore -ModuleName Microsoft.PowerShell.SecretStore -DefaultVault -AllowClobber

SecretManagement Preview 5 Updates

This update to SecretManagement improves the usability of the module by adding name completers, and adding functionality to Unregister-SecretVault for vault extension authors as well a a few other changes. Read the full list of changes below:

  • Get-Secret -Name parameter now accepts arguments with wild card characters as literals (Issue #67)
  • The Verbose parameter switch is now passed to extension vault module functions as an AdditionalParameters name/value pair (Issue #66)
  • Get-SecretVault -Name parameter now takes a string[] type argument (Issue #59)
  • Test-SecretVault -Name parameter now takes a string[] type argument and accepts wild card characters (Issue #56)
  • Register-SecretVault now has a -PassThru parameter to return information on the secret vault just registered
  • When an extension vault is unregistered and if the vault provides a Unregister-SecretVault function, that extension vault function will be called before the extension vault is unregistered (Issue #60)
  • Vault name and Secret name completers have been added to the cmdlets (Issue #35)

SecretStore Preview 3 Updates

This update to SecretStore includes updates to the cmdlet interface based on user feedback and desire to optimize the usability of the vault. Read the full list of changes below:

  • Set-SecretStoreConfiguration now has a -PassThru parameter to write the store configuration object to the pipeline, and no longer writes the configuration object by default (Issue #25).
  • -PasswordTimeout value of zero now allows the provided password to be used only once (Issue #30).
  • When setting a password, an empty password is no longer accepted (Issue #31).
  • Set-SecretStorePassword now has a parameter set that takes old/new password arguments, to allow setting password by automation (Issue #26).
  • Reset-SecretStore now has a new -Password and -PassThru parameter.
  • Reset-SecretStore will now prompt immediately for a new password, if password authentication is selected and prompt interaction is allowed (Issue #34)

Finding other available extension Vaults

To find other SecretManagement extension vault modules, search the PowerShell Gallery for the “SecretManagement” tag. Some community vault extensions that are available:

Thank you to everyone who has created vaults thus far!

Feedback and Support

Community feedback has been essential to the iterative development of these modules. Thank you to everyone who has contributed issues, and feedback thus far! As we approach General Availability, targeted for later this year, for these modules now is the time to test the modules against your scenarios to request changes (especially breaking ones) and discover bugs. To file issues or get support for the SecretManagement interface or vault development experience please use the SecretManagement repository. For issues which pertain specifically to the SecretStore and its cmdlet interface please use the SecretStore repository.

Sydney Smith PowerShell Team

The post SecretManagement and SecretStore Updates appeared first on PowerShell.

PowerShell Working Groups

This post was originally published on this site

Since we open sourced PowerShell in 2016, PowerShell has been an immensely popular project on GitHub.
Every year,
700-1000 PRs and 1300-1500 issues are submitted to the PowerShell repo,
with roughly half of the PRs and 90% of the issues filed from the community.

We realize that some of these issues and PRs have been piling up and,
as the project has grown in popularity and community activity,
we sometimes struggle with the sheer volume of them.
Those of us on the PowerShell Committee have been discussing some ways that we think
we might be able to improve the efficiency of our decision-making process,
and to reduce bottlenecks that may be causing the increase in our overall backlog.

We set out with a couple of goals:

First, we wanted to increase the velocity of innovation in PowerShell,
but without compromising the stability of the engine and language that so many depend upon
within their critical infrastructure and automation environments.
It’s critical that anything we do in changing the management of the PowerShell project not jeopardize this.

We also noticed that a lot of contributor time is being spent on contributions and discussions that
are ultimately rejected by Maintainers or the Committee.
Despite being rejected for legitimate reasons (e.g. risky breaking changes),
we recognize that the rejection could happen before the contributor spends considerable time and effort.

To that end, we want to:

  1. increase the number of people who can make approve or reject proposals,
    especially where those people have domain-specific knowledge about a topic
  2. make those approvals and rejections more explicit, giving contributors confidence in moving forward
  3. make approvals and rejections earlier in the process to avoid unnecessary work for contributors and maintainers

Working Groups

To meet these goals, we are introducing the concept of Working Groups (WGs) within the PowerShell project
(including those repositories that contribute their modules into the PowerShell package).
You can think of WGs as subcommittees for specific areas within the PowerShell project.
Some of their responsibilities include:

  1. Fostering discussions in issues and pull requests
  2. Deciding whether feature proposals need request-for-comment (RFC) docs to be approved by the Committee
  3. Approving or rejecting feature proposals in issues
  4. Offering guidance and expertise in RFC discussions
  5. Triaging bugs filed as issues
  6. Reviewing code in pull requests

Initially, working groups will only consist of PowerShell Team members,
but we will be reaching out to high-impact community contributors over the next few months
to gauge their interest in joining WGs.

Issue Flow

There are two primary categories of issues that get filed in the PowerShell repository:
bugs and feature proposals.
Bugs and features will each be handled differently going forward.

Bugs

Bugs are the easy case. At a high-level, when a bug gets filed:

  1. A Maintainer will label the issue with the appropriate Working Group(s)
  2. Working Group members for those labels will review the bug to determine if it is a legitimate bug,
    by-design, external to the project, and/or worth spending time to fix
    (based on the value, complexity, risk, etc.)
  3. When a bug has been established as legitimate, Working Group members will establish the severity of the bug
    (i.e. the importance of fixing it)
  4. If and when a PowerShell Team member or contributor files a PR to fix the bug,
    at least one Working Group member will be responsible for reviewing the PR.

In practice, this is similar to how bugs are already handled today.
However, we’re hopeful that the addition of Working Group members outside of the PowerShell Team
will enable a greater number of bugs to be triaged and resolved appropriately,
as well as to unblock a number of bug fixes in PR that are of a lower priority.

Feature Proposals

Feature proposals are a little more complicated.

First and foremost, any new feature proposals should initially be filed
as issues, specifically using the issue template for feature
requests

(subject to some ongoing changes). This issue must include:

  • a description of the feature being proposed
  • the scenario for using the feature (i.e. why is the feature useful
    in the real world)
  • examples of how the feature might work in practice (including mandatory example script blocks and output)

Again, Maintainers will label the issue for the appropriate WGs in order to bring them into the issue for discussion.
Working Group members will facilitate a discussion with the community around the utility and design of the proposal,
as well as contributing their expertise on the feasibility and design consistency of implementing the proposal.

One pattern that we are noticing within the PowerShell repo today is the large number of proposals that could
be implemented outside of PowerShell itself (usually via external modules).
In keeping with our goal of maintaining stability in PowerShell,
we’d prefer that this experimentation happens via the PowerShell Gallery,
where modules can be published as prerelease,
and where semantic versioning can be used to communicate breaking changes.
Therefore, WGs will aggressively reject any feature proposals that can be implemented
externally from the repo.

WGs will also decide whether they believe the feature proposal requires an RFC,
based on the complexity, size, and potential impact of the proposal.
Where RFCs are not required, WGs will approve the proposal and then will review the eventual PR to implement it.
Where RFCs are required, contributors will be asked to submit RFCs.
Working Group members will participate heavily in the RFC discussion,
contributing their expertise to help the Committee make decisions on whether to accept the proposal.

Experimental Features

Experimental features are features shipped in PowerShell that are not officially supported as they may be
unstable or subject to change in the future.
(They’re turned on by default in preview branches and off by default in officially supported versions,
including release candidates.)

We introduced experimental features as a way to accelerate development and gather feedback in situations where
we’re unsure whether a specific approach is best,
and where we may want to change the behavior before users start depending on it in production.

In the past, we’ve largely used experimental features for new behavior that we already have a strong intent to eventually merge.
While we’ve caught certain issues that have prevented experimental features from being accepted as stable,
we believe the current perception is that these features will eventually become stable.

In the future, we’d like to use experimental features for experimenting
and gathering user feedback on whether a feature should exist at all,
with a more explicit assertion that many of them will never find their way to a supported GA release.
This means that we may be accepting more PRs into PowerShell as experimental features,
but that this acceptance is not necessarily long-term acceptance into PowerShell.

Instead, the RFC process will be used to convey full acceptance,
something that may happen long after code has been accepted as experimental.
And in fact, the feedback received around the experimental will be used by the Committee to inform the RFC decision.

What’s next?

Similar to the way we roll out functionality in PowerShell,
we’ll be taking a staged approach to rolling out these governance changes, taking feedback along the way.

In the near term, members of the PowerShell Team have been added to preliminary WGs,
and you’ll see Area issue labels change to reflect these WGs as we’ve defined them.
Members of these WGs will be responsible for triaging new issues under those labels,
reviewing PRs under those labels, and (eventually) working through the backlog of existing issues.
WGs will also be experimenting with various ways of organizing themselves,
including how they divvy up issues/PRs and how much consensus amongst themselves to make a decision.

Over the next couple months, we’ll introduce more of this process as official governance proposals within the RFC repo,
and update our existing governance language to reflect the new changes.
These changes may continue to evolve as we learn more about what does and doesn’t work.

The Committee will address existing RFCs on a case-by-case basis.
Some have already been extensively discussed as issues and/or RFC discussions,
and we may choose to move forward with experimental implementations or reject them altogether.

If folks feel that issues, pull requests, or RFCs aren’t being adequately addressed by WGs,
they should still feel free to mention @PowerShell/powershell-committee
or to request that a Review-Committee label be added.
In the future, we’ll have more guidance on how escalations and Committee reviews will work.

Eventually, we’ll reach out to contributors who may be interested in joining these Working Groups,
completing our original goal of increasing the number of people who can make decisions about specific areas of
PowerShell.

Thank you!

Thanks to our contributors and users for continuing to submit issues, pull requests, and RFCs to the PowerShell repo.
We appreicate your patience as we work towards this new model, and we encourage you to provide feedback as issues
in the PowerShell-RFC repo as we continue on this journey.

The post PowerShell Working Groups appeared first on PowerShell.