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
Copy file name to clipboardExpand all lines: docs/modules/ROOT/pages/running/gitops.adoc
+53-4Lines changed: 53 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
[[gitops]]
2
2
= Camel GitOps
3
3
4
-
Once your build is complete, you can configure the operator to run an opinionated GitOps strategy. Camel K has a built-in feature which allow the operator to push a branch on a given Git repository with the latest Integration candidate release built. In order to set the context, this would be the scenario:
4
+
Once your build is complete, you can configure the operator to run an opinionated GitOps strategy. Camel K has a built-in feature which allow the operator to push a branch on a given Git repository with the latest Integration or Pipe candidate release built. In order to set the context, this would be the scenario:
5
5
6
6
1. The dev operator builds the application from Git source
7
7
2. The dev operator push the container image
@@ -43,7 +43,31 @@ spec:
43
43
44
44
NOTE: There are more options to configure on the `gitops` trait. Feel free to have a look and learn on the trait documentation page directly.
45
45
46
-
As soon as the build of the Integration is completed, the operator will prepare the commit with the overlays. The structure would be like the following directory tree:
NOTE: When used with a Pipe, the `url` and `secret` trait parameters are required.
69
+
70
+
As soon as the build is completed, the operator will prepare the commit with the overlays. For an Integration, the structure would be like the following directory tree:
47
71
48
72
```bash
49
73
/integrations/
@@ -70,7 +94,30 @@ As soon as the build of the Integration is completed, the operator will prepare
70
94
71
95
The above structure could be used directly with `kubectl` (eg, `kubectl apply -k /tmp/integrations/sample/overlays/production`) or any CICD capable of running a similar deployment strategy.
72
96
73
-
The important thing to notice is that the **base** Integration is adding the container image that we've just built and any other trait which is required for the application to run correctly (and without the need to be rebuilt) on another environment:
97
+
For a Pipe, the structure is similar but uses `pipe.yaml` and `patch-pipe.yaml` instead:
98
+
99
+
```bash
100
+
/pipes/
101
+
├── all
102
+
│ └── overlays
103
+
│ ├── production
104
+
│ │ └── kustomization.yaml
105
+
│ └── staging
106
+
│ └── kustomization.yaml
107
+
└── timer-to-log
108
+
├── base
109
+
│ ├── pipe.yaml
110
+
│ └── kustomization.yaml
111
+
└── overlays
112
+
├── production
113
+
│ ├── kustomization.yaml
114
+
│ └── patch-pipe.yaml
115
+
└── staging
116
+
├── kustomization.yaml
117
+
└── patch-pipe.yaml
118
+
```
119
+
120
+
The important thing to notice is that the **base** resource (Integration or Pipe) is adding the container image that we've just built and any other trait which is required for the application to run correctly (and without the need to be rebuilt) on another environment:
74
121
75
122
```yaml
76
123
apiVersion: camel.apache.org/v1
@@ -184,7 +231,9 @@ NOTE: this is the approach suggested in https://developers.redhat.com/e-books/pa
184
231
185
232
=== Push to the same repository you've used to build
186
233
187
-
If you're building application from Git and you want to push the changes back to the same, then, you don't need to configure the Git repository for `gitops` trait. If nothing is specified, the trait will get the configuration from `.spec.git` Integration. This approach may be good when you want to have a single repository containing all aspects of an application. In this case we suggest to use a directory named `ci` or `cicd` as a convention to store your GitOps configuration.
234
+
If you're building application from Git and you want to push the changes back to the same repository, then, you don't need to configure the Git repository for `gitops` trait. If nothing is specified, the trait will get the configuration from `.spec.git` Integration. This approach may be good when you want to have a single repository containing all aspects of an application. In this case we suggest to use a directory named `ci` or `cicd` as a convention to store your GitOps configuration.
235
+
236
+
NOTE: This does not apply to Pipes, which must always specify the `url` on the `gitops` trait.
Copy file name to clipboardExpand all lines: pkg/apis/camel/v1/trait/gitops.go
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -17,9 +17,9 @@ limitations under the License.
17
17
18
18
package trait
19
19
20
-
// The GitOps Trait is used to configure the repository where you want to push a GitOps Kustomize overlay configuration of the Integration built.
20
+
// The GitOps Trait is used to configure the repository where you want to push a GitOps Kustomize overlay configuration of the Integration or Pipe built.
21
21
// If the trait is enabled but no pull configuration is provided, then, the operator will use the values stored in Integration `.spec.git` field used
22
-
// to pull the project.
22
+
// to pull the project. When used with a Pipe, the `url` and `secret` parameters are required as Pipes do not have a `.spec.git` fallback.
0 commit comments