gansheer commented on code in PR #5057: URL: https://github.com/apache/camel-k/pull/5057#discussion_r1448679328
########## docs/modules/ROOT/pages/pipeline/pipeline.adoc: ########## @@ -113,9 +117,44 @@ Given the limited space we can use in a Kubernetes custom resource, we are trunc If for any reason you still need to access the entire log of the execution, you can always access to the log of the builder `Pod` and the specific container that was executed, ie `kubectl logs camel-k-kit-chj2gpi9rcoc73cjfv2g-builder -c task1 -p` +[[build-pipeline-sort]] +=== Tasks filtering and sorting +The default execution of tasks can be changed. You can include or remove tasks and provide your order of execution. When using the `builder` trait, this is done via `builder.tasks-filter` property. This parameter accepts a comma separated value list of tasks to execute. It must specify both operator tasks (ie, builder) and custom tasks. + +WARNING: altering the order of tasks may result in a disruptive build behavior. + +With this approach you can also provide your own publishing strategy. The pipeline run as a Kubernetes Pod. Each task is an `initContainer` and the last one is the final `container` which has to provide the published image digest into the `/dev/termination-log` in order to know the publish was completed. This is done out of the box when a supported publishing strategy is executed. If you want to provide your own publishing strategy, then, you need to make sure to follow this rule to have the entire process working (see examples later). + +There are certain environment variables we are injecting in each custom container in order to be able to get dynamic values required to perform certain operation (ie, publishing a container image): + +* INTEGRATION_KIT_IMAGE contains the name of the image expected to be used for the IntegrationKit generated during the pipeline execution + +We may add more if they are required and useful for a general case. + +[[build-pipeline-privileges]] +=== Execution privileges +The builder Pod will set a `PodSecurityContext` with user 1001 privileges. This is a convention in order to maintain the same default user ID for the container images we use by defautl. Each container image will inherit this value unless specified with the user ID parameter. Review Comment: The user is will not be 1001 in S2I mode, we would use the security context constraints (SCCs) to define it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
