ENDOC-539 Apply feedback re bundle cli #571
Conversation
|
|
||
| The next step runs the components locally, resulting in log files in each of the component's directories. | ||
| Keycloak integration enables components to be run locally to test MFEs and MS external to an Entando cluster. Multiple components are run in parallel via commands dependent on type and stack, with a log file for each individual component generated in its directory. |
There was a problem hiding this comment.
the log files are not generated in its directory, they are in the .entando/logs directory.
This section is starting to lose its thread because the purpose was to discuss the process of building a bundle and correlate it to the ent bundle commands. Starting the paragraph about Keycloak, with no reference to the process or ent bundle CLI, sidelines and confuses the main point.
Same below for ent bundle pack.
The focus here was the ent bundle CLI and how they manage a project and turn it into a bundle. Removing all the ent bundle CLI mentions muddles that goal. Another goal was to show the streamlined process of turning the project into a bundle, so focusing on ent bundle init, build, pack and publish. I neglected deploy and install which you added below. It should be added briefly here too.
There was a problem hiding this comment.
i was wondering about .entando/logs but didn't make that change
i'll work with it a bit. there are two options: to do another command details format introducing bullets for each command, or letting this read as an actual overview where we give the reader credit for being able to map each sentence to the command/phase it describes.
the goal to emphasize streamlining didn't come through. i'll try to work that in.
There was a problem hiding this comment.
Maybe the bullets is a good idea, especially if it gets too much longer
| ### Bundle Development Overview | ||
| A single JSON descriptor file works as the manifest for an Entando project to be converted into a reusable bundle. The process starts with the initialization step which | ||
| sets up the structure and scaffolding needed for a new project. Alternatively, the ent tool allows a bundle to be initialized directly from the Entando Hub, speeding up the development process. | ||
| Beginning with Entando 7.1, the `ent bundle` command and its convenience methods govern the structure and files of an Entando Bundle. This format relies on a single JSON descriptor as the project manifest. A new bundle project can be initialized with the default files and folders or from an existing bundle in an Entando hub. |
There was a problem hiding this comment.
ent bundle command and its convenience methods govern the structure and files of an Entando Bundle >> ent bundle is not just a command and it kind of minimizes the new ent bundle functionality which is what this section is elaborating on.
There was a problem hiding this comment.
ent bundle is by definition a command. the Entando Bundle CLI is a tool that enables bundle management, or the functionality of ent bundle. the ent bundle cli was introduced front and center at the top of the page; it is implemented via ent bundle and the various subcommands/args
There was a problem hiding this comment.
I think the 'ent bundle command and its convenience methods' part still makes it sound like a cute little thing, just something easier to do. And ent bundle is not really a command, it's a CLI module, isn't it.
I think it's the word convenience too, the changes weren't just about convenience. The whole process changed to make it modular.
There was a problem hiding this comment.
by definition, ent bundle is a command, and it provides convenience methods
https://en.wikipedia.org/wiki/Convenience_function
There was a problem hiding this comment.
in this context, it is definitely not convenience methods because ent bundle adds all sorts of new methods. We will just have different opinions about this one
There was a problem hiding this comment.
i don't think it's a matter of opinion.
| ### Bundle Development Overview | ||
| A single JSON descriptor file works as the manifest for an Entando project to be converted into a reusable bundle. The process starts with the initialization step which | ||
| sets up the structure and scaffolding needed for a new project. Alternatively, the ent tool allows a bundle to be initialized directly from the Entando Hub, speeding up the development process. | ||
| Beginning with Entando 7.1, the `ent bundle` command and its convenience methods govern the structure and files of an Entando Bundle. This format relies on a single JSON descriptor as the project manifest. A new bundle project can be initialized with the default files and folders or from an existing bundle in an Entando hub. |
There was a problem hiding this comment.
I think the 'ent bundle command and its convenience methods' part still makes it sound like a cute little thing, just something easier to do. And ent bundle is not really a command, it's a CLI module, isn't it.
I think it's the word convenience too, the changes weren't just about convenience. The whole process changed to make it modular.
|
|
||
| The next step runs the components locally, resulting in log files in each of the component's directories. | ||
| Keycloak integration enables components to be run locally to test MFEs and MS external to an Entando cluster. Multiple components are run in parallel via commands dependent on type and stack, with a log file for each individual component generated in its directory. |
There was a problem hiding this comment.
Maybe the bullets is a good idea, especially if it gets too much longer
|
|
||
| Once a bundle has been published, it can be delivered to the ECR of an Entando Application via the `deploy` subcommand. The bundle custom resource is exported and tags are retrieved from Docker Hub. | ||
| - [Deploy](#deploy): `ent bundle deploy` delivers a published bundle to the ECR of an Entando Application. The bundle custom resource is exported and tags are retrieved from Docker Hub. |
There was a problem hiding this comment.
still don't think export is accurate
There was a problem hiding this comment.
i guess leave a comment on notion. to export a CR is common terminology and logical
There was a problem hiding this comment.
I don't think export actually works here. What's happening here is creating the descriptor file for a custom resource - generated is the standard language in all the tools, hence ent prj generate-cr. Export implies taking something out of one system so it can be used in another but the custom resource is actually being written (generated) from the data in the repository. Arguably if the CR existed as a thing in the repository, then it might be an export but that isn't the case here.
There was a problem hiding this comment.
thanks for clarifying; i had thought that the CR was generated in the cluster before the bundle was pulled into the ECR
|
|
||
| Once a bundle has been published, it can be delivered to the ECR of an Entando Application via the `deploy` subcommand. The bundle custom resource is exported and tags are retrieved from Docker Hub. | ||
| - [Deploy](#deploy): `ent bundle deploy` delivers a published bundle to the ECR of an Entando Application. The bundle custom resource is exported and tags are retrieved from Docker Hub. |
There was a problem hiding this comment.
I don't think export actually works here. What's happening here is creating the descriptor file for a custom resource - generated is the standard language in all the tools, hence ent prj generate-cr. Export implies taking something out of one system so it can be used in another but the custom resource is actually being written (generated) from the data in the repository. Arguably if the CR existed as a thing in the repository, then it might be an export but that isn't the case here.
|
|
||
| ### Customize Quickstart | ||
| The `ent quickstart` command allows parameters that customize your quickstart environment. These options allow you to modify specific properties of your VM, installation versions and databases. | ||
| The `ent quickstart` command accepts parameters to customize your quickstart environment. These options allow you to modify specific properties of your VM, installation versions and databases. | ||
|
|
||
| |Operation |Syntax|Description| | ||
| |:--|:--|:--| | ||
| |ent quickstart| ent quickstart --vm-reuse=YOUR-EXISTING-VM| Reuse an existing VM | ||
| ||ent quickstart --release="v7.2.0" | Use a specific release version for the install |
There was a problem hiding this comment.
Existing, we probably shouldn't use an example of 7.2.0 which doesn't exist yet. Either we should use the current release, or make it generic. Probably v7.1.0 is best.
No description provided.