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

Docs: Add guidelines for contributors #609

Open
wants to merge 20 commits into
base: main
Choose a base branch
from

Conversation

mattdot
Copy link
Member

@mattdot mattdot commented Mar 2, 2025

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:

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 the CONTRIBUTING.md and DEVELOPER.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 adopting httpmock 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 of httpmock 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:

    • Removed the decision log outlining the rationale for implementing loosely typed Terraform resources in decision-log/loosely_typed_resources.md.
  • New ADR Document:

    • Added a new ADR document summarizing the rationale and benefits of loosely typed Terraform resources, specifically powerplatform_data_record and powerplatform_data_records in devdocs/adr/loosely_typed_data_records.md.
  • Community Support Documentation:

    • Added a comprehensive community support document including FAQs, developer support channels, and best practices for working with maintainers in devdocs/community_support.md.
  • Observability and Logging Guidelines:

    • Introduced guidelines for observability and logging, emphasizing the use of HashiCorp’s tflog package for structured logging and the importance of not logging sensitive information in devdocs/observability_guidelines.md.

@mattdot mattdot linked an issue Mar 2, 2025 that may be closed by this pull request
19 tasks
@mattdot mattdot added skip-changelog documentation Improvements or additions to documentation developer experience labels Mar 2, 2025
@mattdot mattdot self-assigned this Mar 2, 2025
@mattdot mattdot marked this pull request as ready for review March 3, 2025 07:56
Copy link
Contributor

@ianjensenisme ianjensenisme left a 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.
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Contributor

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>

### 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.
Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Member Author

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.
Copy link
Contributor

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.

mawasile
mawasile previously approved these changes Mar 5, 2025
Copy link
Contributor

@eduardodfmex eduardodfmex left a 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.


### 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.
Copy link
Contributor

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.

github-actions[bot] added 2 commits March 6, 2025 02:41
mattdot and others added 10 commits March 5, 2025 23:45
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer experience documentation Improvements or additions to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Developer documentation improvements
4 participants