Make PowerShell Core reads group policy settings from different registry keys (Windows only) and the configuration files (both Windows and Unix).
- On Windows, move to different GPO registry keys.
- On both Windows and Unix, read GPO related settings from the configuration file `powershell.config.json`.
- On Windows, the policy settings in registry take precedence over the configuration file.
- Enable policy controlled logging and transcription on Unix.
Create the module 'releaseTools.psm1' under 'tools' folder, which expose the function 'Get-ChangeLog' to generate a release change log based on the local commit history.
Note: changes in tools/appveyor.psm1 are not moved to the 6.0.0 branch because:
- the change is to produce win-arm32/win-arm64 zip packages in daily builds.
Since we don't have daily build for the 6.0.0 branch, the change is not needed.
- there are conflicts when cherry-picking the commits
The Linux release build was broken because AppImage,tar,tar-arm in build.json is turned into a string of "AppImage,tar,tar-arm" by docker run. Now it's changed to use switch parameters.
Create linux-arm tarball package in our release build.
Also moved the Linux-x64 tarball creation to Ubutntu 14.04, because Start-PSBuild adds additional symbolic link files when running on Red Hat Family distros.
Note that linux-arm can only be built on Ubuntu, so the tar-arm package will also be generated from the Ubuntu 14.04.
* Disambiguate icon for daily builds on Windows.
Some code had to be borrowed from build.psm1 because this script has to be self contained in case it gets executed by only downloading this file via the published download link https://twitter.com/Steve_MSFT/status/930585082451992576
* add template xml for package signing
* Add script to generate package signing XML
* remove uploading artifact, it always fails.
* Allow the XML to be updated to be specified
1. Remove `[validate]` attribute from parameter so this script can be invoked directly from the web. This doesn't have any negative impact as the $Destination parameter will have a default value if null or empty.
2. Move removal of destination folder later as installing the package requires package management module and archive module (on Windows)
3. On Windows, because files have open handles when run from existing powershell-daily install, I rename the existing files and copy over the new ones. User needs to exit and restart `pwsh` to take effect (similar to macOS/Linux where you have to exit and restart anyways)
* Add two files that need to be signed
* make sure to set PSModuleRestore to true when expanding a signed build because we run PSModuleRestore at that point.
* suppress output of CmdLets which are noisy
- Include a serialized version of PSOptions in an includesymbols zip
- Add a function which will create a zip package from the expanded includesymbols zip and a folder of signed files
- Add a function to restore an includesymbols zip as a build and populated PSOptions with the options
Enhance 'install-powershell.ps1' to work on Linux and macOS too. A user can install release version or daily powershell core on Linux and macOS.
When `-AddToPath` is specified:
- On Windows, add the absolute destination path to the 'User' scope environment variable 'Path';
- On Linux, make the symlink '/usr/bin/pwsh' points to "$Destination/pwsh";
- On MacOS, make the symlink '/usr/local/bin/pwsh' points to "$Destination/pwsh".
- Support '[package]' tag in PR CI to validate packaging changes in PR CI runs.
When using '[package]' tag, regular CI tests will run and packaging steps will also run.
- Fix nightly build on macOS.
- Add install-powershell.ps1 to install powershell core packages on windows.
- Update Start-PSBootStrap to check and install the latest PSCore package on Windows.
- Build PowerShell.Core.Instrumentation.dll - Resource-only binary for the ETW resources.
- Create a registration script for registering/unregistering the ETW provider.
This PR is divided into the following areas:
1. Add/Rename the PowerShell/Windows ETW manifest to the repo and change both the provider id (guid) and name. See #4939.
The manifest is at tools/resxgen/PowerShell-Core-Instrumentation.man
2. Generate a resx file containing the string resources needed for logging ETW events to syslog.
This is accomplished by tools\resxgen\resxgen.psm1 and resxgen.ps1. The tool generates two files
A resx file containing string resources for each message string from the manifest. This is generated in the System.Management.Automation\gen directory.
A C# class (EventResource) that provides the mapping between the integer event id and the associated string resource name. The file is generated in the System.Management.Automation\CoreCLR directory with a compile-time condition of UNIX
NOTE: The EventResource.cs class generated by resgen is explicitly ignored in the csproj file; it is not used.
3. SMA\utils\tracing\PSSysLogProvider.cs
Implements the abstract LogProvider class and is the syslog equivalent of PSEtwLogProvider. The class contains a number of logical methods for logging lifecycle, health, and normal events.
4. SMA\utils\tracing\SysLogProvider.cs
This is the Syslog equivalent of ETW's log provider class and implements a Log method versus ETW's EventWrite. It is also responsible for resolving event ids to resource names and performing the Syslog call. There is a large comment block in the class XML doc that describes the types of log output it produces.
5. SMA\utils\tracing\PSEtwLog.cs
PowerShell's current implementation is tightly coupled to this class; with code calling it directly for all events. To simplify integration of syslog, I updated the class to create an instance of PSSysLogProvider on Linux and removed the Linux-specific stub file.
6. SMA\engine\PropertyAccessor.cs
This class provides a wrapper around PowerShellProperties.json and has been extended to have Unix-specific assessors for configuring logging. Note that the file is expected to be in the $PSHOME directory to ensure SxS.
Currently, there are four configuration properties:
- LogIdentity - the string identifier for the source application. This defaults to 'powershell' and can be configured to enable distinguishing between side-by-side installations.
- LogLevel - configures the tracing level (log level). Informational is the defauilt.
- LogChannels - used to enable operational and analytic logging. Operational is the default.
- LogKeywords - used to configure enabling tracing by keyword. All keywords other than `UseAlwaysAnalytic` are enabled by default.
NOTE: This will likely change. PowerShell sometimes confuses the analytic channel with this keyword and sends logging to the wrong channel. Once this is cleared up, `UseAlwaysAnalytic` and `UseAlwaysOperational` keywords will likely be removed.
Additional Notes:
1. The current implementation writes directly to syslog and writing to a separate log file is still pending.
2. The generated class and resx are not part of the build; instead, it is expected that Resxgen should be run when events are added to the manifest. To fully automate the process, resxgen will need to be updated to generate the other dependent enums such as 'PSChannel', 'PSEventId', 'PSTask', 'PSOpcode', etc. You will see parsing logic in resxgen.psm1 to prepare for that but it is not enabled at this point.
4. Documentation is pending that documents the format of the syslog output as well as associated configuration.
5. As mentioned at the start, tests are pending
- Update `installpsh-suse.sh` to work with the .tar.gz binary archive.
- Remove `download.sh` as it's not used anywhere now. (checked with PowerShellGet and OneGet, they are using a local copy of download.sh).
small fixes found while doing current work item
-replace expects a regex when I wanted to do a literal replace.
Have Sync-PSTags fix any issues it find
