Skip to content

Commit

Permalink
CodeGen from PR 31553 in Azure/azure-rest-api-specs
Browse files Browse the repository at this point in the history
Merge 0c8cdeb19669766f40a3955abe2807fd979b6a41 into fb64eaa0dfc7ee8abc8e10369495729d5b3c1cc5
  • Loading branch information
SDKAuto committed Nov 15, 2024
1 parent 55251fe commit 7986f7f
Show file tree
Hide file tree
Showing 13 changed files with 246 additions and 0 deletions.
1 change: 1 addition & 0 deletions swaggerci/hybridcompute.DefaultTag/.gitattributes
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
* text=auto
18 changes: 18 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,18 @@
bin
obj
.vs
generated
internal
exports
tools
custom/*.psm1
custom/autogen-model-cmdlets
test/*-TestResults.xml
license.txt
/*.ps1
/*.psd1
/*.ps1xml
/*.psm1
/*.snk
/*.csproj
/*.nuspec
24 changes: 24 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
<!-- region Generated -->
# Az.HybridCompute
This directory contains the PowerShell module for the HybridCompute service.

---
## Info
- Modifiable: yes
- Generated: all
- Committed: yes
- Packaged: yes

---
## Detail
This module was primarily generated via [AutoRest](https://github.com/Azure/autorest) using the [PowerShell](https://github.com/Azure/autorest.powershell) extension.

## Module Requirements
- [Az.Accounts module](https://www.powershellgallery.com/packages/Az.Accounts/), version 2.7.5 or greater

## Authentication
AutoRest does not generate authentication code for the module. Authentication is handled via Az.Accounts by altering the HTTP payload before it is sent.

## Development
For information on how to develop for `Az.HybridCompute`, see [how-to.md](how-to.md).
<!-- endregion -->
41 changes: 41 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/custom/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
# Custom
This directory contains custom implementation for non-generated cmdlets for the `Az.HybridCompute` module. Both scripts (`.ps1`) and C# files (`.cs`) can be implemented here. They will be used during the build process in `build-module.ps1`, and create cmdlets into the `../exports` folder. The only generated file into this folder is the `Az.HybridCompute.custom.psm1`. This file should not be modified.

## Info
- Modifiable: yes
- Generated: partial
- Committed: yes
- Packaged: yes

## Details
For `Az.HybridCompute` to use custom cmdlets, it does this two different ways. We **highly recommend** creating script cmdlets, as they are easier to write and allow access to the other exported cmdlets. C# cmdlets *cannot access exported cmdlets*.

For C# cmdlets, they are compiled with the rest of the generated low-level cmdlets into the `./bin/Az.HybridCompute.private.dll`. The names of the cmdlets (methods) and files must follow the `[cmdletName]_[variantName]` syntax used for generated cmdlets. The `variantName` is used as the `ParameterSetName`, so use something appropriate that doesn't clash with already created variant or parameter set names. You cannot use the `ParameterSetName` property in the `Parameter` attribute on C# cmdlets. Each cmdlet must be separated into variants using the same pattern as seen in the `generated/cmdlets` folder.

For script cmdlets, these are loaded via the `Az.HybridCompute.custom.psm1`. Then, during the build process, this module is loaded and processed in the same manner as the C# cmdlets. The fundamental difference is the script cmdlets use the `ParameterSetName` attribute and C# cmdlets do not. To create a script cmdlet variant of a generated cmdlet, simply decorate all parameters in the script with the new `ParameterSetName` in the `Parameter` attribute. This will appropriately treat each parameter set as a separate variant when processed to be exported during the build.

## Purpose
This allows the modules to have cmdlets that were not defined in the REST specification. It also allows combining logic using generated cmdlets. This is a level of customization beyond what can be done using the [readme configuration options](https://github.com/Azure/autorest/blob/master/docs/powershell/options.md) that are currently available. These custom cmdlets are then referenced by the cmdlets created at build-time in the `../exports` folder.

## Usage
The easiest way currently to start developing custom cmdlets is to copy an existing cmdlet. For C# cmdlets, copy one from the `generated/cmdlets` folder. For script cmdlets, build the project using `build-module.ps1` and copy one of the scripts from the `../exports` folder. After that, if you want to add new parameter sets, follow the guidelines in the `Details` section above. For implementing a new cmdlets, at minimum, please keep these parameters:
- Break
- DefaultProfile
- HttpPipelineAppend
- HttpPipelinePrepend
- Proxy
- ProxyCredential
- ProxyUseDefaultCredentials

These provide functionality to our HTTP pipeline and other useful features. In script, you can forward these parameters using `$PSBoundParameters` to the other cmdlets you're calling within `Az.HybridCompute`. For C#, follow the usage seen in the `ProcessRecordAsync` method.

### Attributes
For processing the cmdlets, we've created some additional attributes:
- `Microsoft.Azure.PowerShell.Cmdlets.HybridCompute.DescriptionAttribute`
- Used in C# cmdlets to provide a high-level description of the cmdlet. This is propagated to reference documentation via [help comments](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_comment_based_help) in the exported scripts.
- `Microsoft.Azure.PowerShell.Cmdlets.HybridCompute.DoNotExportAttribute`
- Used in C# and script cmdlets to suppress creating an exported cmdlet at build-time. These cmdlets will *not be exposed* by `Az.HybridCompute`.
- `Microsoft.Azure.PowerShell.Cmdlets.HybridCompute.InternalExportAttribute`
- Used in C# cmdlets to route exported cmdlets to the `../internal`, which are *not exposed* by `Az.HybridCompute`. For more information, see [README.md](../internal/README.md) in the `../internal` folder.
- `Microsoft.Azure.PowerShell.Cmdlets.HybridCompute.ProfileAttribute`
- Used in C# and script cmdlets to define which Azure profiles the cmdlet supports. This is only supported for Azure (`--azure`) modules.
11 changes: 11 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/docs/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Docs
This directory contains the documentation of the cmdlets for the `Az.HybridCompute` module. To run documentation generation, use the `generate-help.ps1` script at the root module folder. Files in this folder will *always be overridden on regeneration*. To update documentation examples, please use the `../examples` folder.

## Info
- Modifiable: no
- Generated: all
- Committed: yes
- Packaged: yes

## Details
The process of documentation generation loads `Az.HybridCompute` and analyzes the exported cmdlets from the module. It recognizes the [help comments](https://learn.microsoft.com/powershell/module/microsoft.powershell.core/about/about_comment_based_help) that are generated into the scripts in the `../exports` folder. Additionally, when writing custom cmdlets in the `../custom` folder, you can use the help comments syntax, which decorate the exported scripts at build-time. The documentation examples are taken from the `../examples` folder.
11 changes: 11 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/examples/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Examples
This directory contains examples from the exported cmdlets of the module. When `build-module.ps1` is ran, example stub files will be generated here. If your module support Azure Profiles, the example stubs will be in individual profile folders. These example stubs should be updated to show how the cmdlet is used. The examples are imported into the documentation when `generate-help.ps1` is ran.

## Info
- Modifiable: yes
- Generated: partial
- Committed: yes
- Packaged: no

## Purpose
This separates the example documentation details from the generated documentation information provided directly from the generated cmdlets. Since the cmdlets don't have examples from the REST spec, this provides a means to add examples easily. The example stubs provide the markdown format that is required. The 3 core elements are: the name of the example, the code information of the example, and the description of the example. That information, if the markdown format is followed, will be available to documentation generation and be part of the documents in the `../docs` folder.
58 changes: 58 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/how-to.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# How-To
This document describes how to develop for `Az.HybridCompute`.

## Building `Az.HybridCompute`
To build, run the `build-module.ps1` at the root of the module directory. This will generate the proxy script cmdlets that are the cmdlets being exported by this module. After the build completes, the proxy script cmdlets will be output to the `exports` folder. To read more about the proxy script cmdlets, look at the [README.md](exports/README.md) in the `exports` folder.

## Creating custom cmdlets
To add cmdlets that were not generated by the REST specification, use the `custom` folder. This folder allows you to add handwritten `.ps1` and `.cs` files. Currently, we support using `.ps1` scripts as new cmdlets or as additional low-level variants (via `ParameterSet`), and `.cs` files as low-level (variants) cmdlets that the exported script cmdlets call. We do not support exporting any `.cs` (dll) cmdlets directly. To read more about custom cmdlets, look at the [README.md](custom/README.md) in the `custom` folder.

## Generating documentation
To generate documentation, the process is now integrated into the `build-module.ps1` script. If you don't want to run this process as part of `build-module.ps1`, you can provide the `-NoDocs` switch. If you want to run documentation generation after the build process, you may still run the `generate-help.ps1` script. Overall, the process will look at the documentation comments in the generated and custom cmdlets and types, and create `.md` files into the `docs` folder. Additionally, this pulls in any examples from the `examples` folder and adds them to the generated help markdown documents. To read more about examples, look at the [README.md](examples/README.md) in the `examples` folder. To read more about documentation, look at the [README.md](docs/README.md) in the `docs` folder.

## Testing `Az.HybridCompute`
To test the cmdlets, we use [Pester](https://github.com/pester/Pester). Tests scripts (`.ps1`) should be added to the `test` folder. To execute the Pester tests, run the `test-module.ps1` script. This will run all tests in `playback` mode within the `test` folder. To read more about testing cmdlets, look at the [README.md](examples/README.md) in the `examples` folder.

## Packing `Az.HybridCompute`
To pack `Az.HybridCompute` for distribution, run the `pack-module.ps1` script. This will take the contents of multiple directories and certain root-folder files to create a `.nupkg`. The structure of the `.nupkg` is created so it can be loaded part of a [PSRepository](https://learn.microsoft.com/powershell/module/powershellget/register-psrepository). Additionally, this package is in a format for distribution to the [PSGallery](https://www.powershellgallery.com/). For signing an Azure module, please contact the [Azure PowerShell](https://github.com/Azure/azure-powershell) team.

## Module Script Details
There are multiple scripts created for performing different actions for developing `Az.HybridCompute`.
- `build-module.ps1`
- Builds the module DLL (`./bin/Az.HybridCompute.private.dll`), creates the exported cmdlets and documentation, generates custom cmdlet test stubs and exported cmdlet example stubs, and updates `./Az.HybridCompute.psd1` with Azure profile information.
- **Parameters**: [`Switch` parameters]
- `-Run`: After building, creates an isolated PowerShell session and loads `Az.HybridCompute`.
- `-Test`: After building, runs the `Pester` tests defined in the `test` folder.
- `-Docs`: After building, generates the Markdown documents for the modules into the `docs` folder.
- `-Pack`: After building, packages the module into a `.nupkg`.
- `-Code`: After building, opens a VSCode window with the module's directory and runs (see `-Run`) the module.
- `-Release`: Builds the module in `Release` configuration (as opposed to `Debug` configuration).
- `-NoDocs`: Supresses writing the documentation markdown files as part of the cmdlet exporting process.
- `-Debugger`: Used when attaching the debugger in Visual Studio to the PowerShell session, and running the build process without recompiling the DLL. This suppresses running the script as an isolated process.
- `run-module.ps1`
- Creates an isolated PowerShell session and loads `Az.HybridCompute` into the session.
- Same as `-Run` in `build-module.ps1`.
- **Parameters**: [`Switch` parameters]
- `-Code`: Opens a VSCode window with the module's directory.
- Same as `-Code` in `build-module.ps1`.
- `generate-help.ps1`
- Generates the Markdown documents for the modules into the `docs` folder.
- Same as `-Docs` in `build-module.ps1`.
- `test-module.ps1`
- Runs the `Pester` tests defined in the `test` folder.
- Same as `-Test` in `build-module.ps1`.
- `pack-module.ps1`
- Packages the module into a `.nupkg` for distribution.
- Same as `-Pack` in `build-module.ps1`.
- `generate-help.ps1`
- Generates the Markdown documents for the modules into the `docs` folder.
- Same as `-Docs` in `build-module.ps1`.
- This process is now integrated into `build-module.ps1` automatically. To disable, use `-NoDocs` when running `build-module.ps1`.
- `export-surface.ps1`
- Generates Markdown documents for both the cmdlet surface and the model (class) surface of the module.
- These files are placed into the `resources` folder.
- Used for investigating the surface of your module. These are *not* documentation for distribution.
- `check-dependencies.ps1`
- Used in `run-module.ps1` and `test-module.ps1` to verify dependent modules are available to run those tasks.
- It will download local (within the module's directory structure) versions of those modules as needed.
- This script *does not* need to be ran by-hand.
10 changes: 10 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/readme.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
### AutoRest Configuration
> see https://aka.ms/autorest
``` yaml
require:
- $(this-folder)/../../tools/SwaggerCI/readme.azure.noprofile.md
- $(this-folder)/../../../azure-rest-api-specs/specification/hybridcompute/resource-manager/readme.md
try-require:
- $(this-folder)/../../../azure-rest-api-specs/specification/hybridcompute/resource-manager/readme.powershell.md
```
11 changes: 11 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/resources/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
# Resources
This directory can contain any additional resources for module that are not required at runtime. This directory **does not** get packaged with the module. If you have assets for custom implementation, place them into the `../custom` folder.

## Info
- Modifiable: yes
- Generated: no
- Committed: yes
- Packaged: no

## Purpose
Use this folder to put anything you want to keep around as part of the repository for the module, but is not something that is required for the module. For example, development files, packaged builds, or additional information. This is only intended to be used in repositories where the module's output directory is cleaned, but tangential resources for the module want to remain intact.
17 changes: 17 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/test/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
# Test
This directory contains the [Pester](https://www.powershellgallery.com/packages/Pester) tests to run for the module. We use Pester as it is the unofficial standard for PowerShell unit testing. Test stubs for custom cmdlets (created in `../custom`) will be generated into this folder when `build-module.ps1` is ran. These test stubs will fail automatically, to indicate that tests should be written for custom cmdlets.

## Info
- Modifiable: yes
- Generated: partial
- Committed: yes
- Packaged: no

## Details
We allow three testing modes: *live*, *record*, and *playback*. These can be selected using the `-Live`, `-Record`, and `-Playback` switches respectively on the `test-module.ps1` script. This script will run through any `.Tests.ps1` scripts in the `test` folder. If you choose the *record* mode, it will create a `.Recording.json` file of the REST calls between the client and server. Then, when you choose *playback* mode, it will use the `.Recording.json` file to mock the communication between server and client. The *live* mode runs the same as the *record* mode; however, it doesn't create the `.Recording.json` file.

## Purpose
Custom cmdlets generally encompass additional functionality not described in the REST specification, or combines functionality generated from the REST spec. To validate this functionality continues to operate as intended, creating tests that can be ran and re-ran against custom cmdlets is part of the framework.

## Usage
To execute tests, run the `test-module.ps1`. To write tests, [this example](https://github.com/pester/Pester/blob/8b9cf4248315e44f1ac6673be149f7e0d7f10466/Examples/Planets/Get-Planet.Tests.ps1#L1) from the Pester repository is very useful for getting started.
21 changes: 21 additions & 0 deletions swaggerci/hybridcompute.DefaultTag/test/loadEnv.ps1
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# ----------------------------------------------------------------------------------
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See License.txt in the project root for license information.
# Code generated by Microsoft (R) AutoRest Code Generator.
# Changes may cause incorrect behavior and will be lost if the code is regenerated.
# ----------------------------------------------------------------------------------
$envFile = 'env.json'
if ($TestMode -eq 'live') {
$envFile = 'localEnv.json'
}

if (Test-Path -Path (Join-Path $PSScriptRoot $envFile)) {
$envFilePath = Join-Path $PSScriptRoot $envFile
} else {
$envFilePath = Join-Path $PSScriptRoot '..\$envFile'
}
$env = @{}
if (Test-Path -Path $envFilePath) {
$env = Get-Content (Join-Path $PSScriptRoot $envFile) | ConvertFrom-Json
$PSDefaultParameterValues=@{"*:Tenant"=$env.Tenant}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
param()
if ($env:AzPSAutorestTestPlaybackMode) {
$loadEnvPath = Join-Path $PSScriptRoot '..' 'test' 'loadEnv.ps1'
. ($loadEnvPath)
return $env.SubscriptionId
}
return (Get-AzContext).Subscription.Id
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
#This script converts securestring to plaintext

param(
[Parameter(Mandatory, ValueFromPipeline)]
[System.Security.SecureString]
${SecureString}
)

$ssPtr = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($SecureString)
try {
$plaintext = [System.Runtime.InteropServices.Marshal]::PtrToStringBSTR($ssPtr)
} finally {
[System.Runtime.InteropServices.Marshal]::ZeroFreeBSTR($ssPtr)
}

return $plaintext

0 comments on commit 7986f7f

Please sign in to comment.