Azure Testing Framework/Library project
Перейти к файлу
marclerwick b47a0205dd
#159 Refactor file structure
* Initial commit with all but one unit test functioning correctly.
Confirm-Resource.Tests.ps1 is failing due to "Unable to find type [ResourceType]", which makes no sense, since Get-ResourceByType uses the same enum, but the unit tests pass without issue.

* Merged examples into grouped folders.
Removed modules from the psd1.

* Added a build script that can be used both during development and to build the final .psm1 for publishing to PS Gallery.

* Minor code cleanup.

* Updating CI/CD workflows.

* Updated the installation and contributing docs.

* Moved pr-psgallery.yml workflow into ci.yml. Now that there is a "build" process for the module this should happen in the CI pipeline and not the PR pipeline.

* Fixing working directory for unit tests.

* Swapped out relative paths for the PS Gallery module name in the examples, because the relative path will no longer work without building the module.

* Moved the ci-publish-docs-branch.yml into the ci.yml. It made sense logically once I tried rewriting it after the refactor.

* Fixing broken reference in the 'ci_cd_workflows.md' file.

* Minor update to 'ci_cd_workflows.md'

* I honestly couldn't figure out why `ResourceType` was not able to be found. I tried every which way of `using`/`Import`ing/dot sourcing that can be imagined. I think that this is a fundamental issue with PowerShell. The more I researched the more I found about enums and classes not being available from nested modules. I'm not sure why the classes work and enums do not though.

* Fixing broken unit test's reference to `ResourceType.psm1`.
2023-02-28 16:32:31 -08:00
.devcontainer #123 Introduce semantic versioning to CD workflow (#125) 2023-01-30 16:35:20 -08:00
.github #159 Refactor file structure 2023-02-28 16:32:31 -08:00
.vscode Mega Linter Migration (#127) 2023-01-27 13:20:36 -08:00
BenchPress #159 Refactor file structure 2023-02-28 16:32:31 -08:00
Modules/BenchPress.Azure #159 Refactor file structure 2023-02-28 16:32:31 -08:00
docs #159 Refactor file structure 2023-02-28 16:32:31 -08:00
examples #159 Refactor file structure 2023-02-28 16:32:31 -08:00
.editorconfig adding common config for code editors 2022-08-16 04:29:16 +00:00
.gitignore init 2023-02-14 14:44:24 -08:00
.gitmodules Mega Linter Migration (#127) 2023-01-27 13:20:36 -08:00
.mega-linter.yml Introduce actionlint and resolve errors (#143) 2023-02-06 10:07:40 -08:00
.npmpackagejsonlintignore Fixing Bicep.psm1 to replace the unicode elipsis. (#138) 2023-02-03 10:07:42 -08:00
CHANGELOG.md Create YAML files to represent PR workflow (#94) 2023-01-13 16:33:57 -08:00
CODE_OF_CONDUCT.md Create YAML files to represent PR workflow (#94) 2023-01-13 16:33:57 -08:00
CONTRIBUTING.md #159 Refactor file structure 2023-02-28 16:32:31 -08:00
LICENSE LICENSE committed 2022-04-22 15:57:07 -07:00
README.md Getting Started Documentation (#118) 2023-01-24 10:32:47 -08:00
ROADMAP.md Mega Linter Migration (#127) 2023-01-27 13:20:36 -08:00
SECURITY.md Create YAML files to represent PR workflow (#94) 2023-01-13 16:33:57 -08:00
SUPPORT.md Create YAML files to represent PR workflow (#94) 2023-01-13 16:33:57 -08:00
bicepconfig.json Mega Linter Migration (#127) 2023-01-27 13:20:36 -08:00
build.ps1 #159 Refactor file structure 2023-02-28 16:32:31 -08:00

README.md

BenchPress

BenchPress is intended to work as a testing framework for Azure deployment features by using Bicep.

Process is the following:

flowchart LR

A[Creation] -->|Bicep| B[Verification]
B --> C[Remove]
  • Creation: New resources are deployed through Bicep files
  • Verification: Test is going to confirm the resource exists and also assert if it matches the expected value
  • Remove: Optionally, resources can be removed after being tested

Please see the following for more info:

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.