mirror of
https://github.com/PowerShell/PowerShell.git
synced 2024-11-27 03:46:23 +08:00
Removed trailing whitespace (#3485)
This commit is contained in:
Travis Plunk
Dongbo Wang
parent
18c28f8fc7
commit
68bcd4b528
@ -1,19 +1,19 @@
|
||||
Build PowerShell on Linux
|
||||
=========================
|
||||
|
||||
This guide will walk you through building PowerShell on Linux.
|
||||
This guide will walk you through building PowerShell on Linux.
|
||||
We'll start by showing how to set up your environment from scratch.
|
||||
|
||||
Environment
|
||||
===========
|
||||
|
||||
These instructions are written assuming the Ubuntu 14.04 LTS, since that's the distro the team uses.
|
||||
These instructions are written assuming the Ubuntu 14.04 LTS, since that's the distro the team uses.
|
||||
The build module works on a best-effort basis for other distributions.
|
||||
|
||||
Git Setup
|
||||
---------
|
||||
|
||||
Using Git requires it to be set up correctly;
|
||||
Using Git requires it to be set up correctly;
|
||||
refer to the [Working with the PowerShell Repository](../git/README.md),
|
||||
[README](../../README.md), and [Contributing Guidelines](../../.github/CONTRIBUTING.md).
|
||||
|
||||
@ -22,8 +22,8 @@ refer to the [Working with the PowerShell Repository](../git/README.md),
|
||||
Toolchain Setup
|
||||
---------------
|
||||
|
||||
We use the [.NET Command-Line Interface][dotnet-cli] (`dotnet`) to build the managed components,
|
||||
and [CMake][] to build the native components.
|
||||
We use the [.NET Command-Line Interface][dotnet-cli] (`dotnet`) to build the managed components,
|
||||
and [CMake][] to build the native components.
|
||||
Install the following packages for the toolchain:
|
||||
|
||||
- `dotnet`: Must be installed from the `Start-PSBootstrap` module as described below.
|
||||
@ -32,13 +32,13 @@ Install the following packages for the toolchain:
|
||||
- `g++`
|
||||
|
||||
Unfortunately, the `apt-get` feed for `dotnet` has been deprecated,
|
||||
and the latest version is only distributed in the form of three separate packages,
|
||||
and the latest version is only distributed in the form of three separate packages,
|
||||
which require manual dependency resolution.
|
||||
|
||||
Installing the toolchain is as easy as running `Start-PSBootstrap` in PowerShell.
|
||||
Installing the toolchain is as easy as running `Start-PSBootstrap` in PowerShell.
|
||||
Of course, this requires a self-hosted copy of PowerShell on Linux.
|
||||
|
||||
Fortunately, this is as easy as [downloading and installing the package](../installation/linux.md).
|
||||
Fortunately, this is as easy as [downloading and installing the package](../installation/linux.md).
|
||||
The `./tools/download.sh` script will also install the PowerShell package.
|
||||
|
||||
In Bash:
|
||||
@ -49,7 +49,7 @@ In Bash:
|
||||
powershell
|
||||
```
|
||||
|
||||
You should now be in a `powershell` console host that is installed separately from any development copy you're about to build.
|
||||
You should now be in a `powershell` console host that is installed separately from any development copy you're about to build.
|
||||
Just import our module, bootstrap the dependencies, and build!
|
||||
|
||||
In PowerShell:
|
||||
@ -78,7 +78,7 @@ If you have any problems installing `dotnet`, please see their [documentation][c
|
||||
|
||||
The version of .NET CLI is very important; the version we are currently using is `1.0.1`.
|
||||
|
||||
Previous installations of DNX, `dnvm`, or older installations of .NET CLI can cause odd failures when running.
|
||||
Previous installations of DNX, `dnvm`, or older installations of .NET CLI can cause odd failures when running.
|
||||
Please check your version and uninstall prior any prior versions.
|
||||
|
||||
[cli-docs]: https://www.microsoft.com/net/core
|
||||
@ -86,8 +86,8 @@ Please check your version and uninstall prior any prior versions.
|
||||
Build using our module
|
||||
======================
|
||||
|
||||
We maintain a [PowerShell module](../../build.psm1) with the function `Start-PSBuild` to build PowerShell.
|
||||
Since this is PowerShell code, it requires self-hosting.
|
||||
We maintain a [PowerShell module](../../build.psm1) with the function `Start-PSBuild` to build PowerShell.
|
||||
Since this is PowerShell code, it requires self-hosting.
|
||||
If you have followed the toolchain setup section above, you should have `powershell` installed.
|
||||
|
||||
> If you cannot or do not want to self-host, `Start-PSBuild` is just a
|
||||
@ -134,8 +134,8 @@ where `dotnet` consumes it as "content" and thus automatically deploys it.
|
||||
Build the managed projects
|
||||
--------------------------
|
||||
|
||||
The `powershell` project is the .NET Core PowerShell host.
|
||||
It is the top level project, so `dotnet build` transitively builds all its dependencies, and emits a `powershell` executable.
|
||||
The `powershell` project is the .NET Core PowerShell host.
|
||||
It is the top level project, so `dotnet build` transitively builds all its dependencies, and emits a `powershell` executable.
|
||||
The `--configuration Linux` flag is necessary to ensure that the preprocessor definition `LINUX` is defined (see [issue #673][]).
|
||||
|
||||
```sh
|
||||
@ -144,14 +144,14 @@ cd src/powershell-unix
|
||||
dotnet build --configuration Linux
|
||||
```
|
||||
|
||||
The executable will be in `./bin/[configuration]/[framework]/[rid]/[binary name]`,
|
||||
where our configuration is `Linux`, framework is `netcoreapp1.1`,
|
||||
runtime identifier is `ubuntu.14.04-x64`, and binary name is `powershell`.
|
||||
The function `Get-PSOutput` will return the path to the executable;
|
||||
The executable will be in `./bin/[configuration]/[framework]/[rid]/[binary name]`,
|
||||
where our configuration is `Linux`, framework is `netcoreapp1.1`,
|
||||
runtime identifier is `ubuntu.14.04-x64`, and binary name is `powershell`.
|
||||
The function `Get-PSOutput` will return the path to the executable;
|
||||
thus you can execute the development copy via `& (Get-PSOutput)`.
|
||||
|
||||
For deploying PowerShell, `dotnet publish` will emit a `publish` directory that contains a flat list of every dependency required for
|
||||
PowerShell.
|
||||
PowerShell.
|
||||
This can be copied to, for example, `/usr/local/share/powershell` or packaged.
|
||||
|
||||
[issue #673]: https://github.com/PowerShell/PowerShell/issues/673
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Build PowerShell on Windows for .NET Core
|
||||
=========================================
|
||||
|
||||
This guide will walk you through building PowerShell on Windows, targeting .NET Core.
|
||||
This guide will walk you through building PowerShell on Windows, targeting .NET Core.
|
||||
We'll start by showing how to set up your environment from scratch.
|
||||
|
||||
You can also [build PowerShell for Full .NET framework](windows-full.md) on Windows.
|
||||
@ -24,14 +24,14 @@ This guide assumes that you have recursively cloned the PowerShell repository an
|
||||
Visual Studio
|
||||
----------------
|
||||
|
||||
You will need to install an edition of Visual Studio 2015 (Community, Enterprise, or Professional) with the optional feature 'Common Tools for Visual C++' installed.
|
||||
You will need to install an edition of Visual Studio 2015 (Community, Enterprise, or Professional) with the optional feature 'Common Tools for Visual C++' installed.
|
||||
The free Community edition of Visual Studio 2015 can be downloaded [here](https://www.visualstudio.com/visual-studio-community-vs/).
|
||||
|
||||
.NET CLI
|
||||
--------
|
||||
|
||||
We use the [.NET Command Line Interface][dotnet-cli] (`dotnet`) to build PowerShell.
|
||||
The version we are currently using is `1.0.1`.
|
||||
The version we are currently using is `1.0.1`.
|
||||
The `Start-PSBootstrap` function will automatically install it and add it to your path:
|
||||
|
||||
```powershell
|
||||
@ -69,17 +69,17 @@ Start-PSBuild
|
||||
|
||||
Congratulations! If everything went right, PowerShell is now built and executable as `./src/powershell-win-core/bin/Debug/netcoreapp1.1/win10-x64/powershell`.
|
||||
|
||||
This location is of the form `./[project]/bin/[configuration]/[framework]/[rid]/[binary name]`,
|
||||
and our project is `powershell`, configuration is `Debug` by default,
|
||||
framework is `netcoreapp1.1`, runtime identifier is **probably** `win10-x64`
|
||||
(but will depend on your operating system;
|
||||
don't worry, `dotnet --info` will tell you what it was), and binary name is `powershell`.
|
||||
The function `Get-PSOutput` will return the path to the executable;
|
||||
This location is of the form `./[project]/bin/[configuration]/[framework]/[rid]/[binary name]`,
|
||||
and our project is `powershell`, configuration is `Debug` by default,
|
||||
framework is `netcoreapp1.1`, runtime identifier is **probably** `win10-x64`
|
||||
(but will depend on your operating system;
|
||||
don't worry, `dotnet --info` will tell you what it was), and binary name is `powershell`.
|
||||
The function `Get-PSOutput` will return the path to the executable;
|
||||
thus you can execute the development copy via `& (Get-PSOutput)`.
|
||||
|
||||
The `powershell` project is the .NET Core PowerShell host.
|
||||
It is the top level project, so `dotnet build` transitively builds all its dependencies,
|
||||
and emits a `powershell` executable.
|
||||
The `powershell` project is the .NET Core PowerShell host.
|
||||
It is the top level project, so `dotnet build` transitively builds all its dependencies,
|
||||
and emits a `powershell` executable.
|
||||
The cross-platform host has built-in documentation via `--help`.
|
||||
|
||||
You can run our cross-platform Pester tests with `Start-PSPester`.
|
||||
|
||||
@ -2,20 +2,20 @@
|
||||
|
||||
## Terms
|
||||
|
||||
* [**PowerShell Committee**](#powershell-committee): A committee of project owners who are responsible for design decisions, approving [RFCs][RFC-repo], and approving new maintainers/committee members
|
||||
* [**PowerShell Committee**](#powershell-committee): A committee of project owners who are responsible for design decisions, approving [RFCs][RFC-repo], and approving new maintainers/committee members
|
||||
* **Project Leads**: Project Leads support the PowerShell Committee, engineering teams, and community by working across Microsoft teams and leadership, and working through industry issues with other companies.
|
||||
They also have optional votes on the PowerShell Committee when they choose to invoke them. The initial Project Leads for PowerShell are Angel Calvo ([AngelCalvo](https://github.com/AngelCalvo)) and Kenneth Hansen ([khansen00](https://github.com/khansen00)).
|
||||
* [**Repository maintainer**](#repository-maintainers): An individual responsible for merging pull requests (PRs) into `master` when all requirements are met (code review, tests, docs, and RFC approval as applicable).
|
||||
Repository Maintainers are the only people with write permissions into `master`.
|
||||
* [**Area experts**](#area-experts): People who are experts for specific components (e.g. PSReadline, the parser) or technologies (e.g. security, performance).
|
||||
Area experts are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
* [**Area experts**](#area-experts): People who are experts for specific components (e.g. PSReadline, the parser) or technologies (e.g. security, performance).
|
||||
Area experts are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
* **Corporation**: The Corporation owns the PowerShell repository and, under extreme circumstances, reserves the right to dissolve or reform the PowerShell Committee, the Project Leads, and the Corporate Maintainer.
|
||||
The Corporation for PowerShell is Microsoft.
|
||||
* **Corporate Maintainer**: The Corporate Maintainer is an entity, person or set of persons, with the ability to veto decisions made by the PowerShell Committee or any other collaborators on the PowerShell project.
|
||||
This veto power will be used with restraint since it is intended that the community drive the project.
|
||||
This veto power will be used with restraint since it is intended that the community drive the project.
|
||||
The Corporate Maintainer is determined by the Corporation both initially and in continuation.
|
||||
The initial Corporate Maintainer for PowerShell is Jeffrey Snover ([jpsnover](https://github.com/jpsnover)).
|
||||
* [**RFC process**][RFC-repo]: The "review-for-comment" (RFC) process whereby design decisions get made.
|
||||
* [**RFC process**][RFC-repo]: The "review-for-comment" (RFC) process whereby design decisions get made.
|
||||
|
||||
## PowerShell Committee
|
||||
|
||||
@ -31,7 +31,7 @@ The PowerShell Committee and its members (aka Committee Members) are the primary
|
||||
|
||||
### Committee Member Responsibilities
|
||||
|
||||
Committee Members are responsible for reviewing and approving [PowerShell RFCs][RFC-repo] proposing new features or design changes.
|
||||
Committee Members are responsible for reviewing and approving [PowerShell RFCs][RFC-repo] proposing new features or design changes.
|
||||
|
||||
#### Changes that require an [RFC][RFC-repo]
|
||||
|
||||
@ -45,14 +45,14 @@ The following types of decisions require a written RFC and ample time for the co
|
||||
|
||||
#### Changes that don't require an RFC
|
||||
|
||||
In some cases, a new feature or behavior may be deemed small enough to forgo the RFC process
|
||||
In some cases, a new feature or behavior may be deemed small enough to forgo the RFC process
|
||||
(e.g. changing the default PSReadline `EditMode` to `Emacs` on Mac/Linux).
|
||||
In these cases, [issues marked as `1 - Planning`][issue-process] require only a simple majority of Committee Members to sign off.
|
||||
In these cases, [issues marked as `1 - Planning`][issue-process] require only a simple majority of Committee Members to sign off.
|
||||
After that, a Repository Maintainer should relabel the issue as `2 - Ready` so that a contributor can begin working on it.
|
||||
|
||||
If any Committee Members feels like this behavior is large enough to warrant an RFC, they can add the label `RFC-required` and the issue owner is expected to follow the RFC process.
|
||||
If any Committee Members feels like this behavior is large enough to warrant an RFC, they can add the label `RFC-required` and the issue owner is expected to follow the RFC process.
|
||||
|
||||
#### Committee Member DOs and DON'Ts
|
||||
#### Committee Member DOs and DON'Ts
|
||||
|
||||
As a PowerShell Committee Member:
|
||||
|
||||
@ -73,23 +73,23 @@ Members are encouraged to share their opinions, but they should be presented as
|
||||
### PowerShell Committee Membership
|
||||
|
||||
The initial PowerShell Committee consists of Microsoft employees.
|
||||
It is expected that over time, PowerShell experts in the community will be made Committee Members.
|
||||
Membership is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
|
||||
It is expected that over time, PowerShell experts in the community will be made Committee Members.
|
||||
Membership is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
|
||||
|
||||
At any point in time, a Committee Member can nominate a strong community member to join the Committee.
|
||||
At any point in time, a Committee Member can nominate a strong community member to join the Committee.
|
||||
Nominations should be submitted in the form of [RFCs][RFC-repo] detailing why that individual is qualified and how they will contribute.
|
||||
After the RFC has been discussed, a unanimous vote will be required for the new Committee Member to be confirmed.
|
||||
After the RFC has been discussed, a unanimous vote will be required for the new Committee Member to be confirmed.
|
||||
|
||||
## Repository Maintainers
|
||||
|
||||
Repository Maintainers are trusted stewards of the PowerShell repository responsible for maintaining consistency and quality of PowerShell code.
|
||||
Repository Maintainers are trusted stewards of the PowerShell repository responsible for maintaining consistency and quality of PowerShell code.
|
||||
One of their primary responsibilities is merging pull requests after all requirements have been fulfilled.
|
||||
|
||||
For more information on Repository Maintainers--their responsibilities, who they are, and how one becomes a Maintainer--see the [README for Repository Maintainers][maintainers].
|
||||
|
||||
## Area Experts
|
||||
|
||||
Area Experts are people with knowledge of specific components or technologies in the PowerShell domain. They are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
Area Experts are people with knowledge of specific components or technologies in the PowerShell domain. They are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
|
||||
They have [write access](https://help.github.com/articles/permission-levels-for-an-organization-repository/) to the PowerShell repository which gives them the power to:
|
||||
|
||||
@ -99,14 +99,14 @@ They have [write access](https://help.github.com/articles/permission-levels-for-
|
||||
|
||||
### Area Expert Responsibilities
|
||||
|
||||
If you are an Area Expert, you are expected to be actively involved in any development, design, or contributions in your area of expertise.
|
||||
If you are an Area Expert, you are expected to be actively involved in any development, design, or contributions in your area of expertise.
|
||||
|
||||
If you are an Area Expert:
|
||||
|
||||
1. **DO** assign the [correct labels][issue-process]
|
||||
1. **DO** assign yourself to issues labeled with your area of expertise
|
||||
1. **DO** code reviews for issues where you're assigned or in your areas of expertise.
|
||||
1. **DO** reply to new issues and pull requests that are related to your area of expertise
|
||||
1. **DO** reply to new issues and pull requests that are related to your area of expertise
|
||||
(while reviewing PRs, leave your comment even if everything looks good - a simple "Looks good to me" or "LGTM" will suffice, so that we know someone has already taken a look at it).
|
||||
1. **DO** make sure contributors are following the [contributor guidelines](../../.github/CONTRIBUTING.md).
|
||||
1. **DO** ask people to resend a pull request, if it [doesn't target `master`](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request).
|
||||
@ -122,12 +122,12 @@ If you are an Area Expert:
|
||||
|
||||
See our [Issue Management Process][issue-process]
|
||||
|
||||
## Pull Request Process
|
||||
## Pull Request Process
|
||||
|
||||
See our [Pull Request Process][pull-request-process]
|
||||
|
||||
[RFC-repo]: https://github.com/PowerShell/PowerShell-RFC
|
||||
[pester]: ../testing-guidelines/WritingPesterTests.md
|
||||
[pester]: ../testing-guidelines/WritingPesterTests.md
|
||||
[ci-system]: ../testing-guidelines/testing-guidelines.md#ci-system
|
||||
[breaking-changes]: ../dev-process/breaking-change-contract.md
|
||||
[issue-process]: ../maintainers/issue-management.md
|
||||
|
||||
@ -20,18 +20,18 @@ Any change that is a clear violation of the public contract.
|
||||
### Unacceptable changes:
|
||||
|
||||
+ A code change that results in a change to the existing behavior observed for a given input with an API, protocol or the PowerShell language.
|
||||
+ Renaming or removing a public type, type member, or type parameter; renaming or removing a cmdlet or cmdlet parameter (note: it is possible to rename a cmdlet parameter if a parameter alias is added. This is an acceptable solution for PowerShell scripts but may break .NET code that depends on the name of the original member on the cmdlet object type.)
|
||||
+ Decreasing the range of accepted values within a given parameter.
|
||||
+ Changing the value of a public constant or enum member; changing the type of a cmdlet parameter to a more restrictive type.
|
||||
+ Renaming or removing a public type, type member, or type parameter; renaming or removing a cmdlet or cmdlet parameter (note: it is possible to rename a cmdlet parameter if a parameter alias is added. This is an acceptable solution for PowerShell scripts but may break .NET code that depends on the name of the original member on the cmdlet object type.)
|
||||
+ Decreasing the range of accepted values within a given parameter.
|
||||
+ Changing the value of a public constant or enum member; changing the type of a cmdlet parameter to a more restrictive type.
|
||||
+ Example: A cmdlet with a parameter -p1 that was previously type as [object] cannot be changed to be or a more restrictive type such as [int].
|
||||
+ Making an incompatible change to any protocol without increasing the protocol version number.
|
||||
+ Making an incompatible change to any protocol without increasing the protocol version number.
|
||||
|
||||
### Acceptable changes:
|
||||
|
||||
+ Any existing behavior that results in an error message generally may be changed to provide new functionality.
|
||||
+ A new instance field is added to a type (this impacts .NET serialization but not PowerShell serialization and so is considered acceptable.)
|
||||
+ Adding new types, new type members and new cmdlets
|
||||
+ Making changes to the protocols with a protocol version increment. Older versions of the protocol would still need to be maintained to allow communication with earlier systems. This would require that protocol negotiation take place between the two systems. In addition to any protocol code changes, the Microsoft Open Specification program requires that the formal protocol specification for a protocol be updated in a timely manner. An example of a MS protocol specification document (MS-PSRP) can be found at: https://msdn.microsoft.com/en-us/library/dd357801.aspx
|
||||
+ Any existing behavior that results in an error message generally may be changed to provide new functionality.
|
||||
+ A new instance field is added to a type (this impacts .NET serialization but not PowerShell serialization and so is considered acceptable.)
|
||||
+ Adding new types, new type members and new cmdlets
|
||||
+ Making changes to the protocols with a protocol version increment. Older versions of the protocol would still need to be maintained to allow communication with earlier systems. This would require that protocol negotiation take place between the two systems. In addition to any protocol code changes, the Microsoft Open Specification program requires that the formal protocol specification for a protocol be updated in a timely manner. An example of a MS protocol specification document (MS-PSRP) can be found at: https://msdn.microsoft.com/en-us/library/dd357801.aspx
|
||||
|
||||
## Bucket 2: Reasonable Grey Area
|
||||
|
||||
@ -39,9 +39,9 @@ Change of behavior that customers would have reasonably depended on.
|
||||
|
||||
Examples:
|
||||
|
||||
+ Change in timing/order of events (even when not specified in docs)
|
||||
+ Change in timing/order of events (even when not specified in docs)
|
||||
+ Example: PowerShell events are handled by interleaving their execution with the execution of the main pipeline thread. Where and when this interleaving occurs might change. This order of execution is not specified but is deterministic so changing it might break some scripts.
|
||||
+ Change in parsing of input and throwing new errors (even if parsing behavior is not specified in the docs)
|
||||
+ Change in parsing of input and throwing new errors (even if parsing behavior is not specified in the docs)
|
||||
+ Example: a script may be using a JSON parser that is forgiving to minor syntactic errors in the JSON text. Changing that parser to be more rigorous in its processing would result in errors being thrown when no error was generated in the past thus breaking scripts.
|
||||
|
||||
Judiciously making changes in these type of features require judgement: how predictable, obvious, consistent was the behavior? In general, a significant external preview of the change would need to be done also possibly requiring an RFC to be created to allow for community input on the proposal.
|
||||
@ -52,7 +52,7 @@ Change of behavior that customers could have depended on, but probably wouldn't.
|
||||
|
||||
Examples:
|
||||
|
||||
+ correcting behavior in a subtle corner case that has no obvious utility.
|
||||
+ correcting behavior in a subtle corner case that has no obvious utility.
|
||||
|
||||
+ Example: the existing behavior of the PowerShell cd called without arguments is to do nothing. Changing this behavior to be consistent with UNIX shells which typically set the CWD to the user’s home directory
|
||||
|
||||
@ -75,7 +75,7 @@ It is impossible to evolve a code base without making such changes, so we don't
|
||||
+ All bucket 1, 2, and 3 breaking changes require contacting team at @powershell/powershell.
|
||||
+ If you're not sure into which bucket a given change falls, contact us as well.
|
||||
+ It doesn't matter if the existing behavior is "wrong", we still need to think through the implications. PowerShell has been in broad use for over 10 years so we be must be extremely sensitive to breaking existing users and scripts.
|
||||
+ If a change is deemed too breaking, we can help identify alternatives such as introducing a new API or cmdlet and obsoleting the old one.
|
||||
+ If a change is deemed too breaking, we can help identify alternatives such as introducing a new API or cmdlet and obsoleting the old one.
|
||||
|
||||
Request for clarifications or suggested alterations to this document should be done by opening issues against this document.
|
||||
|
||||
|
||||
@ -13,7 +13,7 @@ This file is a simple json hashtable that describes mapping between files in sou
|
||||
|
||||
#### Example
|
||||
|
||||
There is an entry
|
||||
There is an entry
|
||||
|
||||
```
|
||||
"monad/src/engine/COM/ComMethod.cs": "engine/COM/ComMethod.cs",
|
||||
@ -27,16 +27,16 @@ It tells us that file `ComMethod.cs` located at `monad/src/engine/COM/ComMethod.
|
||||
Our dev module contains a number of functions that can be used to work with this mapping file.
|
||||
|
||||
* `Copy-MappedFiles` -- copies files from psl-monad into PowerShell/PowerShell. Used for "sd -> github" integration.
|
||||
* `Send-GitDiffToSd` -- applies patch from git to **admin** enlistment with respect to all `map.json` files.
|
||||
* `Send-GitDiffToSd` -- applies patch from git to **admin** enlistment with respect to all `map.json` files.
|
||||
It supports `-WhatIf` switch.
|
||||
|
||||
```
|
||||
> Send-GitDiffToSd -diffArg1 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be~1 -diffArg2 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be -AdminRoot d:\e\ps_dev\admin
|
||||
> Send-GitDiffToSd -diffArg1 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be~1 -diffArg2 32b90c048aa0c5bc8e67f96a98ea01c728c4a5be -AdminRoot d:\e\ps_dev\admin
|
||||
> cd d:\e\ps_dev\admin
|
||||
> sd online ...
|
||||
> # move files to new change list (i.e. with sdb)
|
||||
> sd submit -c <n>
|
||||
|
||||
|
||||
```
|
||||
|
||||
## Updating `map.json`
|
||||
@ -45,7 +45,7 @@ If you are bringing new (that are not yet included) files from source-depot, you
|
||||
|
||||
This way, we can keep track of changes and have ability to integrate changes back to Source Depot.
|
||||
|
||||
Use this approach for any files from source-depot (including test files)
|
||||
Use this approach for any files from source-depot (including test files)
|
||||
|
||||
## Creating `map.json`
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
Submodules
|
||||
==========
|
||||
|
||||
While most developers will not have to deal with submodules on a regular basis, those who do should read this information.
|
||||
While most developers will not have to deal with submodules on a regular basis, those who do should read this information.
|
||||
The submodules currently in this project are:
|
||||
|
||||
- `src/Modules/Pester`: The Pester testing framework for PowerShell
|
||||
@ -16,13 +16,13 @@ Rebase and Fast-Forward Merge Pull Requests in Submodules
|
||||
|
||||
*This is not necessary in the superproject, only submodules!*
|
||||
|
||||
**DO NOT** commit updates unless absolutely necessary.
|
||||
**DO NOT** commit updates unless absolutely necessary.
|
||||
When submodules must be updated, a separate Pull Request must be submitted, reviewed, and merged before updating the superproject.
|
||||
|
||||
Because GitHub's "Merge Pull Request" button merges with `--no-ff`, an extra merge commit will always be created.
|
||||
This is especially annoying when trying to commit updates to submodules.
|
||||
Because GitHub's "Merge Pull Request" button merges with `--no-ff`, an extra merge commit will always be created.
|
||||
This is especially annoying when trying to commit updates to submodules.
|
||||
Therefore our policy is to merge using the Git CLI after approval, with a rebase onto master to enable a fast-forward merge.
|
||||
|
||||
When committing submodule updates, ensure no other changes are in the same commit.
|
||||
Submodule bumps may be included in feature branches for ease of work,
|
||||
When committing submodule updates, ensure no other changes are in the same commit.
|
||||
Submodule bumps may be included in feature branches for ease of work,
|
||||
but the update must be independently approved before merging into master.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# Host PowerShell Core in .NET Core Applications
|
||||
|
||||
> This documentation is based on PowerShell Core packages built against .NET Core 1.1 and prior.
|
||||
> This documentation is based on PowerShell Core packages built against .NET Core 1.1 and prior.
|
||||
> Things may change after we move to .NET Core 2.0.
|
||||
|
||||
## PowerShell Core targeting .NET Core 1.1 and Prior
|
||||
@ -32,7 +32,7 @@ as it's what you need when building a .NET Core application with .NET CLI.
|
||||
|
||||
### Comparison - Hosting Windows PowerShell vs. Hosting PowerShell Core
|
||||
|
||||
The following code demonstrates how to host Windows PowerShell in an application.
|
||||
The following code demonstrates how to host Windows PowerShell in an application.
|
||||
As shown below, you can insert your business logic code directly in the `Main` method.
|
||||
|
||||
```CSharp
|
||||
@ -72,7 +72,7 @@ using System.Reflection;
|
||||
|
||||
namespace Application.Test
|
||||
{
|
||||
public class Program
|
||||
public class Program
|
||||
{
|
||||
/// <summary>
|
||||
/// Managed entry point shim, which starts the actual program
|
||||
@ -80,10 +80,10 @@ namespace Application.Test
|
||||
public static int Main(string[] args)
|
||||
{
|
||||
// Application needs to use PowerShell AssemblyLoadContext if it needs to create PowerShell runspace
|
||||
// PowerShell engine depends on PS ALC to provide the necessary assembly loading/searching support that is missing from .NET Core
|
||||
// PowerShell engine depends on PS ALC to provide the necessary assembly loading/searching support that is missing from .NET Core
|
||||
string appBase = System.IO.Path.GetDirectoryName(typeof(Program).GetTypeInfo().Assembly.Location);
|
||||
System.Console.WriteLine("\nappBase: {0}", appBase);
|
||||
|
||||
|
||||
// Initialize the PS ALC and let it load 'Logic.dll' and start the execution
|
||||
return (int)PowerShellAssemblyLoadContextInitializer.
|
||||
InitializeAndCallEntryMethod(
|
||||
@ -124,7 +124,7 @@ namespace Application.Test
|
||||
|
||||
### .NET Core Sample Application
|
||||
|
||||
You can find the sample application project `"MyApp"` under [sample-dotnet1.1](./sample-dotnet1.1).
|
||||
You can find the sample application project `"MyApp"` under [sample-dotnet1.1](./sample-dotnet1.1).
|
||||
To build the sample project, run the following commands ([.NET Core SDK 1.0.1](https://github.com/dotnet/cli/releases/tag/v1.0.1) is required):
|
||||
|
||||
```powershell
|
||||
|
||||
@ -268,16 +268,16 @@ For more details, see [Create and Run PowerShell Script Guide][create-run-script
|
||||
|
||||
Recommended Training and Reading
|
||||
----
|
||||
- Video: [Get Started with PowerShell][remoting] from Channel9
|
||||
- Video: [Get Started with PowerShell][remoting] from Channel9
|
||||
- [eBooks from PowerShell.org](https://powershell.org/ebooks/)
|
||||
- [eBooks from PowerShell.com][ebooks-powershell.com]
|
||||
- [eBooks from PowerShell.com][ebooks-powershell.com]
|
||||
- [eBooks List][ebook-list] by Martin Schvartzman
|
||||
- [Tutorial from MVP][tutorial]
|
||||
- Script Guy blog: [The best way to Learn PowerShell][to-learn]
|
||||
- [Understanding PowerShell Module][ps-module]
|
||||
- [How and When to Create PowerShell Module][create-ps-module] by Adam Bertram
|
||||
- Script Guy blog: [The best way to Learn PowerShell][to-learn]
|
||||
- [Understanding PowerShell Module][ps-module]
|
||||
- [How and When to Create PowerShell Module][create-ps-module] by Adam Bertram
|
||||
- Video: [PowerShell Remoting in Depth][in-depth] from Channel9
|
||||
- [PowerShell Basics: Remote Management][remote-mgmt] from ITPro
|
||||
- [PowerShell Basics: Remote Management][remote-mgmt] from ITPro
|
||||
- [Running Remote Commands][remote-commands] from PowerShell Web Docs
|
||||
- [Samples for PowerShell Scripts][examples]
|
||||
- [Samples for Writing a PowerShell Script Module][examples-ps-module]
|
||||
|
||||
@ -27,10 +27,10 @@ Editing with Visual Studio Code
|
||||
|
||||
**2. Installing PowerShell Extension**
|
||||
|
||||
- Launch the Visual Studio Code app by:
|
||||
* **Windows**: typing **code** in your PowerShell session
|
||||
* **Linux**: typing **code** in your terminal
|
||||
* **macOS**: typing **code** in your terminal
|
||||
- Launch the Visual Studio Code app by:
|
||||
* **Windows**: typing **code** in your PowerShell session
|
||||
* **Linux**: typing **code** in your terminal
|
||||
* **macOS**: typing **code** in your terminal
|
||||
|
||||
- Launch **Quick Open** by pressing **Ctrl+P** (**Cmd+P** on Mac).
|
||||
- In Quick Open, type **ext install powershell** and hit **Enter**.
|
||||
@ -40,9 +40,9 @@ Editing with Visual Studio Code
|
||||
|
||||
|
||||
- Click the **Install** button on the PowerShell extension from Microsoft.
|
||||
- After the install, you will see the **Install** button turns to **Reload**.
|
||||
- After the install, you will see the **Install** button turns to **Reload**.
|
||||
Click on **Reload**.
|
||||
- After Visual Studio Code has reload, you are ready for editing.
|
||||
- After Visual Studio Code has reload, you are ready for editing.
|
||||
|
||||
For example, to create a new file, click **File->New**.
|
||||
To save it, click **File->Save** and then provide a file name, let's say "HelloWorld.ps1".
|
||||
@ -139,10 +139,10 @@ Once the debug configuration is established, you can select which configuration
|
||||
|
||||
There are a few blogs that may be helpful to get you started using PowerShell extension for Visual Studio Code
|
||||
|
||||
- Visual Studio Code: [PowerShell Extension][ps-extension]
|
||||
- [Write and debug PowerShell scripts in Visual Studio Code][debug]
|
||||
- [Debugging Visual Studio Code Guidance][vscode-guide]
|
||||
- [Debugging PowerShell in Visual Studio Code][ps-vscode]
|
||||
- Visual Studio Code: [PowerShell Extension][ps-extension]
|
||||
- [Write and debug PowerShell scripts in Visual Studio Code][debug]
|
||||
- [Debugging Visual Studio Code Guidance][vscode-guide]
|
||||
- [Debugging PowerShell in Visual Studio Code][ps-vscode]
|
||||
- [Get started with PowerShell development in Visual Studio Code][getting-started]
|
||||
- [Visual Studio Code editing features for PowerShell development – Part 1][editing-part1]
|
||||
- [Visual Studio Code editing features for PowerShell development – Part 2][editing-part2]
|
||||
|
||||
@ -28,11 +28,11 @@ They have [write access](https://help.github.com/articles/repository-permission-
|
||||
|
||||
## Repository Maintainer Responsibilities
|
||||
|
||||
Repository Maintainers enable rapid contributions while maintaining a high level of quality in PowerShell by ensuring that all development processes are being followed correctly.
|
||||
Repository Maintainers enable rapid contributions while maintaining a high level of quality in PowerShell by ensuring that all development processes are being followed correctly.
|
||||
|
||||
If you are a Repository Maintainer, you:
|
||||
|
||||
1. **MUST** ensure that each contributor has signed a valid Contributor License Agreement (CLA)
|
||||
1. **MUST** ensure that each contributor has signed a valid Contributor License Agreement (CLA)
|
||||
1. **MUST** verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.
|
||||
1. **MUST** make sure that [any change requiring approval from the PowerShell Committee](../community/governance.md#changes-that-require-an-rfc) has gone through the proper [RFC][RFC-repo] or approval process
|
||||
1. **MUST** validate that code reviews have been conducted before merging a pull request when no code is written
|
||||
@ -41,14 +41,14 @@ If you are a Repository Maintainer, you:
|
||||
1. **SHOULD** make sure the correct [Area Experts](../community/governance.md#area-experts) are assigned to relevant pull requests and issues.
|
||||
This includes adding extra reviewers when it makes sense
|
||||
(e.g. a pull request that adds remoting capabilities might require a security expert)
|
||||
1. **SHOULD** validate that the names and email addresses in the git commits reasonably match identity of the person submitting the pull request
|
||||
1. **SHOULD** validate that the names and email addresses in the git commits reasonably match identity of the person submitting the pull request
|
||||
1. **SHOULD** make sure contributors are following the [contributor guidelines][CONTRIBUTING]
|
||||
1. **SHOULD** ask people to resend a pull request, if it [doesn't target `master`](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request)
|
||||
1. **SHOULD** wait for the [CI system][ci-system] build to pass for pull requests
|
||||
1. **SHOULD** wait for the [CI system][ci-system] build to pass for pull requests
|
||||
(unless, for instance, the pull request is being submitted to fix broken CI)
|
||||
1. **SHOULD** encourage contributors to refer to issues in their pull request description (e.g. `Resolves issue #123`).
|
||||
If a user did not create an issue prior to submitting their pull request, their pull request should not be rejected.
|
||||
However, they should be reminded to create an issue in the future to frontload any potential problems with the work and to minimize duplication of efforts.
|
||||
However, they should be reminded to create an issue in the future to frontload any potential problems with the work and to minimize duplication of efforts.
|
||||
1. **SHOULD** encourage contributors to create meaningful titles for all PRs.
|
||||
Edit the title if necessary to provide clarity on the problem
|
||||
1. **SHOULD** encourage contributes to write meaningful, descriptive git commits
|
||||
@ -57,7 +57,7 @@ Edit the title if necessary to provide clarity on the problem
|
||||
1. **SHOULD NOT** merge pull requests without the label `cla-signed` or `cla-not-required` from the Microsoft CLA bot
|
||||
(unless the CLA bot is broken, and CLA signing can be confirmed through other means)
|
||||
1. **SHOULD NOT** merge pull requests too quickly after they're submitted.
|
||||
Even if the pull request meets all the requirements, people should have time to give their input
|
||||
Even if the pull request meets all the requirements, people should have time to give their input
|
||||
(unless the pull request is particularly urgent for some reason)
|
||||
1. **SHOULD NOT** merge your own pull requests.
|
||||
If a Repository Maintainer opens a pull request, another Maintainer should merge it unless there are extreme, short-term circumstances requiring a merge or another Maintainer has given explicit sign-off without merging
|
||||
@ -70,14 +70,14 @@ Please see [Issue Management][issue-management]
|
||||
|
||||
1. A contributor opens a pull request.
|
||||
1. The contributor ensures that their pull request passes the [CI system][ci-system] build.
|
||||
- If the build fails, a maintainer adds the ```waiting for author``` label to the pull request.
|
||||
- If the build fails, a maintainer adds the ```waiting for author``` label to the pull request.
|
||||
The contributor can then continue to update the pull request until the build passes.
|
||||
1. Once the build passes, the maintainer either reviews the pull request immediately or adds the ```need review``` label.
|
||||
1. A maintainer or trusted contributor reviews the pull request code.
|
||||
- If the contributor does not meet the reviewer's standards, the reviewer makes comments.
|
||||
A maintainer then removes the ```need review``` label and adds the ```waiting for author``` label.
|
||||
- If the contributor does not meet the reviewer's standards, the reviewer makes comments.
|
||||
A maintainer then removes the ```need review``` label and adds the ```waiting for author``` label.
|
||||
The contributor must address the comments and repeat from step 2.
|
||||
- If the contributor meets the reviewer's standards, the reviewer comments that they are satisfied.
|
||||
- If the contributor meets the reviewer's standards, the reviewer comments that they are satisfied.
|
||||
A maintainer then removes the ```need review``` label.
|
||||
1. Once the code review is completed, a maintainer merges the pull request.
|
||||
|
||||
@ -90,19 +90,19 @@ In these cases:
|
||||
1. Ping the author of PR to remind him of pending changes.
|
||||
- If the contributor responds, it's no longer an abandoned pull request, proceed as normal.
|
||||
2. If the contributor does not respond **within a week**:
|
||||
- Create a new branch with the changes and open an issue to merge the code into the dev branch.
|
||||
Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
|
||||
- Create a new branch with the changes and open an issue to merge the code into the dev branch.
|
||||
Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
|
||||
- If the changes in an abandoned pull request are no longer needed (e.g. due to refactoring of the code base or a design change), simply close the pull request.
|
||||
|
||||
## Becoming a Repository Maintainer
|
||||
|
||||
Repository Maintainers currently consist entirely of Microsoft employees.
|
||||
It is expected that over time, regular trusted contributors to the PowerShell repository will be made Repository Maintainers.
|
||||
Eligibility is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
|
||||
Eligibility is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
|
||||
|
||||
At any point in time, a Repository Maintainers can nominate a strong community member to become a Repository Maintainer.
|
||||
At any point in time, a Repository Maintainers can nominate a strong community member to become a Repository Maintainer.
|
||||
Nominations should be submitted in the form of [RFCs][RFC-repo] detailing why that individual is qualified and how they will contribute.
|
||||
After the RFC has been discussed, a unanimous vote by the PowerShell Committee will be required for the new Repository Maintainer to be confirmed.
|
||||
After the RFC has been discussed, a unanimous vote by the PowerShell Committee will be required for the new Repository Maintainer to be confirmed.
|
||||
|
||||
[RFC-repo]: https://github.com/PowerShell/PowerShell-RFC
|
||||
[ci-system]: ../testing-guidelines/testing-guidelines.md#ci-system
|
||||
|
||||
@ -136,7 +136,7 @@ package will instead be created.
|
||||
On macOS, create a new branch at the release tag. For example:
|
||||
``` powershell
|
||||
git checkout -b local-release-branch v6.0.0-alpha.11
|
||||
```
|
||||
```
|
||||
Then run the following commands:
|
||||
``` powershell
|
||||
Import-Module ./build.psm1
|
||||
@ -155,7 +155,7 @@ you can either run `Start-PSPackage` manually on each of the Linux distros or us
|
||||
On a supported Linux distro, Ubuntu 14.04 for instance, create a new branch at the release tag. For example:
|
||||
``` powershell
|
||||
git checkout -b local-release-branch v6.0.0-alpha.11
|
||||
```
|
||||
```
|
||||
Then run the following commands:
|
||||
``` powershell
|
||||
Import-Module ./build.psm1
|
||||
@ -211,25 +211,25 @@ The output of `Start-PSBuild` includes a `powershell.exe` executable which can s
|
||||
To create release packages, create a new branch at the release tag. For example:
|
||||
``` powershell
|
||||
git checkout -b local-release-branch v6.0.0-alpha.11
|
||||
```
|
||||
```
|
||||
|
||||
#### Windows 10 and Server 2016
|
||||
#### Windows 10 and Server 2016
|
||||
|
||||
``` powershell
|
||||
Import-Module .\build.psm1
|
||||
Start-PSBootstrap -Package
|
||||
Start-PSBuild -Clean -CrossGen -PSModuleRestore -Runtime win10-x64 -Configuration Release
|
||||
Import-Module .\build.psm1
|
||||
Start-PSBootstrap -Package
|
||||
Start-PSBuild -Clean -CrossGen -PSModuleRestore -Runtime win10-x64 -Configuration Release
|
||||
Start-PSPackage -Type msi
|
||||
Start-PSPackage -Type zip
|
||||
```
|
||||
|
||||
#### Windows 8.1 and Server 2012r2
|
||||
#### Windows 8.1 and Server 2012r2
|
||||
|
||||
``` powershell
|
||||
Import-Module .\build.psm1
|
||||
Start-PSBootstrap -Package
|
||||
Start-PSBuild -Clean -CrossGen -PSModuleRestore -Runtime win81-x64 -Configuration Release
|
||||
Start-PSPackage -Type msi -WindowsDownLevel win81-x64
|
||||
Import-Module .\build.psm1
|
||||
Start-PSBootstrap -Package
|
||||
Start-PSBuild -Clean -CrossGen -PSModuleRestore -Runtime win81-x64 -Configuration Release
|
||||
Start-PSPackage -Type msi -WindowsDownLevel win81-x64
|
||||
Start-PSPackage -Type zip -WindowsDownLevel win81-x64
|
||||
```
|
||||
|
||||
@ -243,7 +243,7 @@ git checkout -b local-release-branch v6.0.0-alpha.11
|
||||
|
||||
Run `Publish-NuGetFeed` to generate PowerShell NuGet packages:
|
||||
``` powershell
|
||||
Import-Module .\build.psm1
|
||||
Import-Module .\build.psm1
|
||||
Start-PSBootstrap -Package
|
||||
Start-PSBuild -Clean -Publish
|
||||
$VersionSuffix = ((git describe) -split '-')[-1] -replace "\."
|
||||
|
||||
@ -33,9 +33,9 @@ There are a small number of solutions available:
|
||||
* OpenCover is currently used by corefx to produce code coverage data, also visualization is available via [CoverAlls](https://coveralls.io/github/OpenCover/opencover).
|
||||
We should investigate `OpenCover` and determine it's feasibility for us.
|
||||
Unfortunately I haven't been able to find a solution for Linux
|
||||
* DotCover
|
||||
* DotCover
|
||||
* I have contacted `JetBrains` to see if they have any solutions which may be used with .NET Core.
|
||||
|
||||
|
||||
If we can get code coverage on PowerShell Core on Windows, we would at least be able to have _some_ data to illuminate our test gaps.
|
||||
|
||||
Running code coverage more often on full PowerShell is something that we should consider, if it will help us close existing test coverage gaps, but the issue is _not_ test coverage for full PowerShell, but rather PowerShell Core where we have only a small percentage of tests in comparison.
|
||||
@ -45,9 +45,9 @@ We currently run only those tests which are tagged `CI` excluding the tag `SLOW`
|
||||
This means roughly 1/3rd of our github tests are not being run on any regular schedule.
|
||||
In order to provide us with higher confidence in our code, we should be running *ALL* of our tests on a regular basis.
|
||||
We have recently added to `AppVeyor` running all of our tests on a daily basis, but are not yet running these tests on Linux/Mac via `Travis`, which should be done.
|
||||
However, running the tests is only the first step, we need an easy way to be notified of test failures, and to track progress of those runs over time.
|
||||
However, running the tests is only the first step, we need an easy way to be notified of test failures, and to track progress of those runs over time.
|
||||
Tracking this over time affords us the ability to see how our test count increases, implying an improvement in coverage.
|
||||
It also provides us mechanism whereby we can see trends in instability.
|
||||
It also provides us mechanism whereby we can see trends in instability.
|
||||
|
||||
### Pending and Skipped Tests
|
||||
We currently have approximately 300 tests which are marked either as `skipped` or `pending`.
|
||||
@ -72,7 +72,7 @@ In addition to loopback tests using both WSMan and SSH protocols, we should have
|
||||
* OSX Client -> Nano Client
|
||||
* PowerShell Core Client -> Full PowerShell Server
|
||||
* Full PowerShell Client -> PowerShell Core Server
|
||||
* Downlevel Full PowerShell Client -> PowerShell Core Server
|
||||
* Downlevel Full PowerShell Client -> PowerShell Core Server
|
||||
|
||||
### Challenges
|
||||
* On Windows, we have cmdlets to enable and disable remote access, those cmdlets do not exist on non-Windows platforms (they rely on configuration stored in the registry), nor do we support configuration for the SSH protocol.
|
||||
@ -108,7 +108,7 @@ There are a number of KPIs which we could report on:
|
||||
* Product KPIs
|
||||
* What is the usage of PowerShell Core on the various platforms
|
||||
* What are the common operations performed by PowerShell Core (cmdlet usage)
|
||||
* How many remote connections are created in a session
|
||||
* How many remote connections are created in a session
|
||||
|
||||
## Reporting Priorities
|
||||
1. As a baseline, we should report code coverage on current Full PowerShell from the latest Windows release
|
||||
@ -119,7 +119,7 @@ This is the tool that will enable us to at least determine where we have _no_ da
|
||||
### Public Dashboard
|
||||
Because we collect the test results as a build artifact, it is possible to collect and collate this data and provide a number of dash-board reports.
|
||||
Since we are an OSS project, it makes sense that our reports should be also public.
|
||||
A public dashboard provides evidence that we are not collecting PII, increasing trust in the project and shows that we are using data to drive product decisions.
|
||||
A public dashboard provides evidence that we are not collecting PII, increasing trust in the project and shows that we are using data to drive product decisions.
|
||||
We could easily create a web presence in Azure which would enable us to provide reporting on the current and historical state of our tests.
|
||||
Now that we are running all of our tests on a nightly basis, we should be communicating the results of those test runs.
|
||||
PowerBI could be used to create the visualizations, which would reduce the time and effort.
|
||||
@ -127,14 +127,14 @@ PowerBI could be used to create the visualizations, which would reduce the time
|
||||
In order to achieve this we need to:
|
||||
* Designate an Azure instance to run services and populate Azure tables:
|
||||
* Create tools to retrieve and transform git data
|
||||
* Create tools to retrieve and transform the test data
|
||||
* Create tools to retrieve and transform the test data
|
||||
* Create PowerBI queries to visualize our KPIs
|
||||
|
||||
# Release Criteria
|
||||
We must start defining the release criteria for a production ready release of PowerShell Core, as an initial proposal:
|
||||
* No open issues for the release
|
||||
* 80% code coverage of high use cmdlets (cmdlets used by 70% of users, as captured via telemetry)
|
||||
* 90% code coverage of language elements (coverage error code paths may not be 100%)
|
||||
* 90% code coverage of language elements (coverage error code paths may not be 100%)
|
||||
* 60% code Coverage on Windows via Github tests
|
||||
* 100% of our minimum remoting matrix tested
|
||||
* Acceptance by 50% PowerShell MVPs (via Survey)
|
||||
@ -179,8 +179,8 @@ Unfortunately, the current logging mechanism used in our in-lab tests are not av
|
||||
|
||||
**Proposal**
|
||||
|
||||
* Investigate the effort to run our historical tests in a PowerShell Core environment
|
||||
|
||||
* Investigate the effort to run our historical tests in a PowerShell Core environment
|
||||
|
||||
# Action Plan
|
||||
This document represents a number of initiatives, all of which will take resources.
|
||||
Below is my suggestion for prioritization to reduce risk and improve confidence in our overall quality:
|
||||
|
||||
@ -5,10 +5,10 @@ about Pester or creating tests, the [Pester Wiki](https://github.com/pester/pest
|
||||
|
||||
When creating tests, keep the following in mind:
|
||||
* Tests should not be overly complicated and test too many things
|
||||
* boil down your tests to their essence, test only what you need
|
||||
* boil down your tests to their essence, test only what you need
|
||||
* Tests should be as simple as they can
|
||||
* Tests should generally not rely on any other test
|
||||
|
||||
|
||||
Examples:
|
||||
Here's the simplest of tests
|
||||
|
||||
@ -18,7 +18,7 @@ Describe "A variable can be assigned and retrieved" {
|
||||
$a = 1
|
||||
$a | Should be 1
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If you need to do type checking, that can be done as well
|
||||
@ -33,7 +33,7 @@ Describe "One is really one" {
|
||||
$i = 1
|
||||
$i.GetType() | Should Be "int"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
alternatively, you could do the following:
|
||||
@ -48,7 +48,7 @@ Describe "One is really one" {
|
||||
$i = 1
|
||||
$i.GetType() | Should Be ([System.Int32])
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If you are checking for proper errors, do that in a `try/catch`, and then check `FullyQualifiedErrorId`. Checking against `FullyQualifiedErrorId` is recommended because it does not change based on culture as an error message might.
|
||||
@ -129,10 +129,10 @@ $testCases = @(
|
||||
)
|
||||
|
||||
Describe "A test" {
|
||||
It "<a> -xor <b> should be <expectedresult>" -testcase $testcases {
|
||||
It "<a> -xor <b> should be <expectedresult>" -testcase $testcases {
|
||||
param ($a, $b, $ExpectedResult)
|
||||
$a -xor $b | Should be $ExpectedResult
|
||||
}
|
||||
$a -xor $b | Should be $ExpectedResult
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
@ -177,10 +177,10 @@ Describe it {
|
||||
Write-Host -for DarkRed "After It"
|
||||
}
|
||||
Write-Host -for DarkRed "After Context"
|
||||
Write-Host -for DarkGreen "Before Describe BeforeAll"
|
||||
Write-Host -for DarkGreen "Before Describe BeforeAll"
|
||||
BeforeAll { Write-Host -for DarkGreen "In Describe BeforeAll" }
|
||||
AfterAll { Write-Host -for DarkGreen "In Describe AfterAll" }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Now, when run, you can see the execution schedule
|
||||
@ -206,7 +206,7 @@ After Context
|
||||
Before Describe BeforeAll
|
||||
In Describe AfterAll
|
||||
Tests completed in 79ms
|
||||
Passed: 1 Failed: 0 Skipped: 0 Pending: 0
|
||||
Passed: 1 Failed: 0 Skipped: 0 Pending: 0
|
||||
```
|
||||
|
||||
The DESCRIBE BeforeAll block is executed before any other code even though it was at the bottom of the Describe block, so if state is set elsewhere in the describe BLOCK, that state will not be visible (as the code will not yet been run). Notice, too, that the BEFOREALL block in Context is executed before any other code in that block.
|
||||
@ -241,7 +241,7 @@ Describe "Should not run these tests on non-Windows platforms" {
|
||||
2 | should be 1
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
Here is the output when run on a Linux distribution:
|
||||
```
|
||||
|
||||
@ -13,7 +13,7 @@ When adding new tests, place them in the directories as [outlined below](#test-l
|
||||
|
||||
## CI System
|
||||
|
||||
We use [AppVeyor](http://www.appveyor.com/) as a continuous integration (CI) system for Windows
|
||||
We use [AppVeyor](http://www.appveyor.com/) as a continuous integration (CI) system for Windows
|
||||
and [Travis CI](http://www.travis-ci.com) for non-Windows platforms.
|
||||
|
||||
### AppVeyor
|
||||
@ -53,7 +53,7 @@ They will bring you to the corresponding page with details.
|
||||
### Pester
|
||||
|
||||
Our script-based test framework is [Pester](https://github.com/Pester/Pester).
|
||||
This is the framework which we are using internally at Microsoft for new script-based tests,
|
||||
This is the framework which we are using internally at Microsoft for new script-based tests,
|
||||
and a large number of the tests which are part of the PowerShell project have been migrated from that test base.
|
||||
Pester tests can be used to test most of PowerShell behavior (even some API operations can easily be tested in Pester).
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user