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
To contribute, add the upstream repository as an additional remote and work on a branch other than main. This approach allows you to merge changes into the main branch (reflected in GitOps workflows) and makes upstream contributions easier. Contributions from your forked main branch typically include:
15
+
To contribute, add the upstream repository as an additional remote and work on a branch other than the main branch. Merge changes into the main branch to align with GitOps workflows. This approach simplifies upstream contributions. Contributions from your forked main branch typically include:
16
16
17
17
. Customizations to `values-global.yaml` and other installation-specific files.
18
18
. Commits made by Tekton and other automated processes unique to your setup.
19
19
20
-
To isolate changes for upstream contributions (`hcp` is "Validated Patterns"), you can use a separate remote and branch name:
20
+
*To isolate changes for upstream contributions*
21
21
22
+
. Run the following command to add the upstream repository as a remote:
. Create a branch named `hcp-main` and track `hcp/main`:
37
+
+
38
+
[source,terminal]
39
+
----
26
40
$ git branch -b hcp-main -t hcp/main
27
-
<make changes on the hcp-main branch>
41
+
----
42
+
43
+
. Make your changes on the `hcp-main` branch as needed.
44
+
45
+
. Push your changes to your fork’s `hcp-main` branch:
46
+
47
+
+
48
+
[source,terminal]
49
+
----
28
50
$ git push origin hcp-main
29
51
----
30
52
31
-
To update `hcp-main` branch with upstream changes:
53
+
*To update `hcp-main` branch with upstream changes*
54
+
55
+
. Run the following command to check out the `hcp-main` branch:
32
56
57
+
+
33
58
[source,terminal]
34
59
----
35
60
$ git checkout hcp-main
36
-
$ git pull --rebase
37
61
----
38
62
39
-
To reflect these changes in your forked repository (useful for submitting a PR later):
63
+
. Pull the latest changes from the upstream repository and rebase:
64
+
+
65
+
[source,terminal]
66
+
----
67
+
$ git pull --rebase
68
+
----
40
69
70
+
. Reflect these changes in your forked repository (useful for submitting a PR later):
71
+
+
41
72
[source,terminal]
42
73
----
43
74
$ git push origin hcp-main
44
75
----
45
76
46
-
To integrate upstream pattern changes into your local GitOps process:
77
+
*To integrate upstream pattern changes into your local GitOps process*
47
78
79
+
. Run the following command to check out the main branch:
80
+
+
48
81
[source,terminal]
49
82
----
50
83
$ git checkout main
84
+
----
85
+
86
+
. Merge changes from the `hcp-main` branch into your main branch:
87
+
+
88
+
[source,terminal]
89
+
----
51
90
$ git merge hcp-main
91
+
----
92
+
93
+
. Push the merged changes to your fork’s main branch:
94
+
+
95
+
[source,terminal]
96
+
----
52
97
$ git push origin main
53
98
----
54
99
@@ -61,7 +106,7 @@ This workflow ensures that the `hcp-main` branch:
61
106
[id="changing-subtrees"]
62
107
== Changing subtrees
63
108
64
-
Our patterns use the Git subtree feature to promote modularity, enabling multiple patterns to share the same common base. Over time, we move more functionality into the common directory to isolate pattern-specific components as standard usage practices emerge. This approach strengthens the tools in the common directory, adds features, and simplifies the development of new patterns. Typically, we maintain the common subtree during routine updates, and pulling changes from upstream includes any updates from the common directory.
109
+
The Git subtree feature promotes modularity by enabling multiple patterns to share a common base. Over time, functionality is moved into the common directory to isolate pattern-specific components as standard usage practices emerge. This approach strengthens tools in the common directory, adds features, and simplifies the development of new patterns. The common subtree is typically maintained during routine updates, and pulling changes from upstream includes any updates from the common directory.
65
110
66
111
You only need to modify subtrees if you want to test changes in the common area of the pattern repositories or contribute to the common repository alongside one of the patterns. Using the pattern alone does not require changing subtrees.
Make changes in your fork’s main branch or create a new branch for your modifications.
84
129
85
-
To track these changes in your fork of the pattern repository (e.g., `industrial-edge`), replace the common subtree with your forked version. To simplify this process use:
130
+
To track these changes in your fork of the pattern repository (example, `industrial-edge`), replace the common subtree with your forked version. To simplify this process use:
These are the default settings for the repository configuration.
118
163
119
-
[id="subtree-vs-submodule"]
120
-
== Subtree vs. Submodule
164
+
[id="subtree-compared-to-submodule"]
165
+
== Subtree compared to Submodule
121
166
122
-
Ensuring patterns can be easily shared across multiple projects has always been a priority. While it is technically possible to share changes between unrelated Git repositories, this is a largely manual process prone to errors. We aim to offer a seamless "pull" experience, allowing a single `git pull` action to update shared pattern components. For repository sharing, we considered two main strategies: submodules and subtrees. Initially, we used submodules but later moved to subtrees.
167
+
Ensuring patterns are easily shareable across multiple projects has been a key priority. While technically possible, sharing changes between unrelated Git repositories often involves a manual and error-prone process. The goal is to provide a seamless "pull" experience, where a single git pull action updates shared pattern components. For repository sharing, two main strategies were considered: submodules and subtrees. Initially, submodules were used, but the approach later transitioned to subtrees.
123
168
124
169
Subtrees integrate the history of another repository into a parent repository, offering many benefits of submodules without most of their drawbacks. Atlassian provides useful documentation on subtrees, which explains their advantages in more detail. For more information see, link:https://www.atlassian.com/blog/developer[Developer's blog] and link:https://www.atlassian.com/git/tutorials/git-subtree[Git subtree].
125
170
@@ -131,7 +176,7 @@ Submodules presented unavoidable challenges, such as:
131
176
* Submodules required mirroring more repositories in disconnected environments.
132
177
* Working with forked submodules meant maintaining two separate repositories and multiple branches in each.
133
178
134
-
Subtrees also have challenges. For example, it is easier to diverge from the upstream version of the subtree, and users may not realize that a subtree is in use when cloning a repository. This can be considered a feature, but may lead to conflicts when updating to a newer version. Additionally, subtrees are less commonly understood, which can result in unexpected issues, such as:
179
+
Subtrees also have challenges. For example, it is easier to diverge from the upstream version of the subtree, and users may not realize that a subtree is in use when cloning a repository. This can be considered a feature, but might lead to conflicts when updating to a newer version. Additionally, subtrees are less commonly understood, which can result in unexpected issues, such as:
135
180
136
181
137
182
* Cherry picking from a subtree commit into the parent puts the change in the parent location, not the subtree.
. Customize the deployment for your cluster. Customization involves updating the `values-global.yaml` file with configurations specific to your cluster environment.
42
+
.. Edit the `values-global.yaml` file:
39
43
+
40
44
[source,terminal]
45
+
+
41
46
----
42
47
$ vi values-global.yaml
48
+
----
49
+
.. Commit the updated `values-global.yaml` file to the repository:
0 commit comments