-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENDOC-534 export-publish tutorial #586
Conversation
@@ -48,8 +43,8 @@ kubectl describe ingress/default-sso-in-namespace-ingress -n entando | |||
10. Click `Add Selected` to add `superuser` to the `Assigned Roles`. This change will be saved automatically. | |||
11. Go to the `Credentials` tab and copy the `Secret` shown there for use in the next section | |||
|
|||
### Create env.json | |||
1. Create a directory where you'll run the bundler and go to that directory: | |||
### Create the `env.json` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nshaw, is there a general term for env.json type files? Bundle Environment config file? Environment config file for Bundle?
If there isn't a good alternative, I'll leave it as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-> Create the env.json
configuration file
ent bundle init YOUR-BUNDLE-NAME | ||
cd YOUR-BUNDLE-NAME | ||
``` | ||
2. Copy the resources from the bundle directory, with the exception of microservices (/plugins) and micro frontends (/widgets), to the `platform` directory: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this section may be better to change into just text, without the cp command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on the fence here. I provided a more general command but describing the process might actually be good enough. One nuance is that the widgets can contain non-MFE widgets, like in our basic tutorial. We probably need to clarify that the /plugins and /widgets will need to be handled manually because of things like that. You have a good start on that below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the file path used for the cp set in stone?
``` | ||
2. Copy the resources from the bundle directory, with the exception of microservices (/plugins) and micro frontends (/widgets), to the `platform` directory: | ||
``` | ||
cp -R ../testBundle/bundle/assets platform/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can generalize this so it's done in one step. cp -R ../testBundle/bundle/* platform/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but it will copy over the descriptor.yaml, the widget & plugin directories. Is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be better to just describe the steps. We could do a find command like I did for the jhipster tutorial but it feels like overkill somehow.
``` | ||
cp -R ../testBundle/bundle/assets platform/ | ||
``` | ||
Repeat for all the other components in your bundle, including assets, contentModels, contents, fragments, labels, pageModels, resources, categories, contentTypes, groups, languages, and pages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the general cp you won't need to have this repeat sentence.
ent bundle init YOUR-BUNDLE-NAME | ||
cd YOUR-BUNDLE-NAME | ||
``` | ||
2. Copy the resources from the bundle directory, with the exception of microservices (/plugins) and micro frontends (/widgets), to the `platform` directory: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on the fence here. I provided a more general command but describing the process might actually be good enough. One nuance is that the widgets can contain non-MFE widgets, like in our basic tutorial. We probably need to clarify that the /plugins and /widgets will need to be handled manually because of things like that. You have a good start on that below.
@@ -48,8 +43,8 @@ kubectl describe ingress/default-sso-in-namespace-ingress -n entando | |||
10. Click `Add Selected` to add `superuser` to the `Assigned Roles`. This change will be saved automatically. | |||
11. Go to the `Credentials` tab and copy the `Secret` shown there for use in the next section | |||
|
|||
### Create env.json | |||
1. Create a directory where you'll run the bundler and go to that directory: | |||
### Create the `env.json` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-> Create the env.json
configuration file
::: | ||
|
||
### Construct the Docker-based Bundle Structure | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Lyd1aCla1r3, skip this section for now, lines 84 to the end, it is going to get reworked
|
||
``` | ||
$ ls bundle | ||
assets contentModels contents fragments labels pageModels resources | ||
categories contentTypes descriptor.yaml groups languages pages widgets | ||
``` | ||
|
||
You now have a complete Entando project structure! You can inspect the output to edit the exported components or deploy it to another Entando Application. | ||
You now have a complete Entando project structure for a git-based bundle! You can inspect the output to edit the exported components or [deploy](publish-project-bundle.md) it to another Entando Application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it required that you deploy to a different bundle? or is any instance fair game, including the application used for the export?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not sure what you mean. it was just exported from another location, so you are installing it for the first time in this local instance or to any instance. Why would you install it back to where you just exported from, it would be making work for no reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe i'm misunderstanding the use case. @nshaw if you have a bundle with some good stuff in it and want a similar, slightly different bundle in the same application, could/should you use the export command instead of locally cloning the files and doing surgery on what you want to keep/toss? if this is a possibility i suggest we remove the word "another"
``` | ||
cp -R ../testBundle/bundle/assets platform/ | ||
``` | ||
Repeat for all the other components in your bundle, including assets, contentModels, contents, fragments, labels, pageModels, resources, categories, contentTypes, groups, languages, and pages. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Repeat for" sounds a little abbreviated and like shorthand here; "Repeat this process / these steps, etc." is a bit more fleshed out
ent bundle init YOUR-BUNDLE-NAME | ||
cd YOUR-BUNDLE-NAME | ||
``` | ||
2. Copy the resources from the bundle directory, with the exception of microservices (/plugins) and micro frontends (/widgets), to the `platform` directory: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is the file path used for the cp set in stone?
|
||
If there are micro frontends or microservices in the bundle, use the source code to migrate them to their designated folders. Use the [ent bundle CLI tool](../../../docs/getting-started/ent-bundle.md) to assist in the process. Also check out the [Entando Bundle details](../../../docs/curate/bundle-details.md) page to define specific attributes for the MFEs and MSs in the bundle descriptor, `entando.json`. | ||
|
||
3. With the project structure in place, [build and publish](publish-project-bundle.md) your bundle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
build and publish -> build and deploy (our usual phrasing when referring to this process and a bit more representative of what's occurring)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the tutorial is called build and publish. And I don't think we need to call it the same exact thing every time unless it is a name of a thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in general i agree, but deploy is a more appropriate word imo. the end goal isn't to publish things to git/docker
``` | ||
Repeat for all the other components in your bundle, including assets, contentModels, contents, fragments, labels, pageModels, resources, categories, contentTypes, groups, languages, and pages. | ||
|
||
If there are micro frontends or microservices in the bundle, use the source code to migrate them to their designated folders. Use the [ent bundle CLI tool](../../../docs/getting-started/ent-bundle.md) to assist in the process. Also check out the [Entando Bundle details](../../../docs/curate/bundle-details.md) page to define specific attributes for the MFEs and MSs in the bundle descriptor, `entando.json`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the use of the source code here needs some clarification... do you make use of the source code when migrating, e.g. move the source code, or do you use the source code as in execute it? i think it's the former...
@nshaw i feel like there was a decision regarding the use of the word "migration" - that it should be used exclusively wrt changing platforms?
did we introduce MS as an acronym here? MSs looks really odd and is not a universally adopted initialism. even a somewhat exhaustive google search doesn't yield microservice as a candidate
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 & 2 edited a bit but it's intentionally vague and I think there are many ways to do it. No nothing to execute
Can we discuss about MSs later. After 7.1 is mostly done. changed here anyway
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vague is fine (no details necessary), but it's not clear how to read it and that's a bit different
sure. i remember at one point we were explicitly defining uncommon acronyms before we used them. in this case it should be pretty obv what MS stands for given the context
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vague is not the right word in this context, it's broad. And it needs to be because there are many ways of doing the same thing which is totally implied. I don't think that is unclear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"1 & 2 edited a bit but it's intentionally vague"
there may be many ways to do the same thing but that's beside the point here. this clearly reads like you run source code to perform a migration.
|
||
This command generates the same bundle directory structure as an Entando project, including a bundle descriptor file. | ||
This tutorial illustrates how to use the ent bundler to export a git-based Entando Bundle. This package can be deployed to a running Entando instance or modified to a docker-based bundle to take advantage of Entando's latest composable methods. The procedure assumes you're using an Entando quickstart application. Otherwise, you may need to adjust specific URLs, credentials, namespaces, etc., for a custom application. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"illustrates" is a bit inaccurate because there are no graphics or even a start-to-finish working example. describes?
"modified to" sounds odd; "converted to"
"Entando's latest composable methods" doesn't seem to fit. if that were the case, we should list them explicitly instead of with a vague reference; however, most of the benefits/changes consequent to the restructuring (for example, what alessandro listed in his demo slide) cannot be considered methods.
can simplify the second sentence to close the distance between the subject and verb and avoid the pause of the last comma: "To use a custom application, you may need to..."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- edited
- Nathan thought converted was not quite right
- Disagree, the ent bundle pack, publish, deploy as a whole is a method. there are several layers to this process, so it can be considered methods. Is there something specific about methods that we have to list.
- Don't want to mess with the last two sentences, not sure why it's there to begin with in this situation and not others, but no time to investigate and fix. Too much other work and this seems minor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
modified is a great word choice, but you don't modify to something. modify to show/say/do etc., but modify to a state, not a thing. for example, modify to be a docker-based bundle works, albeit inelegantly
-
disagree... "modified to a docker-based bundle to take advantage of Entando's latest composable methods" is too vague to provide much value to the reader; also, there are several significant advantages to docker-based bundles, and this wording doesn't communicate that / limits and undersells the new structure and process. and i think we should be somewhat aware of using "methods" as a word choice, given someone versed in software will associate that word with "a programmed procedure that is defined as part of a class and included in any object of that class" and perhaps make some false assumptions. but generally speaking, pack+publish+deploy is how you create a bundle, and it's pretty much the only way to do it. whether the bundle is docker- or git-based, and regardless of what commands/tools are used.
-
i was only suggesting a quick edit to move a couple words
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
edited the modified part
let's discuss the use of "methods". For now, don't agree on the narrow definition of methods. in this context it is clearly not calling for some specific program parameter. pretty sure we've used the term composable methods before
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nshaw please weigh in on 3
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nshaw we synced offline
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nshaw jinah is referring to component decoupling, e.g. the ability to execute commands on only MFEs (and vice versa)
The ent bundler command can export a bundle from an existing Entando Application to be utilized in the following ways: | ||
- For the initial install of components into an Entando Application | ||
- To migrate bundles from one environment to another (e.g. Dev to QA) | ||
- To provide a template for building a new application |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this block is kind of unnecessarily wordy; can be simplified, especially because i think the command exports a bundle by definition, not optionally.
"The ent bundler command exports a bundle from an existing Entando Application to:
- Perform the initial install of components into an Entando Application
- Migrate bundles from one environment to another (e.g. Dev to QA)
- Provide a template for building a new application"
No description provided.