--vm-type=docker not compatible with build_root with common prj names containing ':'

[nickbroon]

If for example doing something like:

export OSC_BUILD_ROOT="var/tmp/build-root/%(project)s-%(repo)s-%(arch)s"

when used with common project, that contain the project seperator ':' will cause docker to complain as it uses ':' as in its mount specifications, and paths used cannot contain this character:

docker: Error response from daemon: invalid bind mount spec "/var/tmp/build-root/home:user:foo-Debian_9_Update_standard-x86_64/.mount:/mnt": invalid volume specification: '/var/tmp/build-root/home:user:foo-Debian_9_Update_standard-x86_64/.mount:/mnt'.

Perhaps the build.py code that does the substitution should replace ':' with something else like '_'?
Or at the very least a check/warning should be issues that using build_root with this character is not supported by docker.

            build_root = build_root % {'repo': repo, 'arch': arch,
                         'project': prj, 'package': pacname, 'apihost': apihost}

[mmohring]

I can confirm this problem exists also for osc building with KVM. E.g. there is then another problem but also with ":" and the build cannot be run because a ":" is in the constructed path name. My Workaround is not to put the project name into the path. The disadvantage is that you have to clean the buildroot if you change the project. The solution might be to use some kind of "hash-name" or rewritten name instead of the OBS project name.

[mmohring]

Sorry, it works with KVM (fixed in KVM, not osc, KVM did not allow ":" in path names). Anyway you can generate a pathname with working characters by replacing ':' with a working character like '_' as a workaround for docker.

[nickbroon]

I agree, it can be worked around by explicitly setting build_root to path without ':' in it.
I'd suggest the osc checks and warns when the paths contains this, instead of just allowing docker to error out.
Better yet, when it substitutes 'project' into build_root path in the above code snippet from build.py it should probably default to replacing the ':' with '_' as it's very common for projects to contain this, as OBS uses it as hierarchy separator.

[marcus-h]

On 2017-11-27 12:42:24 +0000, Nick Brown wrote: I agree, it can be worked around by explicitly setting build_root to path without ':' in it. I'd suggest the osc checks and warns when the paths contains this, instead of just allowing docker to error out.

Hmm yes we could do that in the docker case.

Better yet, when it substitutes 'project' into build_root path in the above code snippet from build.py it should probably default to replacing the ':' with '_' as it's very common for projects to contain this, as OBS uses it as hierarchy separator.

Hmm there is a potential clash, if you have a project called foo:bar another project called foo_bar. Not sure if this ever occurs in the wild... Opinions?

[nickbroon]

Would substituting '' with '__' and then substituting ':' with '' should avoid clashes, as I don't believe it's possible to have a project with '::' in it's name?

[marcus-h]

On 2017-11-27 13:27:25 +0000, Nick Brown wrote: Would substituting '_' with '__' and then substituting ':' with '_' should avoid clashes, as I don't believe it's possible to have a project with '::' in it's name?

This would indeed work (and is not ambiguous, because ":_" is not allowed in a project name). However, I think we can avoid this workaround, if we use docker's --mount option instead of --volume. I just created a corresponding PR [1] (completely _untested_). [1] openSUSE/obs-build#411