Technical Design for manifest-to-bicep-extension CLI
#95
Conversation
Signed-off-by: willdavsmith <willdavsmith@gmail.com>
| 4. Update build scripts and CI/CD pipelines | ||
| 5. Add tests for new functionality | ||
| 6. Update documentation | ||
|
|
There was a problem hiding this comment.
the rad CLI installer calls rad bicep download internally, so we should be covered: https://github.com/radius-project/radius/blob/4524c1af06dddb7a2f0c24b73e2b378c2fc0ae03/deploy/install.sh#L180
| #### Build System Updates | ||
|
|
||
| 1. **GitHub Actions**: Updated workflows to install and use the binary instead of `npx` | ||
| 2. Updated `radius-project/bicep-tools` repository to include the manifest-to-bicep-extension binary in releases |
There was a problem hiding this comment.
Where is this binary produced? are there cross compiling concerns, new pipeline etc for producing it?
There was a problem hiding this comment.
I'll add a section in the doc. we'll need to add a new pipeline to radius-project/bicep-tools, but it's very simple. I'll explain in the design meeting too.
| - Remove the Node.js/NPM dependency from the `rad bicep publish-extension` command | ||
| - Provide a consistent binary management experience similar to the Bicep CLI | ||
| - Maintain backward compatibility with existing workflows | ||
| - Ensure the binary is automatically downloaded when needed |
There was a problem hiding this comment.
We need to have a way to pass in this URL for air-gapped environments.
|
|
||
| The user experience should be exactly the same as it is today, with the following changes: | ||
| - The `rad bicep publish-extension` command will no longer require `npx` and will instead execute a native binary. | ||
| - The user will need to run `rad bicep download` to download the new `manifest-to-bicep-extension` binary, similar to how they currently download the Bicep CLI. |
There was a problem hiding this comment.
This should accept a flag for private registries...
|
|
||
| The manifest-to-bicep-extension binary is managed similarly to the Bicep CLI: | ||
|
|
||
| 1. **Download Location**: The binary is downloaded from GitHub releases at `https://github.com/radius-project/bicep-tools/releases/latest/download/` |
There was a problem hiding this comment.
Is the binary something we develop, or does it exist somewhere else? If it's somewhere else, can you provide a link?
| - Binary execution errors are propagated to the user | ||
| - No new telemetry is added | ||
|
|
||
| ## Development plan |
There was a problem hiding this comment.
Do we need a step to modify and test the release process to ensure that the binary is available, as described on line 89?
|
|
||
| The user experience should be exactly the same as it is today, with the following changes: | ||
| - The `rad bicep publish-extension` command will no longer require `npx` and will instead execute a native binary. | ||
| - The user will need to run `rad bicep download` to download the new `manifest-to-bicep-extension` binary, similar to how they currently download the Bicep CLI. |
There was a problem hiding this comment.
Where is this downloaded from?
| - Remove `npx` CLI install from test workflows | ||
| - Use existing test cases to verify that `rad bicep publish-extension` works with the new binary | ||
|
|
||
| ## Security |
There was a problem hiding this comment.
Any impact on dependency version management?
|
|
||
| ## Compatibility | ||
|
|
||
| - This is a breaking change for users who rely on the NPX-based approach |
There was a problem hiding this comment.
Can we run rad bicep download as a part of publish extension cmd?
| └───────────────┘ | ||
| ``` | ||
|
|
||
| ### Detailed Design |
There was a problem hiding this comment.
Any disadvantages of this approach compared to existing design?
manifest-to-bicep-extensionCLI