Hi Evans, a) On a second thought: We are working on the overlay filesystem which is known not to be following 100% POSIX compliance: https://docs.docker.com/storage/storagedriver/overlayfs-driver/#limitations-on-overlayfs-compatibility <https://docs.docker.com/storage/storagedriver/overlayfs-driver/#limitations-on-overlayfs-compatibility> Maybe the build/lock problems are related.
b) IIRC is more or less by design and can't be fixed. Maybe it was a-not-so-good approach suggested. So I would vote to revoke BIGTOP-3001, rebuild images and revert back to old build process. Olaf > Am 01.07.2018 um 18:57 schrieb Evans Ye <[email protected]>: > > As I approaching the new way to build packages via bigtop-ci, I discover > some issues a) gradle home locked, hence can't build in parallel. b) many > dangling images are generated. > > Though those can be tacked, I think we better revert BIGTOP-3001 first and > fix those issues one by one. > Any second thought? > > > Evans Ye <[email protected]> 於 2018年6月14日 週四 下午10:28寫道： > >> Well then we can give bigtop-ci a try. >> I've integrated it into a testing job: >> >> >> https://ci.bigtop.apache.org/view/Packages/job/Bigtop-trunk-packages-BIGTOP-2993/ >> >> Let me see how it goes. >> >> >> Olaf Flebbe <[email protected]> 於 2018年6月14日 週四 下午11:23寫道： >> >>> hi evans >>> >>> i disabled nexus amteady before since it had issues as well. so no nexus >>> should not be a problem >>> >>> olag >>> >>>> Am 14.06.2018 um 15:54 schrieb Evans Ye <[email protected]>: >>>> >>>> bigtop-ci/build.sh can solve the issue but right now we don't have nexus >>>> enabled with it. So it's not ready as Olaf said. I think reverting is a >>>> better option since we don't want to loose stability after day-to-day >>>> iterations. >>>> We can recommit BIGTOP-3001 back once bigtop-ci is polished and ready to >>>> take over CI jobs. >>>> >>>> Evans >>>> >>>> >>>> Olaf Flebbe <[email protected]> 於 2018年6月14日 週四 下午10:05寫道： >>>> >>>>> Hi, >>>>> >>>>> there was a Change in bigtop to remap the uid of jenkins to uid 500. >>> Now >>>>> our CI is seriously broken, since this uid is actually reservered by >>> our >>>>> cloud provider for our host and the jenkins is now broken: since >>> jenkins on >>>>> the host and within the container has different uid's . Mapping of >>> sources >>>>> into the container do not work any more. >>>>> >>>>> I already had to remove all the data in Bigtop-packages-trunk CI job. >>>>> >>>>> There are a couple of options to solve this: >>>>> >>>>> * Reverting BIGTOP-3001, but than it may clash with uid at the >>> committers >>>>> machine >>>>> * Enhance bigtop-ci/build.sh >>>>> >>>>> Best, >>>>> Olaf >>> >>
