Problems with images that assume a particular workingDir and/or HOME environment variable

[skaegi]

I've been integrating with a few pen testing tool images that are relying on a very specific workingDir being set. The problem I've been having is that Tekton overrides this setting and then I had to go back into the image to reverse engineer its original value.

Could we provide a way to not override this setting and do we even need to do this anymore?

[bobcatfish]

The problem I've been having is that Tekton overrides this setting and then I had to go back into the image to reverse engineer its original value.

I'm surprised that Tekton overrides the workingDir - can you provide an example of this happening?

If that's the case I agree that we shouldn't be arbitrarily setting it (what is it getting set to?)

[skaegi]

Sure, any task will do -- just echo $(pwd) and it is always /workspace

https://github.com/tektoncd/pipeline/blob/master/pkg/pod/pod.go#L159

[vdemeester]

Indeed, we are setting it to /workspace if there isn't any. I wonder if we should do the same as the entrypoint magic where we read the image configuration before doing that to see if any is set.

Also, maybe it should be the other way around, by default we do not set it if empty, but we have an option somewhere that tells Tekton to override it (per task or pipeline, or globally ?)

[skaegi]

I want to expand this issue as the HOME env (which gets set to /tekton/home)variable is the other common problem we see e.g. where an image has explicitly set HOME. We're currently asking our users to explicitly set HOME and workingDir.

I <3 the way the entrypoint works as it is mostly transparent and wonder if other things could work the same way.

[bobcatfish]

Also, maybe it should be the other way around, by default we do not set it if empty

👍 for not setting it if it's empty. I propose we warn in 0.10 and change it in the following release, whaddaya think @vdemeester @skaegi ?

but we have an option somewhere that tells Tekton to override it (per task or pipeline, or globally ?)

At the moment i think you can do this with the stepTemplate, maybe that's good enough for now?

I want to expand this issue as the HOME env (which gets set to /tekton/home)variable is the other common problem we see e.g. where an image has explicitly set HOME. We're currently asking our users to explicitly set HOME and workingDir.

This is a bit tricker imo b/c we're trying to create a "home" that is shared across all containers - ( + @imjasonh ) - I'd be up for adding logic like we do with entrypoint, so that we have a hierarchy like:

• If the Step specifies HOME, use that
• If not but the stepTemplate does, use that
• If not but the Image does, use that
• If none of the above, use /tekton/home

?

[imjasonh]

+1 to falling back in that way.

We should consider phasing out /tekton/home and setting env: HOME=/tekton/home entirely. We did it in Knative Build, and in Cloud Build before it, but I think it's largely more confusing than it's worth.

We could make it a platform provider ConfigMap option, opt-out first, then release and announce it'll become opt-in, then eventually remove the option. Don't mount /tekton/home, and don't set HOME=/tekton/home, ever.

If the step or step template sets env: HOME=..., that's fine, a user has set that. If the image has a default HOME, that's fine too. We should get out of the game of setting home, ever.

workingDir and /workspace are harder, because I think users do benefit from being placed by default in a directory that persists across steps and can be guaranteed to exist. We could fallback in the same way, and look into the image metadata to determine whether it sets a WORKDIR, but I'm not sure every user would want that either. Platform providers could opt out of providing /workspace if they know their users don't expect it.

[skaegi]

Inside my company we're starting larger adoption of Tekton and this single issue is constantly getting a ton of attention. Basically, we have teams moving from Jenkins, Travis, and other image based pipelines and are getting hammered when teams do not understand why things that worked in their old pipelines are no longer working.
re: Jason's post above -- the HOME problem is an order of magnitude worse than the workingDir issue. If at all possible I would really like to consider phasing that out if we can still consider it.

[vdemeester]

I am definitely +:100: on phasing out HOME and /tekton/home 👼

[vdemeester]

/assign

[skaegi]

Once @sbwsg commits #2044 I'm happy to do the same work for workingDir as I really want this for 0.11.

[othomann]

I am preparing a PR for the workingDir change.

[othomann]

@sbwsg @skaegi @bobcatfish I created #2115 to take care of the working directory pending change.

[ghost]

Reopening this one as deprecating the workingDir default is yet to happen.

/reopen
/remove-lifecycle stale
/remove-lifecycle rotten

[tekton-robot]

@sbwsg: Reopened this issue.

In response to this:

Reopening this one as deprecating the workingDir default is yet to happen.

/reopen
/remove-lifecycle stale
/remove-lifecycle rotten

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[bitsofinfo]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[ghost]

/remove-lifecycle stale
/lifecycle frozen

[afrittoli]

Now that've switched the default behaviour to not-override HOME, I think this could be closed?
@skaegi @sbwsg

[ghost]

I'm using the comment here: #1836 (comment) to track progress for this issue. We still plan to completely remove the feature flag so i'd like to keep this tracking issue open if that's ok.