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/administration/pipeline-settings.md
+23Lines changed: 23 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -47,6 +47,29 @@ Here you can define global template behavior. The options are:
47
47
48
48
Note that templates are simply normal pipelines “marked” as a template. There is no technical difference between templates and actual pipelines.
49
49
50
+
##Enabling cluster-contexts for pipelines
51
+
By default, all pipelines in the account can access all clusters integrated with Codefresh. Restrict pipeline access to clusters by enabling cluster-injection for individual pipelines in the account.
52
+
53
+
Selectively restricting access to clusters for a pipeline:
54
+
* Enhances security by restricting access to users from different teams.
55
+
* Reduces the overall duration of the build by shortening the initialization phase.
56
+
Codefresh authenticates the credentials of every cluster that the pipeline accesses during the initialization phase. This action affects build duration for accounts with large numbers of clusters.
57
+
58
+
1. In the Codefresh UI, select**Account Settings**, and then[**Pipeline Settings**](https://g.codefresh.io/account-admin/account-conf/pipeline-settings){:target="\_blank"}.
59
+
1. Toggle**Kubernetes cluster context pipeline injection** to ON.
alt="Enabling cluster contexts for injection into pipelines"
66
+
caption="Enabling cluster contexts for injection into pipelines"
67
+
max-width="60%"
68
+
%}
69
+
70
+
You can then select specific clusters for individual pipelines, through the**Kubernetes cluster** option in the[Pipeline's Policies section]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/#policies).
71
+
72
+
50
73
##Pipeline YAML Section
51
74
52
75
Here you can restrict the sources of pipeline YAML that users can select. The options are:
Copy file name to clipboardExpand all lines: _docs/configure-ci-cd-pipeline/pipelines.md
+60-1Lines changed: 60 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -191,6 +191,14 @@ Once you create your pipeline you can also click on the top tab called *Settings
191
191
192
192
###Policies
193
193
194
+
-**Kubernetes clusters**: Control pipeline access to Kubernetes clusters integrated with Codefresh.
195
+
* To allow the pipeline access to_all_ the cluster contexts integrated with Codefresh (the default), toggle**Inject all Kubernetes cluster context to pipeline builds** to ON.
196
+
* To allow the pipeline access to_only_ specific clusters, start typing in the name of the cluster as defined in its integration settings, and select it from the list displayed by Codefresh.
197
+
When defined, the initialization step in the pipeline displays the clusters selected for it.
-**Pipeline Concurrency**: the maximum number of concurrent builds (0-30 or unlimited) -- set this when your pipeline has only one trigger
195
203
>A Pipeline Concurrency of**0** freezes execution of the pipeline, switching it to maintenance mode. Use this concurrency setting to modify existing pipelines and freeze execution until you complete the changes.
196
204
-**Trigger Concurrency**: the maximum number of concurrent builds per trigger (1-31 or unlimited) -- set this when your pipeline has multiple triggers
@@ -209,7 +217,56 @@ Once you create your pipeline you can also click on the top tab called *Settings
209
217
- Builds in pending approval will**be** counted when determining the concurrency limit for a pipeline
210
218
- Honor the option defined globally in your Codefresh account
211
219
212
-
The**Pipeline and Trigger Concurrency** limits are very important as they allow you to define how many instances of a pipeline can run in parallel when multiple commits or multiple pull requests take place.
220
+
221
+
####Select Kubernetes cluster contexts
222
+
By default, all clusters integrated with Codefresh are automatically available for all pipelines in the account.
223
+
The inject cluster option when enabled for the account allows you to selectively restrict the clusters which can be accessed from pipelines created for the user account.
224
+
>This option is only available for Enterprise customers.
225
+
226
+
Increase security by restricting access to users from different teams.
227
+
Codefresh authenticates the credentials of each cluster during the build initialization phase. Fewer clusters mean shorter initializations and reduced build durations.
The option to select clusters for a pipeline is available only when the account-level pipeline setting is enabled. See[Enabling cluster contexts for pipelines]({{site.baseurl}}/docs/administration/pipeline-settings/#enabling-cluster-contexts-for-pipelines).
232
+
233
+
***Update Cluster** permission for users in the Codefresh UI through[Permissions](https://g.codefresh.io/account-admin/permissions/teams){:target="\_blank"}.
234
+
For more information, see[Access Control](https://codefresh.io/docs/docs/administration/access-control/#access-to-kubernetes-clusters-and-pipelines).
235
+
236
+
As part of the Pipeline > Policies, you can either allow access to all clusters (the default), or only specific clusters as in the example below.
alt="Imported cluster contexts in pipeline's init step"
260
+
caption="Imported cluster contexts in pipeline's init step"
261
+
max-width="60%"
262
+
%}
263
+
264
+
265
+
266
+
267
+
268
+
####Pipeline concurrency
269
+
**Pipeline and Trigger Concurrency** limits are very important as they allow you to define how many instances of a pipeline can run in parallel when multiple commits or multiple pull requests take place.
213
270
214
271
>Notice that these limits are*unrelated* to[parallelism within a single pipeline]({{site.baseurl}}/docs/codefresh-yaml/advanced-workflows/).
215
272
@@ -218,6 +275,8 @@ Some common scenarios are:
218
275
* a pipeline that uses a shared resource such as a database or queue and you want to limit how many pipelines can access it
219
276
* a pipeline that deploys to a single production environment (in most cases you only want one active pipeline touching production
220
277
278
+
279
+
####Build termination
221
280
The**Build Termination** settings are useful for pipelines where you commit too fast (i.e. faster then the actual runtime of the pipeline).
222
281
All these settings allow you to lesser the build instance for pipelines when too many triggers are launched at the same time.
223
282
You will find them very useful in cases where too many developers are performing small commits and builds take a long time to finish (i.e. build takes 10 minutes to finish and developers perform multiple pushes every 2 minutes)