Modified language to adhere better to IBM style guide #67
Conversation
|
@rkratky ready to merge if you think it looks good, thanks! |
docs/modules/user-guide/partials/proc_adding-container-component-to-a-devfile.adoc
Outdated
Show resolved
Hide resolved
docs/modules/user-guide/partials/proc_adding-container-component-to-a-devfile.adoc
Outdated
Show resolved
Hide resolved
docs/modules/user-guide/partials/proc_adding-container-component-to-a-devfile.adoc
Outdated
Show resolved
Hide resolved
| @@ -78,7 +78,7 @@ The sources is mounted on a location stored in the `PROJECTS_ROOT` environment v | |||
|
|
|||
| . Container Entrypoint | |||
| + | |||
| The `command` attribute of the `container` along with other arguments, is used to modify the `entrypoint` command of the container created from the image. In {prod} the container is needed to run indefinitely so that you can connect to it and execute arbitrary commands in it at any time. Because the availability of the `sleep` command and the support for the `infinity` argument for it is different and depends on the base image used in the particular images, {prod-short} cannot insert this behavior automatically on its own. However, you can take advantage of this feature to, for example, start up necessary servers with modified configurations, etc. | |||
| Use the `command` attribute of the `container` to modify the `entrypoint` command of the container created from the image. In devfiles, the container runs indefinitely, so you can consistently connect to it and execute commands in it. The availability of the `sleep` command and the support for the `infinity` argument depend on the base image used in the particular images. Therefore, devfiles cannot automatically include these commands. | |||
There was a problem hiding this comment.
- Meaning changed. The orig. use of the
{prod}attribute was incorrect, but it wasn't right to substitute it fordevfiles(containers don't "run in devfiles"). - [IMPORTANT] Given the orig. content's orientation on Eclipse Che, the validity/suitability of this example needs to be checked with SMEs (esp. the inclusion and explanation of the
sleepandinfinitycommands).
| Use the `command` attribute of the `container` to modify the `entrypoint` command of the container created from the image. In devfiles, the container runs indefinitely, so you can consistently connect to it and execute commands in it. The availability of the `sleep` command and the support for the `infinity` argument depend on the base image used in the particular images. Therefore, devfiles cannot automatically include these commands. | |
| Use the `command` attribute of the `container` type to modify the `entrypoint` command of the container created from the image. When a devfile is used in {che-prod}, the container runs indefinitely, so the user can consistently connect to it and execute commands in it. The availability of the `sleep` command and the support for the `infinity` argument depend on the base image used in the particular images. |
There was a problem hiding this comment.
@maysunfaisal , apologies for not directing your attention to this specific comment earlier. Given Robert's question, does the above example still work, specifically the explanation of the sleep and infinity command? Thanks!
docs/modules/user-guide/partials/proc_limiting-resources-usage.adoc
Outdated
Show resolved
Hide resolved
docs/modules/user-guide/partials/proc_limiting-resources-usage.adoc
Outdated
Show resolved
Hide resolved
docs/modules/user-guide/partials/proc_limiting-resources-usage.adoc
Outdated
Show resolved
Hide resolved
| @@ -36,7 +36,7 @@ parent: | |||
| + | |||
| .Parent referred by uri | |||
There was a problem hiding this comment.
| .Parent referred by uri | |
| .Parent referred by a URI |
There was a problem hiding this comment.
Using "URI" (and the associated uri attribute) seems strange here. Shouldn't it be "URL"? If yes, then the spec is wrong :( Confirm with SMEs, please.
There was a problem hiding this comment.
it is URI. URI vs URL FYI :)
There was a problem hiding this comment.
@maysunfaisal, that's exactly why I was asking. The example uses a URL, not a URI. Would it really be possible to use URIs, or are URLs required?
docs/modules/user-guide/partials/proc_referring-to-a-parent-devfile-in-a-devfile.adoc
Outdated
Show resolved
Hide resolved
docs/modules/user-guide/partials/proc_specifying-persistent-storage.adoc
Outdated
Show resolved
Hide resolved
…nt-to-a-devfile.adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
…nt-to-a-devfile.adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
…nt-to-a-devfile.adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
…nt-to-a-devfile.adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
….adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
….adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
….adoc Co-authored-by: Robert Krátký <rkratky@redhat.com>
|
Thanks @maysunfaisal for the insight :) @rkratky please review and see if you think it can be merged now. Thank you both! |
|
For more work on these Eclipse Che related content concerns, please see issue #491: devfile/api#491 |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: elsony, jc-berger, rkratky The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Fixes #254 Review Language in Authoring Stacks.Since I am doing a review of all the authoring stacks docs, I'll be making several PRs. I don't want any single PR to be too large, so I'll make a new PR for every several docs that I modify to meet the IBM Style Guide's requirements.