في شهر أكتوبر ، بدأ Github الإجراءات التي تسمح لك بتنفيذ CI دون مغادرة مكتب النقد الذي يتم تخزين هذا الرمز فيه. انها حقا مريحة للغاية. بمجرد قيام شخص ما بإرسال طلب سحب ، أو ببساطة تحميل تغييرات جديدة على الخادم ، أو أي شيء آخر خاص (يمكن العثور على قائمة بالأحداث التي يمكن ربط الإجراءات بها في الوثائق الرسمية ) ، يبدأ التجميع. كما يتم دعم المهام المتكررة المجدولة ( القائمة على كرون ).
يمكنك إنشاء خطوط أنابيب للعمل تسمى مهام سير العمل . كل هذا جميل ، ويبدو مستقبلاً مشرقًا - باستثناء الوثائق.
استغرق الأمر أكثر من ساعة لمعرفة كيفية إنشاء حاوية مع خدمات تابعة لجهة خارجية لاختبار التطبيق. هنا هو ما تمكنت من معرفة ذلك. يرجى ملاحظة أن الوثائق الرسمية محرجة بصراحة ، غير مكتملة ، وغالبًا ما تكون خاطئة.
يستخدم الإجراء CI القياسي ملفات التكوين مع بناء جملة مشابهة جدا لتلك المستخدمة من قبل CircleCI . هذه مجرد YAML القديمة الجيدة ، والتي تتيح لك تكوين نظام التشغيل المستهدف ، والبيئة ، وأوامر التنفيذ ، إلخ. الإجراءات نفسها تتلقى أسماء فريدة ، والتي تتيح لك الرجوع إلى إجراءات أخرى والاعتماد عليها.
بالإضافة إلى ذلك ، يسمح لك التكوين بتحديد الخدمات . يجب تشغيل الخدمات في مكان ما في السحابة ، وسيقوم GH بتعيين منافذ الحاويات إلى المنافذ التي تكشفها هذه الخدمات ، وفقًا للتكوين. هذا الجزء غير مغطى في الوثائق الرسمية ، وحتى ما هو موصوف يحتوي على أخطاء.
فيما يلي مثال لتكوين العمل لمشروع Elixir يتطلب خدمات RabbitMQ و Redis للاختبار.
name: Tests for My Project on: [push, pull_request] jobs: build: runs-on: ubuntu-latest container: image: elixir:1.9.1-slim services: rabbitmq: image: rabbitmq ports: - 5672:5672 env: RABBITMQ_USER: guest RABBITMQ_PASSWORD: guest RABBITMQ_VHOST: "/" redis: image: redis ports: - 6379:6379 steps: - uses: actions/checkout@v1 - name: Install Dependencies run: | MIX_ENV=ci mix local.rebar --force MIX_ENV=ci mix local.hex --force MIX_ENV=ci mix deps.get - name: Run All Tests run: | MIX_ENV=ci mix test env: RABBITMQ_HOST: rabbitmq RABBITMQ_PORT: ${{ job.services.rabbitmq.ports[5672] }} REDIS_HOST: redis REDIS_PORT: ${{ job.services.redis.ports[6379] }}
كما ترون ، ستعمل الاختبارات على Ubuntu باستخدام Elixir v1.9.1. يتم وصف الخدمات تحت الخدمات الرئيسية ، وهنا تبدأ قصة المباحث البحتة. يتم اختيار المنفذ الفعلي الذي سيتم ربط منفذ الخدمة به عشوائيًا بواسطة محرك الحاوية في وقت التشغيل ويتم تخزينه في متغير shell داخلي يسمى job.services.rabbitmq.ports[5672] . rabbitmq هو اسم الخدمة ، كما هو موضح في هذا الملف في قسم الخدمات و 5672 هو المنفذ المصدر. يحتوي المتغير الداخلي على بناء الجملة $ {{foo}} ويتم تمريره إلى متغير البيئة RABBITMQ_PORT (كتلة الإعداد الأخيرة ، أسفل env المفتاح). في RABBITMQ_HOST - تحتاج إلى وضع اسم الخدمة ، تمامًا مثل مفتاح الخدمات . الآن يمكن للتطبيق قراءة متغيرات البيئة كالمعتاد وسيتم تمرير المنافذ بشكل صحيح.
هذه هي الطريقة التي سنقرأ بها متغيرات البيئة هذه من البيئة (هذا تكوين لـ Elixir ، أما بالنسبة للغات الأخرى فسيكون هناك شيء مشابه جدًا).
import Config config :my_app, rabbitmq: [ host: System.get_env("RABBITMQ_HOST"), password: "guest", port: String.to_integer(System.get_env("RABBITMQ_PORT", "5672")), username: "guest", virtual_host: "/", x_message_ttl: "4000" ]
في ملف المشروع ، أقوم بإنشاء بيئة خاصة :ci ، للتمييز بين تكوين الاختبارات التي تعمل في البيئة المحلية ونفس الاختبارات التي تعمل في مكان ما في السحابة.
بالإضافة إلى ذلك ، في خط أنابيب CI ، أشغِّل dialyzer على مصادري. نظرًا لأنه يتم تشغيله في الحاوية ، تستغرق المهمة بعض الوقت ، لأنه يجب عليك إعادة إنشاء plts من الصفر في كل مرة. لهذا السبب أقوم بذلك مرة واحدة يوميًا باستخدام خيار تكوين schedule .
name: Dialyzer for My Project on: schedule: - cron: "0 1 * * *" jobs: build: runs-on: ubuntu-latest container: image: elixir:1.9.1-slim steps: - uses: actions/checkout@v1 - name: Install Dependencies run: | MIX_ENV=ci mix local.rebar --force MIX_ENV=ci mix local.hex --force MIX_ENV=ci mix deps.get - name: Run All Tests run: | MIX_ENV=ci mix code_quality
هنا code_quality هو اسم مستعار للمهمة تم إعلانه في mix.exs
defp aliases do [ code_quality: ["format", "credo --strict", "dialyzer"] ] end
هنا ، بشكل عام ، كل ما نحتاج إليه هو اختبار سعيد لمشروع ذي تبعيات خارجية في سير عمل Github الجديد.
التكامل المستمر الناجح!