-
Notifications
You must be signed in to change notification settings - Fork 36
Adding Inspecting Packages Guide #287
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
Conversation
✅ Deploy Preview for nephio ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
| description: "A guide to viewing, querying, and inspecting packages in Porch" | ||
| --- | ||
|
|
||
| ## Prerequisites |
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.
Do all the "package" guides have common prerequisites?
If so, maybe we should add them to a sub section "Working with Package Revisions" and define the common prerequisites there.
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.
will do in a separate PR where rpkg / package revision based guides will all get moved as it is easier done that way on my end.
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
| - **spec.tasks**: History of operations performed | ||
| - **status.publishTimestamp**: When it was published | ||
|
|
||
| {{% alert title="Tip" color="primary" %}} |
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 about including this here. We run -o yaml above, then here with json. These are generic kubectl mech so not relevant.
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 see the point but i dont think the tip is hurting or distracting from anything, section shows that the -o yaml/json works as it does with kubectl. i get that its a kubectl mechanic and therefore not relevant however i think the fact that the same mechanic works on porchctl is relevant.
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/inspecting-packages.md
Outdated
Show resolved
Hide resolved
| blueprints.nginx.main nginx main 5 true Published blueprints kpt.dev/latest-revision=true | ||
| ``` | ||
|
|
||
| {{% alert title="Note" color="primary" %}} |
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 this necessary?
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 it adds some clarity and is a useful Note.
|
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: efiacor The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |



Adding a guide to how to view porch Package Revisions and their contents.
Most of these Guide sections are meant to take out the detailed use cases out of the cli-guide into their particular use cases as the cli-guide's main goal is to act as a "A manual/dictionary" for the porchctl commands/arguments and not describe their use cases.