You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/dependabot.yml
+30-1Lines changed: 30 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,36 @@ updates:
10
10
schedule:
11
11
interval: "daily"
12
12
- package-ecosystem: "terraform"# See documentation for possible values
13
-
directory: "/examples"# Location of package manifests
13
+
directories: # Location of terraform modules
14
+
# Workaround for not having glob support yet. Uncommment globs and remove individual paths when available. https://github.blog/changelog/2024-04-29-dependabot-multi-directory-configuration-public-beta-now-available/
Copy file name to clipboardExpand all lines: DEVELOPER.md
+62-13Lines changed: 62 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,21 +58,20 @@ For more information about devcontainers, you can check out the [devcontainer do
58
58
59
59
### Tenant
60
60
61
-
Developers should have access to a tenant where they can create and delete Power Platform environments and other resources.
62
-
63
-
TODO: more information about tenant and permissions needed by the dev user
61
+
Developers should have access to a tenant where they can create and delete Power Platform environments and other resources and run acceptance test.
62
+
You can setup access to you tenant using the following [bootstrap readme](https://github.com/microsoft/power-platform-terraform-quickstarts/blob/main/bootstrap/README.md) from our quickstarts repository.
64
63
65
64
### Credentials
66
65
67
-
See the [provider's user documentation](https://microsoft.github.io/terraform-provider-power-platform#authentication) on getting a service principal or user account credentials configured.
66
+
See the [provider's user documentation](https://microsoft.github.io/terraform-provider-power-platform#authentication) on authenticating to the provider once your tenant is set up.
68
67
69
68
### Environment Variables
70
69
71
70
Use environment variables to configure the provider to use your chosen credentials. You may either pass credentials as terraform variables (via `TF_VAR_*` environment variables) or by using the provider's own environment variables (`POWER_PLATFORM_*`). See the [provider's user documentation](https://microsoft.github.io/terraform-provider-power-platform#authentication) for more information on configuring credentials for the provider.
72
71
73
-
## Running Provider locally in VSCode (linux)
72
+
## Running Provider locally in VSCode
74
73
75
-
Open bash terminal inside VS Code and execute the following commands:
74
+
Open bash terminal inside VSCode and execute the following commands:
76
75
77
76
```bash
78
77
# you should already be in this directory, but just in case
@@ -88,7 +87,17 @@ cd examples/data-sources/powerplatform_environments
88
87
terraform plan
89
88
```
90
89
91
-
Note: You cannot run `terraform init` when using dev overrides. `terraform init` will validate the versions and provider source, while `terraform plan` will skip those validations when `dev overrides` is part of your config.
90
+
If you prefer to use you operating system terminal instead of VSCode you can run the following command:
> You cannot run `terraform init` when using dev overrides. `terraform init` will validate the versions and provider source, while `terraform plan` will skip those validations when `dev overrides` is part of your config. You can simply run `terraforn plan` and `terrafirn apply` when working in devcontainer.
98
+
99
+
> [!TIP]
100
+
> Because when working locally the `terraform init` command will not work, if you need additional terraform providers from terraform registry, all of them have to be added locally to the devcontainer in order to `terraform plan` and `terraform apply` work. You can add you missing terraform providers by adding them `.devcontainer/features/acceptance_test_dependencies/main.tf` and rebuild the devcontainer.
92
101
93
102
## Debugging provider in VSCode
94
103
@@ -128,15 +137,32 @@ To run single unit test
128
137
TF_ACC=0 go test -v ./... -run TestUnit<test_name>
129
138
```
130
139
131
-
Note: The tests require permissions on the folders, these permissions are assigned when creating your container.
132
-
If you have permission problems when running the unit tests, you can rebuild your development container
133
-
or run the following commands again to assign the permissions to the necessary folders.
140
+
> [!NOTE]
141
+
> The tests require permissions on the folders, these permissions are assigned when creating your container. If you have permission problems when running the unit tests, you can rebuild your development container or run the following commands again to assign the permissions to the necessary folders.
All the test for a given resource/datasource are located in `/internal/powerplatform/<resource/datasource_name>_test.go` file. When writing a new feature you should try to create [happy path](https://en.wikipedia.org/wiki/Happy_path) test(s) for you feature covering create, read and deletion of your new feature. For updates you should cover not only update of all properties but situation when a force recreate of a resource is requried (if you have such propeties in you resource).
151
+
152
+
### Writing Unit Tests
153
+
154
+
Unit test are created by mocking HTTP request, some of the often used HTTP mocks encapsulated in `ActivateEnvironmentHttpMocks` function, so that you don't have to write them for every test. When implementing new mocks, the mokcked response json files should be located in `/internal/powerplatform/services/<your_service_name>/test/<resource_or_datasource>/<name_of_the_unit_test>` folder
155
+
156
+
> [!TIP]
157
+
> When creating mocked json responses you can resuse the exising one by **duplicating** then into you `<name_of_the_unit_test>` folder.
158
+
159
+
> [!CAUTION]
160
+
> Your mocked json response file should not contain any Personally Identifiable Information such as tenantid, usernames, phone numbers, emails, addresses etc. You should anonymize that data.
161
+
162
+
### Writing Acceptance Tests
163
+
164
+
Each acceptance test is a copy of an unit test from tested use case perspective. That means for a given unit test we should have an acceptance test that validates the same use case but against a real infrastructure.
165
+
140
166
## Adding Dependencies
141
167
142
168
This provider uses [Go modules](https://github.com/golang/go/wiki/Modules).
@@ -161,7 +187,8 @@ make deps
161
187
162
188
User documentation markdown files in [/docs](/docs/) are auto-generated by the [terraform plugin docs tool](https://github.com/hashicorp/terraform-plugin-docs).
163
189
164
-
Do not manually edit the markdown files in [/docs](/docs/). If you need to edit documentation edit the following sources:
190
+
> [!IMPORTANT]
191
+
> Do not manually edit the markdown files in [/docs](/docs/). If you need to edit documentation edit the following sources:
165
192
166
193
- schema information in the provider, resource, and data-source golang files that are in [/internal](/internal/)
167
194
-[template files](templates/)
@@ -174,6 +201,9 @@ User documentation is temporarily served on GitHub Pages which requires the [pag
174
201
175
202
## Making a Release
176
203
204
+
> [!TIP]
205
+
> In you development work flow, you don't have to release the provider in order to test it locally, instread you can use the devcontainer and keep installing it locally in there by using `make install` command.
206
+
177
207
Our releases use [semantic versioning](https://semver.org/).
178
208
179
209
Given a version number MAJOR.MINOR.PATCH, increment the:
@@ -189,8 +219,27 @@ Use the `preview` extension to the MAJOR.MINOR.PATCH format for preview release
189
219
Use the `git tag` command on the `main` branch (ensure main is up to date) and then push that release back to origin.
190
220
191
221
```bash
192
-
git tag -a v0.7.0-preview -m "v0.7.0-preview"
193
-
git push origin v0.7.0-preview
222
+
git tag -a v1.0.0-preview -m "v1.0.0-preview"
223
+
git push origin v1.0.0-preview
194
224
```
195
225
196
226
Once the release is pushed to the repo, the [release.yml](/.github/workflows/release.yml) action pipeline will detect the new tag and create a draft release. After the build completes, you can publish the release if it looks good.
227
+
228
+
## Developer work flow
229
+
230
+
Once you decide to contribute back to this reposity by fixing a bug or adding a feature you work flow will be as follows:
231
+
232
+
1. Fork this repository and open in locally
233
+
1. Start working in devcontainer on your changes. (commands: `make install`, `terraform plan`, `terraform apply`)
234
+
- Completly new feature should be located in a new `/internal/powerplatform/services/<new_service_name>` folder.
235
+
1. Add and/or update unit and accaptance tests. Tests for new feature should be created in new resource/datasource_test.go file (commands: `make unittest`, `make acctest`)
236
+
- When working on a bug remember to add a new unit and acceptance test(s) covering your use case if that test does not exist yet.
237
+
- When working on a new feature add unit and acceptance tests covering [happy path](https://en.wikipedia.org/wiki/Happy_path) for your feature, ideally also some edge cases. If you feature enhances existing resource/datasource, add/change validation of your new properties in all tests that use that resource/datasource
238
+
1. Create/Update examples in `/examples/...` folder(s)
239
+
- When working on enhacement remeber to add new enhacement properties to all existing examples using that resource/datasource, especially if it is a requried property.
240
+
- When creating new resource/datasource, create new examples showcasing how to use it.
241
+
1. Regenerate the docs. (commands: `make docs`)
242
+
1. Raise a pull request from your fork back the this repository
243
+
244
+
> [!NOTE]
245
+
> If your use case requries testing outside local devcontainer like for example running it from a Github action, then you will need to create a realease from your fork repository.
0 commit comments