Add handling of working directory

[othomann]

Changes

Tekton currently overwrites the working directory in task containers if a specific working directory is not specified. This behaviour is problematic when an image explicitly sets a working directory and expects it to be set to that value upon running.

This PR introduces a feature-flags ConfigMap with a single flag - disable-working-directory-overwrite - that, when set to "true" will prevent Tekton from overriding the working directory in Task containers. This behaviour will be kept for one release which must include a deprecation warning that the behaviour will be changing soon. In the release after that the flag will be flipped so that the default behaviour becomes for Tekton to NOT override the working directory.

Contributes to issue #1836

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

Reviewer Notes

If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.

Release Notes

Tekton currently overwrites the working directory in Step containers if not explicitly specified by the user. This behaviour is problematic when an image explicitly sets the working directory and expects it to be set to that value upon running. You can now disable this behaviour in Tekton by using the feature-flags ConfigMap. See docs/install.md for further details on disabling this behaviour.

[skaegi]

/lgtm
I just tested with my kube-hunter image and now it works without explicitly setting workingDir

[vdemeester]

I wonder if we can optimize this in the future, as same for the home environment variable, it will add another api call each time we create a pod (adding a bit of latency), for something that might change not that often. We do have a configmap watcher for the default & co, I feel we should have the same for feature flags.

Other than that, looks good to me.

/cc @sbwsg

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ghost]

@vdemeester good point! I took a very quick look at the configmap watcher and got 😨 because I couldn't easily trace where the actual configmaps to watch were being configured. I can take another look at this. Issue to track it: #2117

[ghost]

/lgtm