./dev.sh

dev.sh هو نص برمجي مساعد يجعل العمل مع بيئة تطوير Climweb أمرًا سهلاً.

افتراضيًا، سيؤدي تشغيل ./dev.sh إلى تشغيل بيئة التطوير والتأكد من تشغيل الحاويات كمستخدم فعلي.

أمثلة على استخدام ./dev.sh:

$ ./dev.sh # same as the up command above but also ensures the containers run as the running user!
$ ./dev.sh --build # ups and rebuilds
$ ./dev.sh restart # stops and then ups
$ ./dev.sh restart --build # stops, builds, ups
$ ./dev.sh build_only # just builds
$ ./dev.sh dont_migrate # ups but doesn't migrate automatically on startup
$ ./dev.sh dont_migrate dont_sync dont_attach restart --build # even more flags!
$ ./dev.sh run backend manage migrate
# Any commands found after the last `./dev.sh` command will be passed to the `docker compose up` call made by dev.sh
# This lets you say do --build on the end or any other docker-compose commands using dev.sh!
$ ./dev.sh restart {EXTRA_COMMANDS_PASSED_TO_UP}  
$ ./dev.sh down # downs the env
$ ./dev.sh kill # kills (the old stop_dev.sh)
# WARNING: restart_wipe will detail ALL volumes associated with that environment 
# permanently. 
$ ./dev.sh restart_wipe --build

لماذا يضمن ./dev.sh تشغيل الحاويات مثلك

في وضع التطوير، يتم تثبيت أدلة التحكم بالمصدر الخاصة بـ Climweb من git repo المحلي الخاص بك في الحاويات. من خلال تركيب هذه الحاويات، ستشهد تغييرات التعليمات البرمجية المصدر وإعادة البناء تلقائيًا. ومع ذلك، إذا كانت الحاويات لا تعمل كمستخدم فعلي، فقد تقوم الحاويات بتغيير الملكية عن طريق الخطأ أو إنشاء ملفات مملوكة للمستخدم الذي يعمل داخل الحاوية. لذلك، من خلال تشغيل الحاويات كمستخدم لديك، لن يكون هناك احتمال أن تواجه أدلة التحكم بالمصادر مشكلات في ملكية الملفات. بالإضافة إلى ذلك، من الأفضل عدم تشغيل حاويات Docker كمستخدم جذر افتراضي.