Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(doc): detailed builder runtime info #4584

Merged
merged 1 commit into from
Jul 17, 2023
Merged

chore(doc): detailed builder runtime info #4584

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions docs/modules/ROOT/pages/running/runtime-version.adoc
View file
Open in desktop
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].