Containers should use the current user where possible

[Michał Sawicz]

Using `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft` your dir is littered with root-owned folders, it's a pain to have to clean it up with sudo.

[Cris Dywan (kalikiana)]

https://github.com/snapcore/snapcraft/pull/1408

[Michał Sawicz (saviq)]

I don't think the above PR solves what I'm describing here.

It's not only about $HOME, but also about all the snacpraft-created paths (excerpt):

 git status
[...]
Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .cache/
        .cmake/
        .config/
        .local/
        build/
        parts/
        prime/
        snap/.snapcraft/
        stage/

Or are you saying that all the parts things will remain inside the container?

Having a common .cache might be useful to some extent.

[Cris Dywan (kalikiana)]

.cache, .config and .local are addressed by the PR: it keeps them inside the container. We *could* also consider mounting .cache specifically from the host to share it with other snap builds, although that seemed to me like a separate enhancement so I didn't do it here.

Build artifacts like parts, prime and such would live in the project's source folder in a non-containerized build. So I'm not sure that we want different behavior here. I'd think you want as much as possible the same experience?

[Michał Sawicz (saviq)]

It's fine that they live in the project folder. What's not fine is that they're root-owned.

Basically I think you should create a $USER user inside the container and use that to build. That would be closest to local.

[Leo Arias (elopio)]

+1. I also don't like when I can't delete dirs anymore because the container left me without permissions to do so.

However, I had mixed experiences changing manually to the ubuntu user in the container, it sometimes fails to sudo, some other times I can't execute anything with that user. This could have been lxc bugs, now fixed. I'm just mentioning it to keep an eye.