> It is not “known” to me, the plugin maintainer, so as I wrote in PR > 57: if there is a concrete, small, easily reproducible test case that > demonstrates something that does not work which you feel should, > please file it. >
To clarify: I'm not saying that this is a result of a *problem* with how docker.inside is implemented, just that there is a bad interaction between the fairly reasonable implementation and what packaging needs to work fully (more than normal). Nobody is trying to hide bugs from you or shoot holes in the docker-workflow plugin, there are just some cases where docker.inside isn't a good mapping to what is needed so another approach is best used, and this is one. FWIW there's no guaranteed, comprehensive way to create and fully configure a user at runtime across all containers. When needed that is best handled within the container builds (or with helper scripts if you need to control the created user at runtime). Containers may contain stripped-down distributions without the normal user management facilities (or with very feature-limited versions if core utilities are not included). At this point I don't assume that *anything* exists and works in a base image until I see it run successfully. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/17f23bfe-4719-43c0-a51a-f1fdb5e9bab1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
