Proofreading chapter 3#4534
Open
mpgreaves wants to merge 2 commits into
Open
Conversation
Signed-off-by: Michael Greaves <michael.greaves@nokia.com>
Signed-off-by: Michael Greaves <michael.greaves@nokia.com>
mpgreaves
requested review from
efiacor,
kispaljr,
liamfallon and
mozesl-nokia
as code owners
✅ Deploy Preview for kptdocs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
dosubot
Bot
added
size:L
Contributor
There was a problem hiding this comment.
Pull request overview
This PR proofreads and rewrites portions of Chapter 3 (“Packages”) in the kpt book to improve readability and clarity of the package lifecycle workflow documentation.
Changes:
- Rephrases and restructures multiple explanatory paragraphs across package workflows (get/explore/edit/render/update/publish).
- Adjusts headings and list formatting within the chapter content.
- Updates wording around command references and examples.
Comments suppressed due to low confidence (1)
documentation/content/en/book/03-packages/_index.md:80
- List item 3 also has an unindented continuation line ("status of operations...") which will break the numbered list formatting in Markdown. Wrap/indent continuation lines under the list item indentation level.
3. The `status` section records the operational state of the package. This is managed by kpt and tracks the execution
status of operations such as `render`. The `status.conditions` field contains a list of condition objects, similarly to the way in which Kubernetes tracks the conditions on the resources. For example, after running `kpt fn render`, a `Rendered` condition is automatically recorded to indicate whether the last render succeeded or failed.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
73
to
+74
| 1. The `upstream` section contains the user-specified Git reference to the upstream package. This contains three pieces | ||
| of information: | ||
| - `repo`: The Git repository where the package can be found | ||
| - `directory`: The directory within the Git repository where this package can | ||
| be found | ||
| - `ref`: The Git reference for the package. This can be either a branch, tag, | ||
| or commit SHA. | ||
| 2. The `upstreamLock` section records the upstream Git reference (exact Git SHA) that was fetched by kpt. This section | ||
| is managed by kpt and should not be changed manually. | ||
| of information: |
| - Modifying the Kptfile | ||
| - Changes the package hierarchy, also called _package composition_. Examples: | ||
| - It changes the resources within the package. Examples are as follows: | ||
| - Authoring new a Deployment resource. |
|
|
||
| Oftentimes, you want to automate repetitive or complex operations. Having standardized on KRM for | ||
| all resources in a package allows us to easily develop automation in different | ||
| It is often necessary to automate repetitive or complex operations. Having standardized on KRM for all resources in a package allows you easily to develop automation in different |
| no status condition is written since the package is not being updated on disk. | ||
| Note: | ||
| Status conditions are only written for in-place renders (this is the default behavior). When using out-of-place output modes, such as `kpt fn render -o stdout` or `kpt fn render -o <dir>`, | ||
| no status condition is indicated, since the package is not being updated on a disk. |
| Initialize the package: | ||
| These two approaches are described in the following sections. | ||
|
|
||
| ### Creating a package |
|
|
||
| Start by initializing the the `wordpress` directory as a Git repo if you haven't | ||
| already done so: | ||
| Start by initializing the the `wordpress` directory as a Git repository, if you have not already done so: |
| ``` | ||
|
|
||
| ## Update the package | ||
| ## Updating the package |
|
|
||
| Packaging in kpt is based on Git forking. Producers publish packages by committing them to a Git repository. Consumers | ||
| fork the package to use it. | ||
| Packaging in kpt is based on Git forking. The producer publishes a package by committing it to a Git repository. The consumer forks the package, in order to use it. |
|
|
||
| We will cover package composition later in this chapter. For now, let's focus on editing resources | ||
| _within_ a package. | ||
| We will cover package composition later in this section. For now, let us focus on editing the resources _within_ a package. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.