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: CHANGELOG.md
+23-4Lines changed: 23 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,7 +2,25 @@
2
2
3
3
All notable changes to this project will be documented in this file.
4
4
5
-
## [Unreleased] - 2026-03-06
5
+
## [2026-03-20]
6
+
### Added
7
+
- Read-only PostgreSQL mirroring preflight script for validating runner prerequisites before mirror setup
8
+
- PostgreSQL mirroring follow-up wrapper to run preflight, preparation, and mirror creation as a deliberate post-deployment flow
9
+
- Shared AI Search helper module for OneLake indexing scripts to centralize public network access toggles and tokenized REST calls
10
+
11
+
### Changed
12
+
- PostgreSQL mirroring guidance now treats mirroring as a follow-up step after `azd up`, with clearer public-access versus private-network paths
13
+
- Postprovision now restores only PostgreSQL mirroring readiness preparation instead of attempting full mirror creation during the main deployment run
14
+
- Fabric connection and workspace automation now resolve more values from deployment outputs, azd environment values, and deployed resources when transient hook context is incomplete
15
+
- PostgreSQL mirroring scripts now support explicit connection-mode outputs, stronger credential handling, clearer network-path failures, and gateway-aware Fabric connection creation
16
+
- Purview collection and Fabric datasource registration scripts now derive default names and deployment context more reliably from outputs and environment values
17
+
- Post-deployment and mirroring documentation consolidated the mirror workflow into a single primary runbook and clarified when mirroring should be deferred
18
+
19
+
### Removed
20
+
- Temporary PostgreSQL mirroring prep wrapper that toggled public access as a separate script
21
+
- Fabric connection probe debug script and the redundant PostgreSQL mirroring opt-in guide
22
+
23
+
## [2026-03-18]
6
24
### Added
7
25
- Parameter to override Log Analytics workspace resource ID and output mapping for automation scripts
8
26
- Optional `SKIP_PURVIEW_INTEGRATION` guard for Purview automation scripts (used by hooks when Purview is disabled)
@@ -12,17 +30,18 @@ All notable changes to this project will be documented in this file.
12
30
- Preprovision error output simplified with concise failure reason and optional verbose diagnostics
13
31
- Main parameter file reordered into required/optional/defaulted sections with clearer comments
14
32
- OneLake indexing scripts prefer outputs, include AAD-only auth, and handle transient 409 run conflicts
33
+
- Post-deployment steps now include Fabric mirroring checklist items and Key Vault networking guidance for retrieving the `fabric_user` password
15
34
16
-
### Fixed
17
-
-Power BI headers initialization in Log Analytics linkage script to resolve workspace ID lookups
5. Open the **bronze** lakehouse and verify the `Files/documents` folder structure exists
49
48
6. In the workspace, check each lakehouse (**bronze**, **silver**, **gold**) and confirm the **Sensitivity label** matches the value set in the parameter file.
50
49
51
-
### PostgreSQL Mirroring (if enabled)
50
+
### Optional PostgreSQL Mirroring Follow-Up
52
51
53
-
Use these short steps to verify the automatic Fabric connection and mirroring flow. For full details and troubleshooting, see [PostgreSQL mirroring](./postgresql_mirroring.md).
52
+
Use these short steps to verify the PostgreSQL mirroring follow-up flow. For full details and troubleshooting, see [PostgreSQL mirroring](./postgresql_mirroring.md).
53
+
54
+
Mirroring in the current branch is a separate follow-up activity. Fabric connection creation and mirrored database creation are not part of `azd up`.
55
+
56
+
For post-deployment verification, the important distinction is simple:
57
+
58
+
- If you did not intentionally run the mirroring follow-up, treat mirroring as deferred and do not use it as a deployment success criterion.
59
+
- If you did run the mirroring follow-up, verify the Fabric connection and mirrored database from the workspace.
60
+
61
+
If you need to complete mirroring after deployment, use the dedicated steps in [PostgreSQL mirroring](./postgresql_mirroring.md).
62
+
63
+
The PostgreSQL server's **Fabric Mirroring** page only covers the source-server prerequisite preparation. It does not replace the Fabric workspace connection and mirrored database creation steps.
54
64
55
-
0. In **Azure Portal** → **Key Vault** → your vault → **Networking**, set **Public access** to **Allow public access from specific virtual networks and IP addresses**, add your client IP, then **Apply**. This lets you read the PostgreSQL connection password from the vault.
56
-
After you retrieve the secret, remove your IP and **Apply** again to re-lock the vault.
57
65
1. Check the resolved mirroring identity instead of hardcoding it:
0 commit comments