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
## Changes
<!-- Summary of your changes that are easy to understand. Add
screenshots when necessary -->
Add handler methods to resolve global parameters from ADF resources.
Parameter is controlled by the user via prompting. The choice is applied
to an entire ADF resource during conversion. Users can choose to:
- Inject resolved parameter values directly into the code or
configuration during conversion
- Create bundle variables and parameterize code or configuration with
bundle variable references
### Linked issues
<!-- DOC: Link issue with a keyword: close, closes, closed, fix, fixes,
fixed, resolve, resolves, resolved. See
https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword
-->
N/A
### Tests
<!-- How is this tested? Please see the checklist below and also
describe any other relevant tests -->
- [x] manually tested
- [x] added unit tests
- [ ] added integration tests
|`literal`| True | Writes each global variable into the translated configuration or notebook code. |
94
+
|`bundle_variable`| False | Uses a `${var.X}` reference and declares the global variable as a [DAB bundle variable](https://docs.databricks.com/aws/en/dev-tools/bundles/variables). |
95
+
96
+
Under `bundle_variable`, each referenced global becomes a variable in `databricks.yml` with its
97
+
factory value as the default, so a deploy with no overrides reproduces the original ADF behavior.
98
+
You then change the value per target or at deploy time
notebook code are wired through the task's `base_parameters` so `${var.X}` still resolves at
101
+
runtime.
102
+
103
+
<Callouttype="warn"title="Sensitive values ship in plaintext">
104
+
The default values for global parameters are written into `databricks.yml` as plain text. For sensitive
105
+
values (e.g. tokens, connection strings, URLs with embedded SAS signatures), clear the default and
106
+
supply the value at deploy time using a `--var` argument, a per-target override, or a secret scope instead
107
+
of committing sensitive values to the bundle. See `SETUP.md` for a full list of converted global variables.
108
+
</Callout>
109
+
86
110
## Discover complexity report
87
111
88
112
The `discover` phase emits `<output_dir>/metadata/profile_report.csv` (default `./flowx_output/metadata/profile_report.csv`), one row per pipeline with the following columns:
-`<adf_source_dir>` is the original ADF JSON directory (the same `--source-dir` used by discover)
103
104
-`<output_dir>` is the **shared migration output directory** (default: `./flowx_output`) — the
104
105
same one discover used
105
106
-`<pipeline_name>` (optional) — when provided, translates only the named pipeline. **Always pass `--pipeline` when the user has specified a specific pipeline to migrate**, matching the value passed to the discover phase.
107
+
-`--global-parameter-resolution` (optional, default `literal`) — how `@pipeline().globalParameters.X`
108
+
references resolve, applied to every pipeline. `literal` bakes the factory value in as a literal;
109
+
`bundle_variable` emits `${var.X}` and declares the global as a DAB bundle variable whose default is
110
+
the factory value, so it can be set at deploy time (`--var X=…` or a per-target override) instead of
111
+
being hard-coded into pipeline/activity bodies. Globals referenced inside generated notebook code are
112
+
bridged through the task's `base_parameters` so `${var.X}` still resolves. See SETUP.md for the list
113
+
of hoisted variables and a plaintext-secret caveat.
106
114
107
115
The translation report and intermediate IR are written to the **transient**`<output_dir>/.work/`
108
116
folder (`translation_report.json`, per-pipeline IR, `gaps.json`). These are consumed by the steps
0 commit comments