From f65635163076a3f1958d34e4a040f0c95b05c876 Mon Sep 17 00:00:00 2001 From: Chuang Wang Date: Mon, 2 May 2022 15:21:16 -0700 Subject: [PATCH] Document that parameter names are case-insensitive Prior to this commit, parameter names will be checked against duplicates (case-insensitive) by the webhook, but it's not mentioned that parameter names are case-insensitive in the documentation. --- docs/tasks.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/docs/tasks.md b/docs/tasks.md index 1e9ee168e1e..eaed20a1233 100644 --- a/docs/tasks.md +++ b/docs/tasks.md @@ -327,7 +327,7 @@ steps: echo "I am supposed to sleep for 60 seconds!" sleep 60 timeout: 5s -``` +``` #### Specifying `onError` for a `step` @@ -447,6 +447,8 @@ Parameter names: For example, `foo.Is-Bar_` is a valid parameter name, but `barIsBa$` or `0banana` are not. +> NOTE: Parameter names are **case insensitive**. For example, `APPLE` and `apple` will be treated as duplicate parameters. If they appear in the same taskspec's params, validation webook will complain about that. + Each declared parameter has a `type` field, which can be set to either `array` or `string`. `array` is useful in cases where the number of compilation flags being supplied to a task varies throughout the `Task's` execution. If not specified, the `type` field defaults to `string`. When the actual parameter value is supplied, its parsed type is validated against the `type` field. @@ -1163,10 +1165,10 @@ log into the `Pod` and add a `Step` that pauses the `Task` at the desired stage. ### Running Step Containers as a Non Root User -All steps that do not require to be run as a root user should make use of TaskRun features to -designate the container for a step runs as a user without root permissions. As a best practice, -running containers as non root should be built into the container image to avoid any possibility -of the container being run as root. However, as a further measure of enforcing this practice, +All steps that do not require to be run as a root user should make use of TaskRun features to +designate the container for a step runs as a user without root permissions. As a best practice, +running containers as non root should be built into the container image to avoid any possibility +of the container being run as root. However, as a further measure of enforcing this practice, steps can make use of a `securityContext` to specify how the container should run. An example of running Task steps as a non root user is shown below: @@ -1210,17 +1212,17 @@ spec: runAsUser: 1001 ``` -In the example above, the step `show-user-2000` specifies via a `securityContext` that the container -for the step should run as user 2000. A `securityContext` must still be specified via a TaskRun `podTemplate` -for this TaskRun to run in a Kubernetes environment that enforces running containers as non root as a requirement. +In the example above, the step `show-user-2000` specifies via a `securityContext` that the container +for the step should run as user 2000. A `securityContext` must still be specified via a TaskRun `podTemplate` +for this TaskRun to run in a Kubernetes environment that enforces running containers as non root as a requirement. -The `runAsNonRoot` property specified via the `podTemplate` above validates that steps part of this TaskRun are -running as non root users and will fail to start any step container that attempts to run as root. Only specifying -`runAsNonRoot: true` will not actually run containers as non root as the property simply validates that steps are not +The `runAsNonRoot` property specified via the `podTemplate` above validates that steps part of this TaskRun are +running as non root users and will fail to start any step container that attempts to run as root. Only specifying +`runAsNonRoot: true` will not actually run containers as non root as the property simply validates that steps are not running as root. It is the `runAsUser` property that is actually used to set the non root user ID for the container. -If a step defines its own `securityContext`, it will be applied for the step container over the `securityContext` -specified at the pod level via the TaskRun `podTemplate`. +If a step defines its own `securityContext`, it will be applied for the step container over the `securityContext` +specified at the pod level via the TaskRun `podTemplate`. More information about Pod and Container Security Contexts can be found via the [Kubernetes website](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod).