Skip to content

Commit

Permalink
chore(doc): detailed builder runtime info
Browse files Browse the repository at this point in the history
  • Loading branch information
squakez committed Jul 17, 2023
1 parent 2b5a694 commit a421a3c
Showing 1 changed file with 6 additions and 0 deletions.
6 changes: 6 additions & 0 deletions docs/modules/ROOT/pages/running/runtime-version.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,6 +10,12 @@ kamel run my-route.yaml -t camel.runtime-version=1.17.0

Having the ability to choose the runtime, gives you the ability to specify which Camel version you want to run. Each Camel K Runtime is bound to a well defined version of Camel (see the compatibility matrix).

== How does it work

This feature requires the dynamic generation of a builder that contains all the tooling expected by the build phase. In particular, this is a requirement for Quarkus native builds which, from now on, can be only done with builder `Pod` strategy.

When you are creating a new runtime for which a [CamelCatalog](/camel-k/next/architecture/cr/camel-catalog.html) does not yest exist, Camel K Operator is in charge to create such a catalog. The creation of a new Catalog binds to the creation of a container image builder which will later be used by the builder `Pod` to build a Camel application which is specific to such a runtime.

== Pin a runtime version

By default each Camel K version uses a specific runtime version, ie, Camel K 2.0 uses Camel K Runtime 2.16.0. Using the trait will let you pin to a well defined version, avoiding to unintentionally upgrade the runtime of the integrations running when you perform an operator upgrade. See more info in the xref:contributing/upgrade.adoc#maintain-runtime-integrations[Camel K upgrade documentation].

0 comments on commit a421a3c

Please sign in to comment.