-
Notifications
You must be signed in to change notification settings - Fork 14
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
Docs: Add guidelines for contributors #609
base: main
Are you sure you want to change the base?
Conversation
…d streamline contribution process
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor updates requested
|
||
## Naming Attributes | ||
|
||
Attribute naming should closely mirror terminology used by the Power Platform API or the Power Platform Admin Center UI. When discrepancies exist due to feature renaming or updates, choose the modern, user-recognizable term. For instance, prefer Dataverse instead of older, deprecated terminology like CDS to ensure users familiar with current platform features easily understand the schema. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"modern" and "user-recognizable" are sometimes contradictory. Example: Our Managed Identity references should really be abbreviated "MI" (matching the modern name), but the "user-recognizable" naming could be "MSI". Do we have any guidance to tip the scale in a conflict? In the above example we went with user-recognizable, but I wonder if it's always that clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
l think it's a judgement call at that point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess what I'm getting at is that what we're really doing is going with what we see in other providers, even if it's antiquated terminology. Maybe add a note to that effect: "when in doubt, look at what other providers have done"
Co-authored-by: Ian Jensen <94021216+ianjensenisme@users.noreply.github.com>
devdocs/community_support.md
Outdated
|
||
### Q: Can I develop on this provider without using the VS Code Dev Container? | ||
|
||
**A:** It's not recommended to develop this provider outside the provided Dev Container. GitHub Codespaces is the preferred environment due to consistency, controlled dependencies, and reproducibility. Using the Dev Container locally is acceptable, but manually setting up a local environment can introduce risks such as mismatched dependencies, version conflicts, and environmental inconsistencies that could complicate development and troubleshooting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i disagree with that sentence, technically local container is the same thing. Its just ootb git integration are missing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I try the local dev container and doesn't work, I will create one Issues to make it work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the last part of the sentence is supposed to be about not using the devcontainer. It says devcontainer locally is fine.
- **SingleNested Blocks:** Used for singular configurations, such as Dataverse settings within the `powerplatform_environment` resource, grouping attributes like `language_code`, `currency_code`, and `security_group_id`. | ||
- **SetNested or ListNested Blocks:** Used for repeatable structures, such as multiple connector references or multiple similar configurations. | ||
|
||
Avoid overly deep nesting. Clearly represent resource or data source structure without unnecessary complexity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would add more info about judgment, how to structure a new resource. Right now if something has a complex structure like for example env settings, we try to follow the ppac UI in our schema.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for creating and extending the documentation..!
I add a couple of suggestions.
devdocs/community_support.md
Outdated
|
||
### Q: Can I develop on this provider without using the VS Code Dev Container? | ||
|
||
**A:** It's not recommended to develop this provider outside the provided Dev Container. GitHub Codespaces is the preferred environment due to consistency, controlled dependencies, and reproducibility. Using the Dev Container locally is acceptable, but manually setting up a local environment can introduce risks such as mismatched dependencies, version conflicts, and environmental inconsistencies that could complicate development and troubleshooting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I try the local dev container and doesn't work, I will create one Issues to make it work.
…ules for resources and data sources
…nd streamlining instructions
Co-authored-by: mawasile <50197777+mawasile@users.noreply.github.com>
Co-authored-by: mawasile <50197777+mawasile@users.noreply.github.com>
Co-authored-by: Eduardo Sanchez <eduardodfmex@hotmail.com>
Co-authored-by: Eduardo Sanchez <eduardodfmex@hotmail.com>
…thub.com/microsoft/terraform-provider-power-platform into 608-developer-documentation-improvements
This pull request includes updates to the documentation and developer guidelines for the Terraform Provider for Power Platform. The changes aim to provide clearer instructions for contributors and improve the overall structure of the documentation. The most important changes include adding a dynamic configuration guide, enhancing the contribution guidelines, and reorganizing developer resources.
Documentation updates:
.changes/unreleased/documentation-20250303-071315.yaml
: Added a dynamic configuration guide to the user documentation.CONTRIBUTING.md
: Reorganized and expanded the contribution guidelines, including a new section on examples and clarifying the process for contributing new resources and data sources.Developer guidelines:
DEVELOPER.md
: Reorganized the developer documentation, added a summary of developer resources, and detailed the developer workflow, including setting up development environments using GitHub Codespaces or local devcontainers.DEVELOPER.md
: Updated the section on testing guidelines to provide detailed instructions on writing unit and acceptance tests, and the importance of comprehensive test coverage.This pull request to the Terraform Provider for Power Platform repository includes significant updates to theCONTRIBUTING.md
andDEVELOPER.md
files, as well as the addition of new documentation files. The changes aim to improve the contribution guidelines, developer setup instructions, and testing practices. The most important changes include restructuring the contribution types, enhancing developer resource documentation, and adoptinghttpmock
for unit testing.Contribution Guidelines and Examples:
CONTRIBUTING.md
: Restructured the contribution types section to clarify the difficulty levels of different contributions and added detailed examples for contributing to the Power Platform Terraform Provider.Developer Setup and Resources:
DEVELOPER.md
: Enhanced the documentation by adding a comprehensive summary of developer resources, including guidelines for testing, security, schema design, and community support. Introduced two recommended development environment options: GitHub Codespaces and Local Devcontainer.DEVELOPER.md
: Provided detailed instructions for setting up and configuring Git credentials in both GitHub Codespaces and Local Devcontainer environments.Decision Logs and Testing:
decision-log/loosely_typed_resources.md
: Removed the decision log for loosely typed resources, which outlined the rationale and comparison between strongly typed and loosely typed resources in the Terraform Provider for Power Platform.devdocs/adr/httpmocks.md
: Added a new ADR document detailing the adoption ofhttpmock
for HTTP request mocking in unit tests, highlighting the benefits and implementation guidelines for improved test reliability and determinism.This pull request includes several documentation updates and additions to improve clarity and support for developers and users of the Terraform Provider for Power Platform. The most important changes are summarized below:Documentation Updates:
Decision Log Removal:
decision-log/loosely_typed_resources.md
.New ADR Document:
powerplatform_data_record
andpowerplatform_data_records
indevdocs/adr/loosely_typed_data_records.md
.Community Support Documentation:
devdocs/community_support.md
.Observability and Logging Guidelines:
tflog
package for structured logging and the importance of not logging sensitive information indevdocs/observability_guidelines.md
.