Upgrade examples on the new docs #275
Conversation
lapentad
requested review from
Catalin-Stratulat-Ericsson and
efiacor
and removed request for
arora-sagar and
henderiw
|
Rebased on main |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
✅ Deploy Preview for nephio ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
lapentad
force-pushed
the
tutorial-upgrades-section
branch
from
e1e16be to
64b4a4a
Compare
Signed-off-by: lapentafd <[email protected]>
Signed-off-by: lapentafd <[email protected]>
lapentad
force-pushed
the
tutorial-upgrades-section
branch
from
64b4a4a to
85b2a82
Compare
|
Rebased |
content/en/docs/neo-porch/4_tutorials_and_how-tos/test-setup.md
Outdated
Show resolved
Hide resolved
content/en/docs/neo-porch/4_tutorials_and_how-tos/test-setup.md
Outdated
Show resolved
Hide resolved
| ## Package Lifecycle Workflow | ||
| Packages managed by Porch progress through several states, from creation to final publication. This workflow ensures that packages are reviewed and approved before they are published and consumed. | ||
| The typical lifecycle of a package is as follows: | ||
| 1. **Draft:** A user initializes a new package or clones an existing one. The package is in a `Draft` state, allowing the user to make changes freely in their local workspace. | ||
| 2. **Proposed:** Once the changes are ready for review, the user pushes the package, which transitions it to the `Proposed` state. In this stage, the package is available for review by other team members. | ||
| 3. **Review and Approval:** | ||
| * **Approved:** If the package is approved, it is ready to be published. | ||
| * **Rejected:** If changes are required, the package is rejected. The user must pull the package, make the necessary modifications, and re-propose it for another review. | ||
| 4. **Published:** After approval, the package is published. Published packages are considered stable and are available for deployment and consumption by other systems or clusters. They typically become the "latest" version of a package. | ||
|  |
There was a problem hiding this comment.
i dont think this section should be here why is this relevant to setting up the dev env?
There was a problem hiding this comment.
perhaps it should be moved to its own section in the tutorials called package lifecycle workflow which goes into a bit more detail and is referred to in the tutorials and the diagram should be a bit more in depth?
There was a problem hiding this comment.
ill provide a sample diagram using your current one as an example
There was a problem hiding this comment.
ok in the meantime i moved the package lifecycle section
Signed-off-by: lapentafd <[email protected]>
Signed-off-by: lapentafd <[email protected]>
| ## Overview | ||
|
|
||
| Lorem Ipsum | ||
| > Note: The tutorials in this section assume you have a local development environment running (Porch + Gitea in kind). If you plan to follow the walkthroughs locally, please set up the Local Dev Environment first: [Local Development Environment Setup]({{% relref "/docs/neo-porch/6_configuration_and_deployments/deployments/local-dev-env-deployment.md" %}}). |
There was a problem hiding this comment.
I think each tutorial should have it's own prerequisite section instead
| --- | ||
|
|
||
| ## Lorem Ipsum | ||
| ## Package Lifecycle Workflow |
There was a problem hiding this comment.
This should prob go with the Package Revision concept section
| ## Package Lifecycle Workflow | ||
|
|
||
| tutorial similar to getting started with first package in getting started section but this time in more detail and with package lifecycle diagram to clearly refference the different stages a package can be in and how it can change | ||
| Packages managed by Porch progress through several states, from creation to final publication. This workflow ensures that packages are reviewed and approved before they are published and consumed. |
There was a problem hiding this comment.
Do we need to explicitly differentiate between Package Revisions and KPT Packages?
| --- | ||
|
|
||
| ## Lorem Ipsum | ||
| # Upgrading Porch Packages |
| @@ -1,16 +1,239 @@ | |||
| --- | |||
| title: "Upgrading Packages" | |||
There was a problem hiding this comment.
Again, I think it might be useful to refer to Package Revisions in the Porch docs to differentiate from the KPT Package. Others may disagree. The 2 are linked, but different IMHO
|
|
||
| ### Step 3: Clone Blueprint v1 into a Deployment Package | ||
|
|
||
| Now, a user clones the blueprint to create a "downstream" deployment package. |
There was a problem hiding this comment.
We should prob have a Style Guide for this but we should stick to 1 style of "Step" instructions.
"Next, we'll create " -> "Create"
"Now, a user clones " -> "Clone"
|
|
||
| Scenario: Upstream adds a new ConfigMap and local changes added an annotation to Kptfile. `resource-merge` should apply the upstream addition while preserving the local annotation. | ||
|
|
||
| Commands (happy path): |
|
|
||
| ### Command Flags | ||
|
|
||
| The `porchctl rpkg upgrade` command has several key flags: |
There was a problem hiding this comment.
This should be referenced at the top with a link to the cli guide
| * **Separate Repositories:** For better organization and access control, keep blueprint packages and deployment packages in separate Git repositories. | ||
| * **Understand Your Strategy:** Before upgrading, be certain which merge strategy fits your use case to avoid accidentally losing important local customizations. When in doubt, the default `resource-merge` is the safest and most intelligent option. | ||
|
|
||
| ### Cleanup |
There was a problem hiding this comment.
Nice to have but prob not necessary.
Signed-off-by: lapentafd <[email protected]>
|
3 participants
Replacing #261