You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Porch generates PackageRevision names automatically using a consistent format:
63
+
Porch generates PackageRevision names automatically using the `{repositoryName}.{packageName}.{workspaceName}` format. An example PackageRevision naming would be `porch-test.my-first-package.v1`.
-**Repository Name**: Name of the registered Git repository
69
68
-**Package Name**: Logical name for the package (can have multiple revisions)
70
69
-**Workspace Name**: Unique identifier within the package (maps to Git branch/tag)
71
70
72
-
**Important Notes:**
73
-
74
-
- Workspace names must be unique within a package
75
-
- Multiple PackageRevisions can share the same package name with different workspaces
76
-
- Published PackageRevisions get tagged in Git using the workspace name
71
+
{{% alert title="Note" color="primary" %}}
72
+
Workspace names must be unique within a package. Multiple PackageRevisions can share the same package name with different workspaces and published PackageRevisions get tagged in Git using the workspace name.
73
+
{{% /alert %}}
77
74
78
75
---
79
76
@@ -87,11 +84,7 @@ PackageRevisions contain structured configuration files that can be modified thr
87
84
2.**Modify**: Edit files locally using standard tools
88
85
3.**Push**: Upload changes back to Porch (triggers pipeline rendering)
89
86
90
-
**Pipeline Processing:**
91
-
92
-
- KRM functions defined in the Kptfile automatically transform resources
93
-
- Functions run when PackageRevisions are pushed to Porch
94
-
- Common functions: set-namespace, apply-replacements, search-replace
87
+
KRM functions defined in the Kptfile automatically transform resources; they run when PackageRevisions are pushed to Porch. Common examples include `set-namespace`, `apply-replacements`, and `search-replace`.
95
88
96
89
**Content Structure:**
97
90
@@ -116,16 +109,9 @@ PackageRevisions are stored in Git repositories registered with Porch:
116
109
-**Proposed**: Stored in `proposed/{workspace}` branch
117
110
-**Published**: Tagged as `{workspace}` and stored in main branch
118
111
119
-
**Repository Types:**
120
-
121
-
-**Blueprint Repositories**: Contain upstream package templates for cloning
122
-
-**Deployment Repositories**: Store deployment-ready packages (marked with `--deployment` flag)
123
-
124
-
**Synchronization:**
112
+
Porch differentiates two types of repositories: "blueprint" and "deployment". Blueprint repositories are meant to contain upstream package templates for cloning, while deployment repositories should store deployment-ready packages. The latter are marked with the `--deployment` flag.
- Periodic sync can be configured with cron expressions
114
+
Porch automatically syncs with Git repositories, however you can perform a manual sync with the `porchctl repo sync <repository-name>` command. You can also configure periodic sync with cron expressions.
129
115
130
116
---
131
117
@@ -135,33 +121,33 @@ Common issues when working with PackageRevisions and their solutions:
135
121
136
122
**PackageRevision stuck in Draft?**
137
123
138
-
- Check readiness conditions: `porchctl rpkg get <PACKAGE-REVISION> -o yaml | grep -A 5 conditions`
139
-
- Verify all required fields are populated in the Kptfile
140
-
- Check for pipeline function errors in Porch server logs
124
+
- Check readiness conditions with the `porchctl rpkg get <PACKAGE-REVISION> -o yaml | grep -A 5 conditions` command
125
+
- Verify that all required fields are populated in the Kptfile
126
+
- Check for pipeline function errors in the Porch server logs
141
127
142
128
**Push fails with conflict?**
143
129
144
-
- Pull the latest version first: `porchctl rpkg pull <PACKAGE-REVISION> ./dir`
145
-
-The PackageRevision may have been modified by someone else
130
+
- Pull the latest version first with the `porchctl rpkg pull <PACKAGE-REVISION> <directory>` command
131
+
-Check if the PackageRevision has been modified by someone else
146
132
- Resolve conflicts locally and push again
147
133
148
134
**Cannot modify Published PackageRevision?**
149
135
150
136
- Published PackageRevisions are immutable by design
151
-
- Create a new revision using `porchctl rpkg copy`
137
+
- Create a new revision with the `porchctl rpkg copy` command
152
138
- Use the copying workflow to create editable versions
153
139
154
140
**PackageRevision not found?**
155
141
156
-
- Verify the exact PackageRevision name: `porchctl rpkg get --namespace default`
157
-
- Check you're using the correct namespace
142
+
- Verify the exact PackageRevision name with the `porchctl rpkg get --namespace default` command
143
+
- Check if you are using the correct namespace
158
144
- Ensure the repository is registered and synchronized
Copy file name to clipboardExpand all lines: docs/content/en/docs/4_tutorials_and_how-tos/working_with_package_revisions/cloning-packages.md
+19-30Lines changed: 19 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -58,7 +58,7 @@ First, list available PackageRevisions to find one to clone:
58
58
porchctl rpkg get --namespace default
59
59
```
60
60
61
-
**Example output:**
61
+
Example output:
62
62
63
63
```bash
64
64
NAME PACKAGE WORKSPACENAME REVISION LATEST LIFECYCLE REPOSITORY
@@ -67,11 +67,7 @@ blueprints.wordpress.v1 wordpress v1 3 t
67
67
deployments.my-app.v1 my-app v1 1 true Published deployments
68
68
```
69
69
70
-
**What to look for:**
71
-
72
-
- Published PackageRevisions from blueprint repositories are good candidates for cloning
73
-
- Note the full NAME (e.g., `blueprints.nginx.main`)
74
-
- Check the REPOSITORY column to identify the source repository
70
+
Look for published PackageRevisions from blueprint repositories that are good candidates for cloning. Note the full NAME (e.g., `blueprints.nginx.main`) and check the REPOSITORY column to identify the source repository.
75
71
76
72
---
77
73
@@ -88,22 +84,15 @@ porchctl rpkg clone \
88
84
--workspace v1
89
85
```
90
86
91
-
**What this does:**
92
-
93
-
- Creates a new PackageRevision based on `blueprints.nginx.main`
94
-
- Names the new PackageRevision `my-nginx` (package name)
95
-
- Places it in the `deployments` repository (different from source)
96
-
- Uses `v1` as the workspace name
97
-
- Starts in `Draft` lifecycle state
98
-
- Maintains an upstream reference to `blueprints.nginx.main`
87
+
This command creates a new PackageRevision based on `blueprints.nginx.main` and names the new PackageRevision `my-nginx` (package name). The package is placed in the `deployments` repository (different from source) and receives `v1` as the workspace name. This PackageRevision starts in `Draft` lifecycle state. An upstream reference to `blueprints.nginx.main` is maintained.
99
88
100
-
**Verify the clone was created:**
89
+
Verify the clone was created:
101
90
102
91
```bash
103
92
porchctl rpkg get --namespace default --name my-nginx
104
93
```
105
94
106
-
**Example output:**
95
+
Example output:
107
96
108
97
```bash
109
98
NAME PACKAGE WORKSPACENAME REVISION LATEST LIFECYCLE REPOSITORY
@@ -120,7 +109,7 @@ After cloning, you can modify the new PackageRevision. Pull it locally:
0 commit comments