Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Wiki] Updated docs recommendations & structure #2565

Merged
merged 4 commits into from
Jan 13, 2023

Conversation

AlexanderSehr
Copy link
Contributor

@AlexanderSehr AlexanderSehr commented Jan 13, 2023

Description

  • Expanded on the recommendations for deploy.test.bicep & dependencies.bicep files

Type of Change

Please delete options that are not relevant.

  • Bugfix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Update to documentation

@AlexanderSehr AlexanderSehr self-assigned this Jan 13, 2023
@AlexanderSehr AlexanderSehr requested a review from a team as a code owner January 13, 2023 14:35
@AlexanderSehr AlexanderSehr linked an issue Jan 13, 2023 that may be closed by this pull request
@AlexanderSehr AlexanderSehr added documentation Improvements or additions to documentation enhancement New feature or request labels Jan 13, 2023
@AlexanderSehr AlexanderSehr enabled auto-merge (squash) January 13, 2023 14:44
Copy link
Contributor

@ChrisSidebotham ChrisSidebotham left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AlexanderSehr AlexanderSehr merged commit 8edc3fb into main Jan 13, 2023
@AlexanderSehr AlexanderSehr deleted the users/alsehr/2416_docs branch January 13, 2023 14:49
@@ -562,17 +562,26 @@ Module test files follow these general guidelines:
- A module should have as many module test files as it needs to evaluate all parts of the module's functionality.
- Sensitive data should not be stored inside the module test file but rather be injected by the use of tokens, as described in the [Token replacement](./The%20CI%20environment%20-%20Token%20replacement) section, or via a [Key Vault reference](https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/key-vault-parameter?tabs=azure-cli#reference-secrets-with-static-id).

In addition, they follow these file-type-specific guidelines:
Test folder guidelines:

- Each scenario should be setup in its own sub-folder (e.g. `.test/linux`)
- Sub-folder names should ideally relate to the content they deploy. For example, a sub-folder `min` should be chosen for a scenario in which only the minimum set of parameters are used to deploy the module.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- Sub-folder names should ideally relate to the content they deploy. For example, a sub-folder `min` should be chosen for a scenario in which only the minimum set of parameters are used to deploy the module.
- Sub-folder names should ideally relate to the content they deploy. For example, a sub-folder `min` should be chosen for a scenario in which only the minimum set of parameters, i.e., only required parameters, are used to deploy the module.

- Each file should define a parameter `serviceShort`. This parameter should be unique to this file (i.e, no two test files should share the same) as it is injected into all resource deployments, making them unique too and account for corresponding requirements. As a reference you can create a identifier by combining a substring of the resource type and test scenario (e.g., in case of a Linux Virtual Machine Deployment: `vmlin`)
- Each file should define a parameter `serviceShort`. This parameter should be unique to this file (i.e, no two test files should share the same) as it is injected into all resource deployments, making them unique too and account for corresponding requirements.
- As a reference you can create a identifier by combining a substring of the resource type and test scenario (e.g., in case of a Linux Virtual Machine Deployment: `vmlin`).
- For the substring we recommend to take the first character any and upper-case character from the resource type identifier amd combine them to one string. Following you can find a few examples for reference:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- For the substring we recommend to take the first character any and upper-case character from the resource type identifier amd combine them to one string. Following you can find a few examples for reference:
- For the substring, we recommend to take the first character and subsequent upper-case characters from the resource type identifier and combine them into one string. Following you can find a few examples for reference:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document the convention for the serviceShort value generation
3 participants