> On Nov 19, 2016, at 11:30 AM, suraj acharya <[email protected]> wrote:
>
> Questions :
> 1. What is the expected user to run the test-patch.sh script?
It's expected to be the same user that is executing the script outside
of the container. This way when we import volumes the uid, etc match.
> In my dev environment, I tried to run it as root,
Oh, that's going to be problematic.
> and it errored out since the user root and group root existed.
Right.
> I had to make the following change to allow the user root to run the
> commands. If this looks reasonable, I can submit a patch for the same.
Yup, I think that's reasonable.
>
> 2. My understanding of the --user-plugins is that, yetus will copy over the
> whole directory and try to run the pre-commit for the build in the
> user_plugin directory.
> However, when I run it it throws an error saying :
> cp: cannot stat ‘/root/avro/share/pre_commit/*’: No such file or directory.
> And the whole run fails.
> However, if I run it in a non docker environment it runs successfully.
Your understanding is correct. Docker mode basically copies everything
into a holding area. That holding area is then used to re-execute under Docker
with everything in a known, fixed location. This prevents a lot of work later
in having to guess what needs be mounted in volumes, changing code underneath
us if we're patching ourselves, and various other craziness/edge cases.
That said, I have a hunch that the quoting is wrong in copytpbits:
cp -pr "${USER_PLUGIN_DIR}/*" \
"${PATCH_DIR}/precommit/user-plugins"
At a minimum, "${USER_PLUGIN_DIR}/*" should be "${USER_PLUGIN_DIR}"/*.
But this line should probably be
cp -pr "${USER_PLUGIN_DIR}"/. \
"${PATCH_DIR}/precommit/user-plugins"
... to avoid any shell escape issues as well as copy dot-files. We
could go extra crazy and use cp -pR, but that's probably wildly unnecessary.
